Extreme Programming Perspectives by Giancarlo Succi, Michele Marchesi, Laurie Williams, Williams, James Donovan Wells

From the Publisher

Extreme Programming (XP) has been established as a significant departure from traditional software development methods. The success of the XP 2001 and XP Universe 2001 conferences is no surprise; some of the brightest minds in software engineering gathered at these venues to discuss the discipline that is XP. These conferences showcase the continuously changing face of XP. Common programming practices will never be the same, and developers and business people alike need to bear this fact in mind as they plan for the future.

Inspired by the techniques and challenges explored at these conferences, Extreme Programming Perspectives presents 47 articles that represent the insights and practical wisdom of the leaders of the XP community. Encompassing a wide variety of key topics on XP and other agile methodologies, this book offers experience-based techniques for implementing XP effectively and provides successful transitioning strategies. Articles are grouped into six main sections: an overview of XP and agile methodologies; XP development practices; issues involved in transitioning to XP and agile methodologies; real-life experiences of working with XP; tools for facilitating XP development; and finally, ideas for expanding and extending XP.

You will find such outstanding articles as:

Product Details

• Table of Contents
• Forewords & Introductions
• Read an Excerpt

Table of Contents

Forewords & Introductions

Writing a book about new software development methodologies can be a very easy and a very difficult task together.

It could be very easy, as you could talk about very generic and high-level vaporware without ever entering details, and backing your approach with statements such as “it requires customization,” “no silver bullets,” and other politically correct statements.

You could take the completely opposite approach, and still have a fairly easy task if you have ever run a project with your methodology. You could enter a detailed description of what you did, distilling a complete approach around your individual idiosyncrasies. Best would be if you add something esoteric, such as typing into the keyboard with only the right hand, and using the left to hold a silk napkin with whom you would clean your sweater every other minute.

This is not because software authors are bad by nature. We should remember that in the early days of the studies in electronics, the equation for the resistor was awfully complex, with lots of terms which were really insignificant. Nowadays, it is a simple algebraic division: R=V/I.

However, writing about a new methodology becomes dreadfully difficult if you aim at creating something really valuable for the reader, combining the limited theoretical understanding with the limited experimental evidence, and avoiding a terse language.

This book takes this latter approach. We combine an overview of XP, from the hand of the people who proposed it, description of experiences in specific areas yet unclear and subjectto debate, and an empirical evaluation of how XP projects are progressing in software companies.

The first section is the overview of the methodology. We assume that you have already read the cult books, Kent’s, Martin’s, Ron’s, Jim’s, etc. So we summarize all the foundations in one chapter, by Don.

In Chapter 2, Jim Highsmith presents the essence of “Agility.” This insightful chapter goes in the depth of Agile Methodologies and explains the rationale behind any agile proposal.

The large number of Agile Methodologies may disorient software managers and engineers. To this end, Michele provides guidelines to select which among the several Agile Methodologies best suits your environment (Chapter 3).

Most likely people thinking at XP, associate it to Pair Programming. Detractors say that it is only a fad, which wastes time and money of software companies. Supporters are convinced that it is the philosopher store of software development. In Chapter 4, Laurie discusses the principles of Pair Programming, details when and how to adopt it, and summarizes the expected benefits.

An effective analysis in XP is centered in the ability to find a suitable metaphor. This is not an easy task, especially when the project gets larger and more complex. In Chapter 5, William and Steven Wake focus on the issue of metaphor. In particular, they detail their approach in finding a metaphor, in relating the objects of the system to it, and in evaluating whether there are “bad metaphors.”

XP is not cowboy coding, neither completely uncontrolled development. It is the opposite of them. But how is it possible to couple an agile approach with measurements and process control? They look like an antinomy. In Chapter 6, Giancarlo discussed possible avenues to implement an agile measurement program, taking advantage of sources of data naturally available to software engineers and managers.

What is the extent to which each individual practice of XP is useful? How much of them should we keep in our project for our project to be successful? What is the level of customization of the practices that we can safely have? In Chapter 7, Ron attempts to address these tricky issues that managers pose every day. He analyses the most relevant practices and concludes with a caveat toward to “agile” customizations.

Last but not the least, Michele explains how it is possible to hit your targets using XP. He explains how to align business and technical goals, and outlines possible problems that you may face when implementing an XP project and how to solve them.

Read an Excerpt

Welcome to yet another book on Extreme Programming—and Agile Methodologies, of course!

Writing a book about new software development methodologies can be a very easy and a very difficult task together.

It could be very easy, as you could talk about very generic and high-level vaporware without ever entering details, and backing your approach with statements such as “it requires customization,” “no silver bullets,” and other politically correct statements.

You could take the completely opposite approach, and still have a fairly easy task if you have ever run a project with your methodology. You could enter a detailed description of what you did, distilling a complete approach around your individual idiosyncrasies. Best would be if you add something esoteric, such as typing into the keyboard with only the right hand, and using the left to hold a silk napkin with whom you would clean your sweater every other minute.

This is not because software authors are bad by nature. We should remember that in the early days of the studies in electronics, the equation for the resistor was awfully complex, with lots of terms which were really insignificant. Nowadays, it is a simple algebraic division: R=V/I.

However, writing about a new methodology becomes dreadfully difficult if you aim at creating something really valuable for the reader, combining the limited theoretical understanding with the limited experimental evidence, and avoiding a terse language.

This book takes this latter approach. We combine an overview of XP, from the hand of the people who proposed it, description of experiences in specific areas yet unclear andsubject to debate, and an empirical evaluation of how XP projects are progressing in software companies.

The first section is the overview of the methodology. We assume that you have already read the cult books, Kent’s, Martin’s, Ron’s, Jim’s, etc. So we summarize all the foundations in one chapter, by Don.

In Chapter 2, Jim Highsmith presents the essence of “Agility.” This insightful chapter goes in the depth of Agile Methodologies and explains the rationale behind any agile proposal.

The large number of Agile Methodologies may disorient software managers and engineers. To this end, Michele provides guidelines to select which among the several Agile Methodologies best suits your environment (Chapter 3).

Most likely people thinking at XP, associate it to Pair Programming. Detractors say that it is only a fad, which wastes time and money of software companies. Supporters are convinced that it is the philosopher store of software development. In Chapter 4, Laurie discusses the principles of Pair Programming, details when and how to adopt it, and summarizes the expected benefits.

An effective analysis in XP is centered in the ability to find a suitable metaphor. This is not an easy task, especially when the project gets larger and more complex. In Chapter 5, William and Steven Wake focus on the issue of metaphor. In particular, they detail their approach in finding a metaphor, in relating the objects of the system to it, and in evaluating whether there are “bad metaphors.”

XP is not cowboy coding, neither completely uncontrolled development. It is the opposite of them. But how is it possible to couple an agile approach with measurements and process control? They look like an antinomy. In Chapter 6, Giancarlo discussed possible avenues to implement an agile measurement program, taking advantage of sources of data naturally available to software engineers and managers.

What is the extent to which each individual practice of XP is useful? How much of them should we keep in our project for our project to be successful? What is the level of customization of the practices that we can safely have? In Chapter 7, Ron attempts to address these tricky issues that managers pose every day. He analyses the most relevant practices and concludes with a caveat toward to “agile” customizations.

Last but not the least, Michele explains how it is possible to hit your targets using XP. He explains how to align business and technical goals, and outlines possible problems that you may face when implementing an XP project and how to solve them.