Extreme Programming

Extreme Programing

Introduction
Two of the greatest terms in software development these days are “Agile Software Development” and “Extreme Programming.” Both propose a different approach to software development than the traditional waterfall model and both promise productivity improvements. The methodologies appeal to many software developers, and many have embraced them. Do these methodologies work in large projects? Extreme Programming explicitly excluded projects larger than twenty people in its earliest description. In spite of this, several projects within Avaya have begun experimenting with agile software development, and Extreme Programming in particular. Their experiences, while preliminary, are providing a framework for further agile development methodology. This paper describes study of their experiences.

Agile software development
It is an approach to software that focuses on lightweight processes and adaptability to change. The best-known agile methodology is called Extreme Programming. It suggests twelve practices that include iterative development practices, automated unit testing, and pair programming.

Extreme Programming
It is a new methodology designed to help small development teams deliver value despite constantly changing requirements. Take a peek at what makes up this approach to software development and see if it might be right for your team.

XP was conceived and developed by Kent Beck, who wrote Extreme Programming Explained, The book addresses the issues faced by small development teams working in an environment of ever-changing requirements. XP is not so much a standard as it is a series of processes or methods designed to help tackle these issues. Many of the methods suggested by XP followers are intuitive and are already incorporated in some manner within common development environments.

The practices
Advocates of XP identify 12 rules (or practices) to follow during the development process:
• User stories (planning): User stories can be viewed as a watered-down version of use case. The customer defines the desired features for the new application and describes each feature's business value and priority. These are to be kept brief, with only enough detail to give an understanding of the request. The project team will employ the user stories for cost estimating and project management.
• Small releases (building blocks): With XP, you develop and deliver the application in a series of small, frequently updated versions. As each new requirement is added, complete the system and re-release.
• Metaphor (standardized naming schemes): XP systems development requires adhering to a set of standards for items such as variable names, class names, and methods. Employing this system of names should allow for the intuitive understanding of each item.
• Collective ownership: No one person owns or is responsible for individual code segments. In turn, the code is reviewed and updated by everyone on the team, allowing for a more collaborative effort.
• Coding standard: All team members write code in the same way, using the same styles and formats. This allows for rapid code sharing and reduces the learning curve for other developers.
• Simple design: The best design is the easiest one that works. A correct design for an XP system is one that runs all unit and functional tests, meets the business value, and does it only once for each function.
• Refactoring: Communication between team members is crucial. Each member should have a synchronous understanding of the application and should continually work to adjust and improve the code. This allows the system to be constantly revised without duplicating code.
• Testing: Each building block (small release) must be thoroughly tested prior to release. Write the tests first and develop the code to meet the requirements of the test. This allows for a clean application in the long term by flushing out problems before they get lost in a large application.
• Pair programming: XP programmers work in pairs. All code is developed by two programmers who work together at a single machine. The expectation is that pair programming produces higher quality code at the same or less cost.
• Continuous integration: Software builds are completed several times a day. This keeps all developers on the same page by keeping the application up to date with the most recent coding changes.
• 40-hour workweek: For XP practices to be effective, developers must be on top of their game. Experience has shown that tired or sleep-deprived developers make more mistakes and are more subject to burnout—resulting in lower-quality code.
• On-site customer: One of the most important concepts of XP is the need to have the customer as an integral part of the development effort. The customer must be available at all times to set priorities, deliver and establish requirements, and answer questions.

XP is touted as a new paradigm in the development of code by small teams. And for better or for worse, it seems to work. As you review these 12 practices, consider how many of them you already employ. There's a good chance that you've used at least one or two. But while each of these practices can stand alone, you must implement all of them to reap the benefits that XP promises.

Conclusion
Much of XP is proving to be useful to projects within Avaya. No project follows all of XP. There were two major reasons for deviance from all the XP practices. The first was that certain XP practices were not appropriate for large software projects. The second was that some practices did not fit with other practices in the existing projects. For the most part, the projects benefited from the practices they did adopt.
Large projects in other companies may benefit from adopting and adapting the practices that the Avaya projects found useful. Those projects may wish to explore agile methodologies in general, rather than focus on XP, which is most appropriate for small projects.

Principles
The principles that form the basis of XP are based on the values just described and are intended to foster decisions in a system development project. The principles are intended to be more concrete than the values and more easily translated to guidance in a practical situation.

Rules
The first version of rules for XP was published in 1999 by Don Wells at the XP website. 29 rules are given in the categories of planning, managing, designing, coding, and testing. Planning, managing and designing are called out explicitly to counter claims that XP doesn't support those activities.