by Ron Jeffries, Ann Anderson, and Chet Hendrickson
In Chapters 7 - 9 of Extreme Programming Installed, the authors address the issue of release planning and the way that user stories are estimated and scheduled in the Extreme Programming paradigm. Small and frequent releases are important because not only do they allow the customer to have a working product sooner, but they also allow for customer feedback throughout the development process. Each release shouldn't be just a demo of what the product could possibly do in the future, but instead should be a real product that the customer can start using on a regular basis. The authors also give examples of large-scale projects that can't seem to be broken down into small releases, and show ways that incremental pieces can be delivered. For example, if you are tasked to build a "Distributed Manufacturing Control System" consisting of microcomputers that talk through a distributed network and control each machine of a factory, it would seem that you need the whole system working before it could be released. But, you could program for and create the microcomputer for a single machine, and allow it to communicate mechanically with the existing legacy system. Then, you could incrementally add functionality to each machine in the factory, making the system more efficient along the way to the final system.
When planning releases, it is important that the Customer as defined in the first few chapters is in charge of planning the user stories that will be completed in a release. As before, the Customer presents user stories to the Programmers, who each look at the stories, ask for clarification, and estimate the time it will take to finish it in points. Then, based on the number of points that the team can finish in a week together, the Customer can pick the most important user stories that can be completed by the release date. After this, the Programmers can each sign up for the user stories, making sure they don't pick too many and overshoot their capacity. An important note is that each Programmer should sign up for a user story alone, or with a partner, and not split up tasks between different Programmers. This isn't to say that another Programmer isn't allowed to help you if you're stuck; this is so that tasks in a user story aren't forgotten and the story never finished.
After working at a major company this summer, I learned a lot about Extreme Programming because we used the system (or a variation of SCRUM, really) at the company. While we didn't have actual note cards for user stories, we had an online system that allowed us to add user stories, define tasks for those stories, and then assign a point estimate to them. Like in these three chapters, we would have release or iteration planning meetings where we would introduce each user story, and we would all vote on the number of points we thought it would take. When we had a consensus, that was recorded, and a programmer signed up for the task. From experience, this system works EXTREMELY well. We never once had a problem with estimating incorrectly how long it would take to finish a task, and so whenever we got to the end of the iteration / release, there were only a few features that didn't make it in. And because we were working on incremental releases to a new product, most of the things that didn't make it were minor bug fixes concerning strings or something. Also, having a "Customer" in charge of choosing the most important user stories for an iteration is extremely useful in giving the programmers direction.
No comments:
Post a Comment