eXtreme Programming

Myles Standish, in his tour around Canaxia's various software development groups, finds a small team of developers utilizing eXtreme Programming (XP) practices for their project delivery (Beck 2000). The group is extremely successful at rolling out small software releases quickly and on time, but friction has been identified with this development group working with other organizations in the enterprise, such as the data warehouse group and the data center facilities. Some business customers that have familiarity with agile software development principles appreciate accelerated delivery and increased customer focus. The customers that are not familiar struggle with agile approaches since they are used to highly process oriented approaches. Another key factor is that the development team has an extensive inventory of automated test scripts already defined for ongoing maintenance and enhancement of the system. eXtreme Programming has worked well for this group, but the key for Myles is to understand how this group and its methodology can be better integrated into his plans for the enterprise architecture.

eXtreme Programming has recently become one of the most attractive approaches to software development projects for developers. In its purest form, eXtreme Programming is based upon one simple tenet: "Find the essential elements of creating good software, do them all the time, and discard everything else." During their work at Chrysler Corporation in 1996, Kent Beck and Ward Cunningham developed a lightweight approach to the controlled delivery of software products. Their inspiration for the new software methodology was to develop a practice that took all the "good activities" associated with software development and to apply them all in an extreme manner. For example, designing as a project activity is good, so make sure your developers are designing all the time. Testing the project is good, so make sure the system is constantly being tested. Since coding is good for the project, make sure to code all the time. On the other hand, heavy documentation and designing for scenarios that do not exist does not contribute to the ultimate software product, so minimize or remove these activities from the project.

A lightweight approach was needed to develop a flexible framework to handle project risks associated with dynamically changing requirements and managing unsettled project expectations. Many times, the business or customers, as they are referred to in XP do not have a firm idea of the solution they are looking to create through a software solution. Without a clear understanding of all the requirements, the development team has virtually no chance of designing and constructing a successful software product. It became obvious that a flexible and adaptive methodology was necessary to handle ongoing changes in requirements without causing huge deviations in project delivery. XP defines a series of processes and practices to improve software delivery by four basic principles:

• Feedback: First, incorporate constant feedback in requirements and design while still managing the scope, schedule, and cost of a project's delivery.

• Communication: Second, facilitate communication throughout the team through quick and effective team meetings, abbreviated requirements-gathering processes, and constant peer feedback during development.

• Simplicity: Third, promote simplicity in the design of a system, thereby enabling a developer to effectively evaluate the design immediately upon the delivery of new or changing requirements.

• Courage: Fourth, all the members of an effective XP development team must have courage in their requirements, design, code, and testing procedures. It is only through courage and confidence in these areas that the team is able to quickly and effectively respond to deviations during the development cycle.

Three major roles are identified in this lightweight methodology. They are as follows:

• Customers: Customers are identified individuals who have an intimate understanding of the business for which the application is being developed. They are responsible for authoring the initial "user stories" or requirements specifications for the project. They are available constantly throughout the delivery of the project and continue to contribute during the project's delivery in feedback sessions.

• Developers: The developer is really the central player in an XP project. They are all responsible for the design, coding, testing, and integration of the software product.

• Coaches/Managers: Coaches are the project leads who are responsible for coordinating the development activities and for ensuring that the practices of XP are followed throughout the team.

Figure 5-1 provides a detailed perspective on the structure of the iterative XP process.

Figure 5-1. Iterative XP process.

The four main practices of XP require extreme attention in the delivery cycle. Each of the practices has a series of processes and procedures identified for the development of a project. The four main practices are the following:

• Continuous Planning: The planning phase for this project is synonymous with the concept and specification phase described in the SDLC process, but the approach defined in XP defines that this practice is constantly revisited.

• Continuous Design: Directly following any planning activity, the technology team responds with quick design sessions that are organized quickly both at the team level and at the developer level.

• Continuous Coding: Coding is conducted by pairs of developers who work together to satisfy the user stories defined in the planning practice of XP's methodology.

• Continuous Testing: The developers work immediately to develop automated test scripts to create a context through which new code is to be developed.

Continuous Planning

