Release Planning


Everything in XP revolves around user stories. The programmers break stories up into tasks and sign up for those tasks ; acceptance tests are driven by the stories, with more detail added; and conversations with the customer are triggered by requests for more detail for individual stories. If the system contains bugs that need to be fixed, then they are written up as stories. [8] And planning in XP, in particular, revolves around user stories.

More specifically , release planning in XP is based on which user stories to implement and release to the customer in which iteration. The stories are estimated by the programmers in terms of perfect weeks [9] ”that is, the amount that a programmer feels he could get done in a week with no interruptions, no distractions, and a mind focused purely on the story at hand. By tracking these estimates over time and comparing these with the actual time that each story takes to implement (which will inevitably be more time due to all the interruptions and distractions), the project velocity can be measured.

In XP, this is known as the planning game. Essentially, XP s planning game is a way to do agile planning so that change can be embraced. The team ( including the customer) plans several iterations and at least two releases ahead. At the start of each iteration, the stories may be reprioritized.

Although this approach has merit for certain types of projects, in most business organizations the customer would almost certainly prefer to take a fixed scope, fixed budget approach, in which the customer works out in advance what is needed and the supplier (the XP team) tenders for the contract.

XP is optimized toward optional-scope contracts, but in many cases the real world just doesn t work this way. So in cases where a fixed-scope contract is required, XP s high-discipline collection of interdependent practices isn t the most efficient approach by any means.

start example

We discuss the merits and pitfalls of the various contract types in Chapter 11. And in pretty much the entire book (though particularly in Chapters 3, 11, and 12) we discuss why XP is high discipline and not the most efficient approach.

end example
 

[8] Kent Beck and Martin Fowler, Planning Extreme Programming , op. cit.

[9] The term perfect weeks or ideal days is used less often these days. Most XP teams now use story points or gummi bears or some other arbitrary measure to distinguish between estimating and scheduling.




Extreme Programming Refactored
Extreme Programming Refactored: The Case Against XP
ISBN: 1590590961
EAN: 2147483647
Year: 2003
Pages: 156

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net