Requirements are the things that you should discover before starting to build your product. Discovering the requirements during construction, or worse, when you client starts using your product, is so expensive and so inefficient, that we will assume that no right-thinking person would do it, and will not mention it again.
Then he goes on to criticize the statement above, by comparing it to the agile processes, where you have continuous discovery of the requirements. Here is what he says:
Agile methods violate this underlying assumption by intending to discover the 'requirements' during construction and after delivery.
I don't quite agree with Martin Fowler here. Agile processes are inherently iterative, but even in an iterative process the requirements for a given iteration are supposed to be known before that iteration starts. At the beginning of a Scrum iteration, for instance, the team is supposed to know exactly what it has to build, as defined in the Sprint Backlog. An iteration doesn't start if the team doesn't have the scope very well defined. The opposite to it would be to sit down in front of a computer in a given morning to begin writing the revenues recognition module without any idea of how the revenues recognition rules are suppose to work, and starting to ask around to see how revenues recognition works.
The even worse thing mentioned in the quote above is to discover the requirements when the system is in production. It is equivalent to write the revenues recognition module using your own assumptions to what the business rules are and then finding out during production that the rules you implemented are completely wrong.
What Agile methods do have is the ability to adapt to change. Requirements change because the market or the business change, and they also change because the people involved get a better understanding of what the requirements are. The assumption is that you will get the requirements wrong, and this is very often the case, but you are still hoping to have gotten them right at the first time. If you got them wrong, though, Agile processes have the means to adapt to this change.
Posts
2 comentários:
Hi,
Hm... actually I agree with him.
Your are correct when you say that in a iteration the team will know what are the requirements for *that iteration*. In that iteration we will still discover new requirements that will be played in subsequent iterations, that's where Agile diverges from what the book (or at least that paragraph) says.
Agile processes will ideally not have a big-bang "got to production" thing so when he says ' after delivery' he actually means any of the production-ready systems that are delivered in the end of each iteration.
cheers
Hi Shoes,
It looks like a matter of interpretation to me. I haven't read the book, but I don't expect it to be suggesting that requirements should all be set in stone before you begin building your software. Any textbook on software engineering for the past 20 years talks about iterative development, so I would be *very* surprised if the guys who wrote that book are still thinking with a waterfall mindset! :)
It seemed to me that the text was saying that you should not start coding without knowing the requirements for what you are coding.
Cheers!
Post a Comment