To summarize, I find it helpful to consider iterations and increments in both of these dimensions.
- An iterative process would be like any agile process. You repeat the same development activities over and over. That's what we like to do.
- An iteration in the product dimension would be, as Cockburn points out, improving quality or functionality of the product. That is certainly legitimate in a lot of situations. You make a tentative solution — not necessarily a prototype — and you present it. It may be accepted or rejected. But even if accepted, the customer may want to iterate on it to improve it. Tom Gilb calls it evolutionary development. And we may want to iterate on it, refactor it, to improve its internal quality.
- An increment in the process would imply doing more and more things in each iteration, like documenting more, testing more, designing more, or even adding new steps. This happens in many situations where thing go wrong. Then you add rules or steps to go through to prevent that from happening again. Isn't that how heavy processes emerge?
- Incrementing the product would be adding new features to it. That's what we normally do.
Is this distinction helpful? Well, I think it is always helpful to understand the words you are using.
So, within the framework of an iterative process, we both iterate on the product and we increment the product.
Does all of this assume an iterative process in the first place? I don't think so. Look at a typical waterfall development process. While deployment may be neither iterative nor incremental, I am sure that in most cases the development is de facto incremental, despite the linear process. The developers are even likely to iterate over the (still undeployed) product. So the product is developed both iteratively and incrementally. But the process is not iterative.
And I find that in RUP, for instance, the process is iterative, and you are supposed to build the product incrementally. But RUP does not encourage iterating on the product itself. To me, that's one important factor that makes it very waterfallish and inapt to adaptive development.
To implement the agile values, the process needs to be iterative, and you need to both iterate on the product and increment the product during your process iterations. Waterfall fails in not being an iterative process. RUP fails in not iterating on the product.
1 comment:
Insiktsfullt och klargörande!
/Christina
Post a Comment