Ron Jefferies, Ann Andreson, Chet Hendrickson
Editors: ?
The authors began this section by discussing the various aspects of user stories from their creation to implementation. To begin the user story process, the programmers and customer sit in a room with a box full of index cards. Then the customer writes down a story that explains a small section of the functionality of the system. The programmers and customer then work together to refine the story by asking questions and addressing concerns. This relates back to the in person communication that is a core aspect of extreme programming.
The authors then discuss acceptance tests, tests provided by the customer to ensure the system meets all of their requirements. Programmers should utilize these acceptance tests throughout the entire development process. This will allow them to ensure that the product meets the specifications of the customer at all times. The customer should also be able to add or remove acceptance tests at any point in time. A good way to manage this process is to use automated testing, where builds are automatically run through a program that will verify that they meet the current set of acceptance tests.
The last chapter focuses on how important it is for programmers to be able to estimate the difficulty of user stories. This allows the programming team to provide useful feedback to the customer as well as plan their schedule to avoid roadblocks and keep the development process as smooth as possible. The authors recommend using a point system, where each story is allotted a certain amount of points based on its difficulty. The programmers can then set a budget on how many points they are able to complete in a certain time period. If the user stories presented to the team exceed the budget then the customer would need to remove or modify stories.
Discussion:
I like the idea of using user stories to communicate the desires of the customer to the programming team as well as the concerns of the programming team back to the customer. Often, customers want every feature possible for a low cost and a short development time. Having the team meet with the customer in person can help to encourage communication on project scope and cost from the very beginning. I wish that the authors would have focused more on the discussion of how programmers and customers can negotiate user stories. Such as what to do in certain unplanned situations where the customer refuses to modify stories. I think that the ideas in this reading could be applied to the projects that I work on where a customer is involved. Having the face to face communication at the start of a project could really help me to understand what the customer actually wants from the end product.
No comments:
Post a Comment