Extreme Programming (XP) is a lightweight methodology that enables small teams of developers to achieve breakthrough productivity and software quality, even when faced with rapidly changing or unclear requirements. In this new book, top object-oriented consultants James Newkirk and Robert Martin walk through an entire XP project, chronicling the adoption of XP by a team that has never used it before. Along the way, they show how to overcome the obstacles facing XP adopters, and present realistic XP best practices virtually any development organization can benefit from. The case study in this book is real, driven by the needs of a real customer. The artifacts, code, user stories, and anecdotes are all real, drawn from videotaped meetings throughout the project's development process. The result: an exceptionally true-to-life narrative, complete with mistakes and false starts, and reflecting the ebb and flow of a real project. For organizations considering XP, this may be the most realistic and useful guide ever produced. For project managers, developers, software engineers, XP customers, and upper-level managers.

Review:

Theory is fine but practice makes perfect. Extreme Programming in Practice is the story of the Object Mentor company's first foray into XP after the Web site it designed and implemented failed. It takes chutzpah to use your own incompetence as a lesson for others.

OK, the "customer" here is internal but the processes the team went through were intended to be identical to those it would use with an external customer. The project was the site-registration system--the part that had failed. There was no question of fixing it, instead the team sat down with its "customer" and started from scratch.

The resulting story as told in Extreme Programming In Practice is fascinating because it's real. By chapter six the authors have already come unstuck through not using automatic testing on code, allowing the "customer" to miss iteration meetings, creating overlong iterations and implementing infrastructure code before the tasks dependent on them. What's especially interesting is that the authors knew what XP said they should be doing yet, for various perceived reasons: internal politics, other work and existing practices among others, chose to do something different.

Almost all these choices caused problems. These ranged from poor time estimates and lots of infrastructure reworking to simply delivering the "wrong" features. Object Mentor learned a lot from its mistakes and if you're about to try XP, you could too, saving a lot of time, money and credibility. --Steve Patient

"About this title" may belong to another edition of this title.

Store Description

Visit Seller's Storefront