Exploration Through Example
Example-driven development, Agile testing, context-driven testing, Agile programming, Ruby, and other things of interest to Brian Marick
| 191.8 | ⇒ | 167.2 | ⇒ | 186.2 | 183.6 | 184.0 | 183.2 | 184.6 |
Exploration Through ExampleExample-driven development, Agile testing, context-driven testing, Agile programming, Ruby, and other things of interest to Brian Marick
|
|
Tue, 09 Nov 2004Adding a basement to the house Agile methods people claim changed requirements late in a project are not a disaster. Skeptics claim that's impossible, that it's like finishing the first story of a house and then deciding you want a basement. That's a misguided analogy. The reason putting in a basement after the walls are up is hard is because almost no one does it. If it was done to every house during construction, you may be sure that homebuilders would have learned to do it as cheaply as is physically possible. Agile projects don't think ahead: in iteration N, they don't pay much attention to what's coming in iteration N+1, much less iteration N+5. That means that every iteration brings with it a whole slew of what are, in effect, changed requirements. That trains both the software and the team to handle change as cheaply as is softwarically possible. It's like the way that just-in-time inventory management forces factories to improve their production process. Because they cannot buffer asynchronies with stock on hand, they are forced to remove them. (See The Machine That Changed the World.)
## Posted at 23:53 in category /agile
[permalink]
[top]
|
|