The crux of the planning activities for an XP development project is based around the user stories, which are descriptions of smaller parts of a project's delivery. User stories are usually identified as encompassing about 1 to 3 weeks of development activity. If a user story describes more than this amount of work, the story should be broken into multiple stories. If the stories identified are representative of less than this amount of work, they should be combined with other smaller stories. The user story is solely written by the customer and is generally about three to five sentences captured on an index card or a single-page document. User stories are found more often than not as handwritten notes describing particular behaviors of a system.

The stories themselves are used for three major purposes. First, they are descriptive of the portion of the product they are meant to describe. The level of detail in these user stories is recommended to be complete enough to create dependable estimates of the implementation time. Further details the developer may require will be reviewed between the developer and the authoring customer during the actual implementation. The second purpose for the user stories is to use them for user acceptance criteria. During the testing practices of XP, automated acceptance tests must be created to verify that the code satisfies the goals of the original user story. The third purpose of the user stories is for use during release planning. XP promotes smaller and more frequent releases of an application. Generally about twenty to thirty user stories are grouped together to describe particular releases for an application. For applications with more than this many defined stories, multiple releases are scheduled for the project.

As a metric for determining the timeframe for a release, XP defines a project's velocity. The velocity of a project is simply defined as the number of user stories completed during a release schedule. If, historically, a release of about twenty-five stories takes the development team about 6 weeks to react; this metric of twenty-five stories per 6 weeks can be used to plan the schedule for future releases.

Another major tenet of XP is that the developers of a team are to be moved around. As the project progresses, domains of expertise will evolve. A major risk that projects fall into is to continue assigning the same developers to the same areas of code development. This is because the developers who are familiar with particular areas of code will implement changes and enhancements to that area more quickly. The risk is that the team begins to develop pockets of knowledge that narrow the perspective of developers. It is important that the team members move around to different areas of the project's implementation to promote cross-training and reduce the risk of creating unintentional bottlenecks in the development cycle.

Continuous Design

eXtreme Programming champions the idea that a simple design is more flexible and faster to implement than a complex design. The technology team in an XP project takes the user stories and attempts to create the simplest design of technology to satisfy the stated requirements. The key factor is that these designs be defined to be adaptive and not predictive. Predictive designs try to incorporate anticipated changes in requirements and functionality. XP dictates that the developers must focus on designing for the requirements defined in the user story. The developers must have the confidence that as new requirements are defined, they can adapt their design or redevelop a new simple design to satisfy any future requirements.

During the design phase, the technology team will adapt a system metaphor in describing the components and behavior of a system. The system metaphor is the context and convention for naming classes and methods consistently. For example, a strong system metaphor for Canaxia could be to use terminology associated with the fabrication process for a car. For data access, the components can be defined in context to procuring raw materials. For object instantiation, the processes and classes can be context for an assembly line and workstations.

One of the key products of the design phase for an XP project is the Class, Responsibility and Collaboration (CRC) Card. Each CRC Card is usually a simple index card that defines an object or behavior in a system. These cards are used during team design sessions to describe message flow among CRC cards. The team members can then provide feedback during a design session based on the layout of the cards.

The next major portion of the designing during an XP project is to execute on spike solutions. At times, it is obvious that portions of the project are vastly more complex than other portions of the system. Rather than spending time in meetings or design sessions, the team will identify an area that requires a spike solution, where a pair of developers is assigned to quickly implement (keeping the scope to within a week or two) a plausible solution to the problem. The spike solution is geared toward gathering as much information as possible about a particular technology risk and is often simply thrown away once the information from the exercise has been synthesized into the team.

Refactoring is also an essential step in all design activities. Refactoring is the process of reevaluating and recoding portions of an application to simplify the design of the code. Developers and their managers must be trained to readily revisit and recode portions of an application as soon as the simplicity and the maintenance of that code are in jeopardy.

Continuous Coding

One of the central but most difficult practices to adopt in eXtreme Programming is pair programming. Pair programming dictates that all code that is to be incorporated into a release must be developed by two developers working together at a single computer. The premise is that two developers at a single computer are cable of generating as much functionality as two developers at separate computers; the difference being that the code created under paired development will be of higher quality because every line has been scrutinized from two perspectives. As one developer drives or keys in the lines of code, the other developer is able to retain a strategic perspective on how the methods fit into a class. The second developer can also provide feedback into how to keep the code as simple as possible and to make sure all the coding standards are continually satisfied. The paired developers are expected to switch off with the keyboard, each taking turns at driving versus strategizing the development.

