Book Reading 3: Extreme Programming Installed (CH 4-6)

Sample: User Story
Reference Information:
Title: Extreme Programming Installed
Authors: Ron Jeffries, Ann Anderson, Chet Hendrickson
Publication: Addison-Wesley Professional; 1 edition (October 26, 2000)

Summary:

          User Stories
User story is the short description of the behavior of the system, from the point of view of the user of the system. First step is - analysis i.e. finding out what the customer wants. The user story is the medium of analysis i.e. the medium of communication between the customer and the programmer.User stories are nothing but couple of sentences written on an index card (as shown in the picture above). Sometimes, the stories get complex and the programmer may need to help the customer to write the stories. It's important that complex stories are broken down into simpler stories. How many stories are required depends upon the complexity of the final software product. Stories shown ideally encompass a week or two pf programmer's time. Once the programmer is done implementing the story, the next step is - "acceptance tests."

          Acceptance tests
Acceptance tests allow the customer to know when the system works, and tell the programmers what needs to be done. It's not a good idea to leave the testing phase to the very end, by this time, the programmers have forgotten what and how they had implemented the features. This leads to long debugging sessions and slows down the project. The code keeps on changing rapidly and the only way to move rapidly with confidence is to have a strong network of tests, both unit and acceptance, that ensure that the changes to the system don't break things that already work. The tests must be automated. Acceptance tests need to be in the same iteration in which the story is scheduled.

          Story Estimation
Customers need to know how much the stories will cost in order to choose which ones to choose and which ones to defer. During the project flow, the story time is estimated by comparison, i.e. the story being addressed is compared to a similar story that has been worked on before. If both the stories are similar in complexity and difficulty, they will take about the same time to complete. This is how programmers estimate the time it takes to finish a story. Its always a good idea to estimate in groups, this helps in reducing errors in estimation. In the beginning of the project, there are no stories to be compared to, which is why spiking is used. Spike involves writing of some sample code so that the programmer will learn enough to estimate.

Discussion:
All the tools mentioned by the author are extremely useful. I have used agile development methodology in one of my classes before and it's extremely effective. Extreme programming is a part of agile methodology, except, it's more like Agile on steroids. It aims for fast actions, rapid results and evaluation without leaving any room for errors. These tools are designed using personal experiences and I can see how they can increase efficiency, accuracy and cost effectiveness.