By Alan Zeichick
Its not extreme, and its not about programming. The disciplineor religion or processof Extreme Programming (XP), pioneered by Kent Beck, is all about managing, motivating and empowering teams of software developers to deliver high-quality software on time, under budget and with fewer-than-usual defects.
But the process, clearly laid out in Becks original book, Extreme Programming Explained (Addison-Wesley, 2000), contains specific requirements. For example: Nobody writes any code until after they build automated software test cases that verify that the code meets its formal requirements. Programmers work in pairs, so that they can explain to each other what theyre doing. All programmers are allowed, nay encouraged, to constantly fiddle with every piece of code in the project, so that they can refactor and simplify the code. The project itself is broken into short chunks, each of which might take one to three weeks to implement, test and deliver. Customers should be deeply involved with the development process, and are encouraged to prioritize and reprioritize features and functionality. And its better to deliver partial functionality immediately, and then add new functionality in small incremental releases, than to wait to deliver everything all at once.
Its hard to argue with most of those ideals, though others seem to be either counterproductive or even downright dangerous. Should anyone on a major development team really be allowed to recode any module at any time? Beck says yes: As long as the code can pass its tests, constant refactoring can only improve the product. That may seem fine to you; but to me, its an invitation for chaos in all but the smallest development teams.
Becks latest book, Planning Extreme Programming, co-authored with Martin Fowler, offers guidance to project managers who are interested in XP but dont know how to plan projects based on its principles.
Planning begins with a breezy manifesto about the importance of planning software projects and of including the customer in every step of the plan. Business people make business decisions, and technical people make technical decisions, say the authors, meaning that the business peoplethe customersshould make all decisions regarding delivery dates, project scope and functional priorities. The developers, of course, must provide accurate cost and time estimates to the customer, but ultimately its the customers responsibility to make the hard decisions, every step of the way.
TELLING A STORY
Once project managers (and customers) accept their roles, say Beck and Fowler, customers begin writing user stories, which describe discrete features of the project. The XP methodology (if you can call XP a methodology) is to describe each story in a simple sentence or two, such as The system should check the spelling of all words entered in the comments field, written out on an index card.
User stories should be independent of each other, short enough to be coded and delivered in a few weeks, and testable using automated test suites. On a regular basis, the project manager reviews the stories with the programmers, recasts if necessary longer stories into multiple short stories, and develops estimates as to the cost and time required to build each storys functionality in the project. The customer then sets priorities based on business goals as well as technical dependencies (theres no point spell-checking a data-entry field if that field has not been added yet), and the project manager hands out the highest-priority story cards to the projects programmer teams. When the programmers are finished, the process repeats itself.
If the story-by-story development scheme is going to work, the project and team must be able to deliver accurate estimates to the customer. XP keeps the estimation process simpletheres no function-point analysis here! Rather, each user story should be short enough that after a little practice, the project manager can estimate its complexity, primarily by comparing it with other stories that have been completed. In some cases, members of the project team might have different estimates. In that case, say Beck and Fowler, go with the shortest one, to keep the project moving and stop the programmers from being too conservative.
The user-story writing, review and coding cycle, the book argues, is XPs strength. Because nobody is asked to commit to a complete specification of an entire project up front, and customers can change or add new stories at any time, XP is inherently flexible and adaptable to rapidly changing business needs. But that flexibility must be tempered with realityif requirements are always changing, then the project never gets completed. The solution to that is the release plan, which specifies a series of dates, perhaps a few months apart, on which the team will stop and deploy whats written to the customer. Even if a few user-story estimates prove to be too optimistic, the release dates should be inviolate: Nothing erodes confidence faster than missing deadlines.
Extreme Programming certainly lends itself better to some types of projects than others. An e-commerce Web site, end-user application or collection of components? Yes, incremental feature-by-feature evolution is a good way to go. The firmware for the Space Shuttle, an operating system or a standards-based compiler? Hmm, probably not. For big projects with firm specifications, traditional requirement-gathering, estimation and management techniques are better, and XP need not apply. If you work on the formeror even if you work on the latterread this book. Its casual yet pragmatic attitude toward software development management, like XP itself, is a breath of fresh air.
Reprinted with permission of SDTimes. Originally appeared in Issue 22, January 15, 2001.