by Ron Jeffries, Ann Anderson, and Chet Hendrickson
Chapter 22 of Extreme Programming Installed is about defects and bugs in your code. The most important thing about finding defects is the way they are reported; whether you include an automated defect tool within the software or allow the customer to email them, they need to be quickly communicated and dealt with. There is also the issue of priority. If the defect is a minor fix, it can be written on a card and scheduled for the next iteration as if it was a regular user story. If the defect is a little more serious, the customer and programming team need to coordinate about priority. When a programmer is fixing a defect, they're not working on new code for the iteration, and so a few small features may need to be dropped to accommodate this new time requirement. It's also really important to try to prevent future defects. If a defect makes it to the customer, that means that it made it past the programmers' unit tests and also past the customer's acceptance tests. Examine your current tests and write a test that will make the defect appear. Then fix the defect, and now you know that future defects related to this defect will be caught before they make it to the customer.
Chapter 23 summarizes all of the concepts of Extreme Programming that make software projects more efficient and on time. XP stresses communication between programmers, managers, and customers, and mandates that a customer be on-site for in-person communication. Testing is a heavy part of the development process, and any code that is going to be released must pass all of the unit tests 100%. Programmers code in pairs, with one person working on the code and the other watching over their shoulder and asking questions to make sure they understand the meaning and also catch as many errors as possible. Planning should be minimal at the beginning, and just consist of taking features and converting them into user stories, and making initial estimates. XP stresses iterative design and programming where you are constantly tracking your project and updating design paradigms and coding estimates along the way.
Chapter 24 is about how to communicate to the customer and manager about the programmer's estimates. A lot of the time, management doesn't completely understand the difficulty and complexity of the software that is being built. As the authors explain, the programmers are usually forced to say "I'll try," and then end up working overtime and stressing themselves out to reach the deadline. Usually, even with all the hard work and stress, the deadline still isn't made. Instead, you should sit down with your customer and managers and explain the estimates. Explain that this is the amount of points you team can finish in a week, show how many points each task is estimated, and then allow them to prioritize and remove some less important stories from the iteration. Although they'll probably be frustrated and mad, you now will have a reachable deadline and can work towards that without stressing the whole team and managers out.
In all, I thought that Extreme Programming Installed was a very interesting book, and seemed to address many of the issues with programming and software development paradigms used today. I agree that design should be done along the way, because as you work on a software project you learn more about possibly implementations and get better estimates along the way. I also like the idea of open communication - waiting for an email from someone else will just hold you back and keep you from continuing your work on important issues. It's a lot easier to just walk down the hallway and get a clear answer right away so you can continue your work. Extreme Programming, if adopted by more development teams, would mean that we haves more useful software on the market that meets deadlines and has less defects and bugs, all while allowing the programming team and managers to do their job efficiently, without stress, and enjoy it along the way.
No comments:
Post a Comment