Extreme Programming in Perl Robert Nagler phần 2 pps

hands and scream in exasperation, they’re saying the program misses the

mark by a mile. It’s insufficient to tell them the specification was right

or that the programmers simply misunderstood it. It’s the code users are

frustrated with, and it’s the code that is just plain wrong.

Planning and specification does not guarantee end-user satisfaction. Plan￾driven methodologies ignore requirements risk, that is, the risk that details

may be incorrect, missing, or somehow not quite what the customer wants.

When we gather requirements, write the specification, ship it off, and only

check the program against user expectations at the end, we are setting our￾selves up for failure. Requirements change in this scenario is very expensive.

This is what we see in the Rock example. The requirements risk is propor￾tional to this time lag. Given the predominance of plan-driven software

development, it’s likely that a large number of project failures are directly

attributable to too little requirements risk mitigation.

1.6 Let’s Rock And Roll

Fortunately, there is an alternative version of the Get Me a Rock story,

which solves the ill-defined requirements problem with greater efficiency:

Boss: Get me a rock.

Peon: Sure, boss. Let’s go for a ride to the quarry.

...a little while later...

Boss: Thanks for pointing out this rock.

I would have missed it if I went by myself.

Peon:You’re welcome, boss.

The moral of this story is: to increase efficiency and quality, bring the

customer as close as possible to a project’s implementation.

Copyright c 2004 Robert Nagler

All rights reserved [email protected]

6