by Ron Jeffries, Ann Anderson, and Chet Hendrickson
In Chapters 4 - 6 of Extreme Programming Installed, the authors present the idea that is integral to Extreme Programming and Agile Programming development practices: the user story. A user story is a description of something that the user should be able to do, which is usually called a feature. Each user story represents some programming work that should be done, and should specify the inputs to the procedure, the correct outputs, or the options / things that the user can do with it. When the design is done in user stories, there are more incremental updates to the product with new features being added. The benefit is that there is always a working product to show to a customer.
At the beginning of the planning process, the customers write all the user stories on index cards, and give them to the programmer. The programmers look at each one, ask for clarification if needed, split a user story into multiple ones if it's too large, and estimate how long it will take to do. The estimation is done in "points," which each represent a "perfect engineering week." A perfect engineering week is the amount of work you could get done if you were allowed to program with no interruptions for a week. So if a user story is given 2 points, it means that it should take about 2 weeks to finish.
The customer is responsible for specifying acceptance tests for each of the user stories; in this way, the programmer knows exactly what functionality must be there and knows when they're done programming for the story. In Extreme Programming, testing is not a phase that is done at the very end of the development process. Instead, automated tests are built that are constantly run. This is so that errors can be caught after a programmer has just finished coding the section, making it easier to remember what changes you made and where the error might be.
I really liked this section because it perfectly describes the way my group worked when I interned this summer. We made user stories and tasks for the user stories (online though, not with note cards) and we estimated points for each user story. This really helped keep the group organized and let us all know exactly what work we needed to do, and the time frame for getting it done. And although writing automated tests and tools can be time-consuming, and some programmers may have that as their only job, I know from experience that it's worth finding errors as soon as they're made. I can't tell you how many times that I've forgotten how I coded something in a school project and had no idea what to change to fix it.
No comments:
Post a Comment