Title: Extreme Programming Installed
Author: Ron Jeffries, Ann Anderson, Chet Hendrickson
Editor: Addison-Wesley Professional, October 2000
Summary
Chapter 4 discusses user stories, which are short descriptions of the behavior of the system from the viewpoint of the user. It is the customer's responsibility to create the stories to let the programmers know what's needed in order to get the most possible value out of programming. The user story acts as a mode of communication between customer and programmer. Stories can be split or expanded upon based on the amount of time they will take or estimated complexity.
Chapter 5 discusses acceptance tests, which allow the customer to know when the system works and to tell the programmers what needs to be done. It is the customer's responsibility to provide acceptance tests as part of each iteration, telling the programmers what must work and ensuring that changes to the system do not break things that already work.
Chapter 6 explains the process of estimating stories, and how long they will take to program so that customers know how much stories will cost in order to choose which ones should be completed. During the project, stories are estimated by comparing them to previously completed stories, although the time to implement a story depends not only on complexity but also how fast the team is working at that point in time. The estimation usually occurs by some neutral measure of time, such as a point system or "perfect engineering weeks." For stories that are unlike any story previously completed, the method of writing some sample code to make an estimation is preferred.
Chapter 4 discusses user stories, which are short descriptions of the behavior of the system from the viewpoint of the user. It is the customer's responsibility to create the stories to let the programmers know what's needed in order to get the most possible value out of programming. The user story acts as a mode of communication between customer and programmer. Stories can be split or expanded upon based on the amount of time they will take or estimated complexity.
 |
| An example of a user story depicting the need for a "Search and Replace" feature in a word processor. Source: www.stellman-greene.com |
Chapter 5 discusses acceptance tests, which allow the customer to know when the system works and to tell the programmers what needs to be done. It is the customer's responsibility to provide acceptance tests as part of each iteration, telling the programmers what must work and ensuring that changes to the system do not break things that already work.
Chapter 6 explains the process of estimating stories, and how long they will take to program so that customers know how much stories will cost in order to choose which ones should be completed. During the project, stories are estimated by comparing them to previously completed stories, although the time to implement a story depends not only on complexity but also how fast the team is working at that point in time. The estimation usually occurs by some neutral measure of time, such as a point system or "perfect engineering weeks." For stories that are unlike any story previously completed, the method of writing some sample code to make an estimation is preferred.
Discussion
The idea of user stories seems like a good idea for getting the customer to neatly lay out the features a system needs to have, although it may be confusing as it is unlike most methods. Acceptance tests could also be a useful feature, allowing both user and programmer to be sure that a particular aspect of the system is currently working despite any changes that may have occurred. While programmers generally find tests to be tedious and a waste of time, the customer's satisfaction should probably outweigh the programmer's speediness of programming. Besides, if the programmer is attempting to program as fast as possible, eliminating tests in order to do it, he is likely to waste more time fixing things that have been accidentally broken than would originally have been spent writing automated tests. Finally, the point system of estimating stories seems like it would be a pain. Instead, it would be nice to be able to say approximately how long the programming should take in days or weeks instead of assigning points that could be seen to have arbitrary meaning to different programmers.
The idea of user stories seems like a good idea for getting the customer to neatly lay out the features a system needs to have, although it may be confusing as it is unlike most methods. Acceptance tests could also be a useful feature, allowing both user and programmer to be sure that a particular aspect of the system is currently working despite any changes that may have occurred. While programmers generally find tests to be tedious and a waste of time, the customer's satisfaction should probably outweigh the programmer's speediness of programming. Besides, if the programmer is attempting to program as fast as possible, eliminating tests in order to do it, he is likely to waste more time fixing things that have been accidentally broken than would originally have been spent writing automated tests. Finally, the point system of estimating stories seems like it would be a pain. Instead, it would be nice to be able to say approximately how long the programming should take in days or weeks instead of assigning points that could be seen to have arbitrary meaning to different programmers.
No comments:
Post a Comment