Software that performs required tasks and meets expectations; accurate estimation of time to completion and cost of development; the opportunity to decide which features to include and which to defer; frequent small releases that incorporate continual customer feedback; constant integration and automated testing that insures clean code and robust performance...These are some of the many benefits of Extreme Programming (XP), a software development approach especially geared for smaller teams facing vague or rapidly changing requirements.
Despite the "extreme" in its name, XP actually reduces risks--the risk of putting out software that is faulty, out of date at its release, over budget, or not fully capable of performing the tasks for which it was intended. Initially considered radical, XP has proven itself successful and is entering the mainstream of software development. The greatest challenge now facing software development managers and engineers is how to implement this beneficial approach.
Extreme Programming Installed explains the core principles of Extreme Programming and details each step in the XP development cycle. This book conveys the essence of the XP approach--techniques for implementation, obstacles likely to be encountered, and experience-based advice for successful execution.
You will learn the best approaches to:
*Working with an on-site customer
*Defining requirements with user "stories"
*Estimating the time and cost of each story
*Delivering small, frequent releases
*Performing constant integration and frequent iterations
*Running design sessions to help programmers move forward with confidence
*xUnit automated testing
*Handling defects in the fast-paced, team-oriented XP environment
*How to refine estimates and steer the development effort through frequent changes
The authors present the personal reflections of those who have been through the eXtreme Programming experience. Readers will benefit from firsthand accounts of hard-won wisdom on topics such as the art of estimation, managing development infrastructure, solving problems without finger-pointing, the importance of simplicity, and how to introduce modern development tools into an environment where none existed.
Review By: Bill Tuccio 05/11/2004This book details the steps involved to implement the eXtreme Programming (XP) methodology. The XP process is a series of steps that puts all project participants in tune with the pulse of the project and its deadlines. These steps include requirements broken into short user stories; the customer on-site with the programmers to adapt to changes and answer questions; programmers writing units tests before the code; continuous integration of code into builds; minimal coding to achieve functionality; pair programming; time estimates based on experience with the project; and lightweight metrics that help steer the project to completion.
Authors Ron Jeffries, Ann Anderson, and Chet Hendrickson pick up where the first XP book (eXtreme Programming Explained, by Kent Beck) left off. They describe every element of XP, leaving nothing to doubt about how an XP project should be run. Central to XP is the acknowledgement that as a product develops, the requirements are seen more clearly by both customer and programmers and that this growing experience should be used to the benefit of the project by continuous refactoring to improve code quality, adjustment of what features go in what release, adjustment of time estimates, and adjustment of metrics.
The book details the importance of unit testing every piece of code in the system and designing modules in such a way that such code is conducive to definitive unit tests. Every release requires that all unit tests are run to a 100 percent pass rate. Unit tests are distinguished from acceptance tests, which gauge-test the product against business requirements. Also emphasized is the importance of adapting to change by “steering” iterative releases. Steering involves customer’s and programmer’s reacting to experience on the project and modifying functionality to stay on the agreed track.
The authors write in a light-hearted and easy-to-understand voice that brings out the XP mood: cooperation, courage, no-nonsense metrics, and object orientated programming. XP says that each programming unit is driven by a user story and that the programming unit will be no longer than two or three weeks of work. So, too, do the authors write their book by making no chapter longer than a couple of pages that can be absorbed in fifteen or twenty minutes. When a topic needs expanding, they simply drill into it in the next chapter.
XP is defined as a discipline that is driven by and requires strong skills of both customer and programmer. The programmers need to know how to communicate, refactor, adapt to change, and listen. Customers need to know what they want in their product, how to compromise on features, how to adapt to change, and how to listen. XP demands a close working relationship with the customer so that programmers can work off minimal initial stories and fill in the details as the details emerge while coding. XP demands of all parties acceptance of a key paradigm: What they are building cannot be fully known at the outset; it will develop as the mass of the product develops.
If you’re going to implement XP, this is the book to read. It will help define the roles of all parties in the XP project, set up the work environment to prepare for the on-site customer and pair programming and ad hoc design meetings, and give all team members a common expectation of how to proceed. The authors take the time to add what they call “bonus chapters” that define some additional real-life XP experiences, including coding and steering exercises. They also start every chapter with some great cartoons that aptly introduce the content.
The book particularly helped me understand the importance and methods to achieve unit testing of 100 percent of the code on 100 percent of the releases and also how to code unit tests before coding the functionality. As a developer, that concept is something that will apply to everything I write, whether XP or otherwise.
Last, if you are trying to decide to buy this book or “eXtreme Programming eXplained” by Kent Beck, consider that “eXplained” defines the methodology and is useful for the high-level manager trying to understand if XP may work for their organization, while “Installed” is more appropriate for participants in an XP project, including customers, managers, and programmers.
To learn more about eXtreme, search StickyMinds.com on “eXtreme.”