This post originated from an RSS feed registered with .NET Buzz
by Darrell Norton.
Original Post: Extreme Programming Explained: 2nd ed - Part 2
Feed Title: Darrell Norton's Blog
Feed URL: /error.htm?aspxerrorpath=/blogs/darrell.norton/Rss.aspx
Feed Description: Agile Software Development: Scrum, XP, et al with .NET
Last time we left off at the XP practices. In the second edition, Kent Beck doubles the original 12 practices and groups them into Primary Practices and Corollary Practices. The primary practices are relatively independent, that is, they add value to software development without needing any supporting practices. They should be all you need to get started experimenting with XP.
The primary practices are:
Sit together - maybe not all in one big room, but being physically closer together improves communication
Whole team - teams are cross-functional, able to handle delivering the entire application. Nothing is "thrown over the wall"
Pair programming - yes, it's still here, although in this edition Kent spends a good amount of time talking about respecting personal space ("personal hygiene and breath issues are very important")
10-minute build - the build should be automated, and it and all its tests should run in under 10 minutes. I wonder if the Windows team will ever get their builds this fast?
Continuous integration - developers should check in several times per day to reduce integration headaches
Incremental design - start simple and grow as needed, keep code quality high and technical debt low
The corollary practices are practices that are more difficult to implement, or that require the safety net of one or more primary practices. These practices, however, can substantially improve a team's performance that only uses the primary practices.
The corollary practices are:
Real customer involvement - I guess since the CHAOS report says that a lack of customer involvement is the number one reason why projects fail that this is pretty important, but you need to have your house in order before inviting the guests in
Team continuity - keep effective teams together. Sadly this is lost on most managers as they feel the need to disperse successful teams in a misguided attempt to spread "best practices"
Shrinking teams - basically all projects go through a lifecycle where staffing needs will vary depending on the stage of the project. Be aware of this, and shrink teams when necessary
Root-cause analysis - don't eliminate a defect until you know what caused it
Shared code - any team member can improve any section of the code. I haven't seen this work out too well in practice, but maybe it's just my experience so far
Code and tests - the code is the design and is the source of truth, everything should be subservient (i.e., automatically generated) to it whenever possible
Single code base - try to keep the number of development branches as low as possible, although I think you should branch when you need to
Daily deployment - only if you have a low enough defect rate
Pay-per-use - a suggestion to better align developers' and customers' interests
That's a lot of practices! And we've only vaguely referenced the idea of the "whole team". So who should be on the team? That's a discussion for next time.
Previous Topic
