When Alan Cooper and Kent Beck debated the benefits of eXtreme Programming versus Interaction Design, they disagreed on a lot of things. One thing they agreed on is that Agile processes are designed to minimize the impact of changing requirements. Cooper believes that it makes more sense to minimize future change by understanding the requirements better up front. Beck believes that the requirements can not be understood by the team until something is delivered. Beck’s point is that the customer doesn’t understand the requirements until he has something in his hands. We’ve shown how this is both a strength and a weakness for Agile in the real world. In The Hobbit, the dragon Smaug was missing a scale on his belly, that made him vulnerable. Agile processes have a similar weak spot.
Irrelevance of Change
The interesting thing isn’t that Agile teams need changes in the requirements to succeed. The process is relatively immune to change. By waiting until the last responsible moment to elicit requirements, we don’t care how much those requirements change prior to getting them.
Relevance of Change
There’s a chink in Agile’s armor. Imagine we are half-way through a project, using an Agile process.
- We know that requirements change.
- We are about to gather requirements for the next iteration.
- We waited to gather these requirements, because the requirements didn’t exist until the customer saw the last release.
If change happens, and we’ve finished half of the application, it stands to reason that half of the changes will be to stuff we’ve already built.
When 90% of the application is complete, won’t 90% of the changes be to stuff we’ve already done (and now have to do again)?
No Worse Than a Waterfall
Sure, with a waterfall model , 100% of the changes will be to stuff we’ve already built, because we (think we) finish it before we deliver it. With an Agile process, roughly half of the changes should be to functionality we’ve already delivered. This assumes a constant rate of output by the development team.
Good Requirements Matter
I don’t accept the premise that the customer doesn’t know what they want. Customers know what they want – higher profits, greater market share, etc. What customers don’t know is what software they want. With the right requirements, and the resulting implementation, they don’t care. Or at least, they shouldn’t care. Documenting these requirements is very hard. Most people can’t do it well. That doesn’t mean that the job can’t be done. Most people can’t run a four minute mile, or transpose music up a step when sightreading. Doesn’t mean it can’t be done.
Cooper believes that the interaction design process is the ideal one for writing software requirements. He may be right, the jury is still out. There are only two statements that we can make about the “best” software development process.
- The best process includes elements of each of the processes that currently claims to be best.
- The best process for project A (or team A, or company A) is not the best process for project B.
Conclusion
Without proclaiming what the best process is, we know that some things are very powerfull:
- Combining structured requirements with interaction design principals yields compellingly useful software.
- Iterative delivery and responding to customer feedback helps us make increasingly better decisions.
- Continuous integration provides a massive efficiency boost to developers and lowers QA costs.
The “best” process is going to combine those strengths, whatever its called.
Latest Articles
Comments on all Articles