Along with paired programming, another shift in the preconceptions of development in an XP project is coding the unit an automated script that the developer can run to empirically observe whether a new piece of code satisfies the requirements for that component first. Essentially, if done correctly, the combined time to create a unit test and then to create the code to satisfy that test is equivalent to the time required to simply create the code from scratch. This premise is based upon the fact that unit tests help the developer keep focused on creating only the essential functionality. The obvious benefit is that all the code in the system is created from the context of measurable test scripts that can be used to accurately describe the progress of development.

Along with generating unit test code for all new development, the developers must be integrating frequently. All code should be written and integrated on a daily basis, and even more frequently if it is possible. Constant integration provides the developers with immediate feedback about problems between the code components they are building. The difficulties of integrating code so frequently are reduced with the creation of the unit test scripts that must be satisfied before integration is allowed. What this constant integration and automated unit tests also allow is that developers are empowered to modify any code throughout the system. Too often, developers must rely on one another to make sure their piece of the development is working as expected. Using these practices enables developers to simply visit any pieces of code and make whatever changes they need for integration, and then, as long as the unit tests continue to be satisfied, developers can be confident that the systems will integrate properly. This also creates a culture of collective ownership of the code base. This collective ownership empowers all the developers to enhance, fix, and maintain any piece of code in the entire project.

The next major requirement during the coding practice is that the customer must always be available during the delivery cycle of a project. The customer or the author of the user stories has provided enough details for the development team to estimate and begin the coding activities, but, since the user stories are not meant to capture every detail of an implementation, the developers must have constant access to the user to hash through details of the implementation.

Continuous Testing

As stated, testing becomes an integral component of the coding cycle for an XP project. The unit tests instill a structure to the development activities to make sure that all the functionality is empirically tracked during development. These tests enable the developer to confidently enhance, refactor, or fix any area of code in an XP project. If a developer does integrate an area of code that causes a bug, the developer has an opportunity to enhance the unit tests and make the framework of tests even more comprehensive for future enhancements to the code base. The unit tests are also a great way for the manager of a project to track to the delivery of the project. Since the unit tests are to be automated, they can simply execute the battery of unit tests at any time and track the number of passed versus failed unit tests, thereby having an empirical view of what areas of functionality are complete versus incomplete.

Another activity during testing is the creation and execution of the acceptance tests. The acceptance tests are created from the context of the user stories. It is also good practice to automate these tests. The goal of each of these tests is to identify whether the requirements of the entire user story are satisfied by the implementation.

The Benefits and Shortcomings of XP

eXtreme Programming offers a variety of benefits to a company's enterprise software development capabilities. It is a methodology that empowers developers to interact intimately with business users, thereby increasing communication and effective feedback across the development teams and the business units. The methodology takes an aggressive stance in managing risk and creating a team of stakeholders for the successful delivery of a project. Developers tend to enjoy working in the context of the documentation light methodology of XP. They are empowered to make technical decisions at every level of an application delivery project. Many times other methodologies dictate that a project architect owns the overall architecture and design of the project. XP clashes with that premise by stating that every developer is an architect, developer, and quality assurance analyst.

Also from the company's perspective, XP projects are generally easier to maintain. The knowledge capital invested in any individual developer is distributed across a team and reduces the risk of losing a critical person with unique system knowledge. The business users the customers see releases of their new systems more quickly and more frequently, and they are encouraged to participate as team members for project delivery, which in turn means educating the customer better in the practice of software development.

On the other hand, XP as a methodology is difficult to integrate into the culture of many large corporations. Paired programming is a difficult concept to receive buy in from both existing development teams and corporate management. Development has historically been a single-person activity, and development professionals tend to have a hard time switching to a two-person-to-one-computer paradigm. Also, in budgeting and structuring a project in a corporation, a development staff must be available with the business to estimate the cost and schedule for new project developments. Because XP is defined to only provide estimates through feedback from a development team, it is more costly to the company to evaluate the initial cost and size of a project with this methodology. Finally, eXtreme Programming requires that a dedicated customer representative be on the team. This is inherently difficult because users with the proper business perspective for participating as a customer must be taken from their day-to-day responsibilities to support the development team.