Soapbox - eXtreme Programming Development through Dialog

T o those who are unfamiliar with the method, eXtreme Programming might conjure up visions of programmers madly hacking away without concern for analysis, architecture, design, or consequences. Indeed, people have frequently made such accusations. Yet such claims are not only baseless, they are dia-metrically opposed to what XP is all about. XP is the brainchild of Kent Beck, and he describes it in his landmark book eXtreme Programming Explained (Addison-Wesley, 2000). (A review of this book appears on page 113 in this issue.) It is a software development method that views people, rather than paper, as a project's most potent element. Its primary motive is to start a dialog between the people involved in a project. It facilitates this by identifying the parties in the conversation and arming them with the clear knowledge of what they are responsible for communicating to others. The Dialog The two primary roles in XP are customer and programmer. The customer is the person or group who represents the users. The customer is responsible for identifying the features (known as stories) that the programmers must implement, providing detailed acceptance tests for those stories and assigning priority to them. Thus, the programmers should implement the stories the customer wants, in the order the customer wants, and pass any tests that the customer specifies. Programmers may not implement anything that the customer does not explicitly request. On the other hand, programmers are responsible for estimating how long it will take to implement the stories. Customers may not question or challenge those estimates or make commitments to third parties that do not reflect those estimates. With this division of responsibility in place, it is clear that a project plan represents a dialog between the customer and programmers. The protocol of that dialog is also clear. The customer tells the programmers what stories he or she wants in the next iteration. The programmers add up the estimates for those stories and tell the customer whether they are possible. The customer can remove or swap stories but can't get more in the iteration than the programmers estimate is possible. The programmers can tell the customer how long something will take, but they can't select the stories to be implemented. How could this possibly work? After all, no customer is going to simply accept the pro-grammers' estimates; instead, the customer will push back on those estimates, demand better performance, and …