Extreme Programming Installed, Chapters 4-6

Reference Information
Extreme Programming Installed, Chapters 4-6
Jeffries, et al
Addison-Wesley Professional, 2000


Summary
Chapter four describes the process for using stories to drive the iterative development process. User stories are short explanations of the desired functionality of the system. They are written by the customer for the programming team, describing at most one major feature that is desired. The story writing process starts with the customer and programming team in the same room, and a box of index cards. The customer should then write out a story on each card while the team asks questions, causing the customer to refine the story until the team is in complete understanding. The conversation generated between the customer and the team is the critical element of the process, since this type of face-to-face meeting is much preferred to email and phone calls. The stories should be whittled down, or broken up into separate stories if need be, so that they should only take a week or two to implement for a programmer.


Chapter five covers the topic of acceptance tests, which are the tests provided by the customer to ensure that all of the requirements are being met. The tests should be as thorough as possible to ensure that no major bugs make it to the actual release version. Testing should be a key part of the development process, with testing going on from the very beginning so that any bug introduced can be quickly fixed before the programmer forgets the details about the offending code. To facilitate this constant testing, it must be automated from the beginning so new tests can be added throughout the development process without difficulty. The customer must provide the acceptance test for a feature being implemented in an iteration by around the middle of that iteration to ensure that it gets the necessary amount of testing. 


Chapter six explores how programmers can estimate the cost of a story, in terms of programmer time. Accurate estimates allow the customer to choose exactly what they would like in each iteration while also keeping the development process running smooth. At first judge time by "perfect engineering weeks", which are ideal working weeks with no interruptions. Then, assign points to this allotment of time so future reckoning of time is in an abstract point form instead of real time so as to prevent demoralizing the programmers. Once these baseline estimations have been assigned points, all future stories can simply be compared in difficulty against already completed stories to estimate cost (i.e. if it is twice as hard, double the points). To give the customer a "budget" for features, use past performance in points per iteration to judge how much may be completed in the next.


Opinion
We have had to use the storyboarding technique in a software engineering class, but we lacked specifics and experience on how to put it into motion. We mostly made mistakes coming up with story size, and chapter four made it clear to me exactly how large projects should be. The author should have, in my opinion, explained the exact difference between unit and acceptance tests, since he clearly differentiates them but gives no reason for this.

Using index cards to write stories on