Book Reading #4 Extreme Programming Installed

 
Chapters 4-6:


Chapters four, five and six covered user stories, acceptance tests, and story estimation respectively. These principals covered were more ideas of how each of the steps in the design process should go. In four we looked at user stories and how the team should handle them. There was a large emphasis on the number of stories that each team should have and how to properly write them on index cards and then tear up ones that you do not want anymore. There was also a large emphasis on making sure each card is short and only contains one idea, if at any time a programmer is unsure of how long an idea will take to put into action it is probably too long and needs to be split into two stories. This also led into how the programmers should be comfortable with ripping up index cards as many were going to be used in the entire process. The next chapter was very brief but did talk about acceptance testing. This is basically the idea that the customer is allowed to see the program in working order at many different times throughout the process. The programmers should have a working version of the program each week for the customer to see and be able to talk about what they finished in the last week as well as what they are going to do this week. It was also pointed out that this step in the process is important so the user is able to change what the programmers did if s/he so chooses. Lastly the process of story estimation was covered, whereby the programmers rate with a number how many weeks they think it will take. Typical ranges covered were .5 - 4 and if anything was going to take longer than 3-4 it was discussed that it should, again, be broken into two stories instead of one. The latter half of the chapter then gave examples of some user stories and time estimates.


Again, for me, a lot of this was a review of Agile as we learned in class. Some of these ideas are very solid and I do like they way that they are done. I think the most interesting part of this is the way that they do user stories and estimations as it is much easier to teach than the way that it was presented to us. I like that each programmer gets their own stack of cards and that bad ideas are literally thrown out and that stories that are too long are literally broken into two different stories. I also like the way they decide length of projects and how there is a grounded system for assigning points. The way we did it we assigned arbitrary values to each story letting the SCRUM master know how long we think the story would take then we discussed ideas. In the way that was presented in the book they had a grounding for how long to make each story (one, two three, or half a week) and they were able to draw upon past experiences to compare stories and determine how much time a programmer was going to need. The chapter on acceptance testing was almost too short. While it did hit some good points about how the acceptance tests enable the user to make good decisions and change ideas it didn't cover much more and left me wanting to know a little bit more about them.