What is Extreme Programming (XP) and What are its Goals?
Extreme Programming is a systematic approach with a set of values, rules and practices for rapidly developing high quality software that provides the highest value for customers. Traditional Extreme Programming methodology demands that developers have to perform test-first strategy and code re-factoring. On one hand, the test-first strategy asks developers to write test cases before coding, while on the other hand re-factoring practice requests them to revise code frequently. [4] The goal of Extreme programming is to attempt to reduce the cost of changes in requirements by having multiple short development cycles, rather than a long one. Changes are a natural, inescapable and desirable aspect of software-development projects, and should be planned for, instead of attempting to define a stable set of requirements.[21]
The most surprising aspects of Extreme Programming Methodology are its simple rules. The rules may seem awkward and perhaps even naive at first, but are based on sound values and principles. [16] The rules for Extreme Programming Methodology are outlined and explained below.
Extreme Programming is a systematic approach with a set of values, rules and practices for rapidly developing high quality software that provides the highest value for customers. Traditional Extreme Programming methodology demands that developers have to perform test-first strategy and code re-factoring. On one hand, the test-first strategy asks developers to write test cases before coding, while on the other hand re-factoring practice requests them to revise code frequently. [4] The goal of Extreme programming is to attempt to reduce the cost of changes in requirements by having multiple short development cycles, rather than a long one. Changes are a natural, inescapable and desirable aspect of software-development projects, and should be planned for, instead of attempting to define a stable set of requirements.[21]
Improvement of Development Projects through Extreme Programming (XP) Methodology Values:
Extreme Programming (XP) is based on values. The following Extreme Programming Values are more than just a marketing stunt, they are more important than practices. [16]
- Simplicity: What is needed will be done and no more, which will maximize value created for investment made to date. Small steps will be taken and failures will be mitigated as they happen. The project developed will be maintained long term at reasonable cost.[16]
- Communication: Everyone is part of the team, and daily communication is face to face. Team works together on everything from requirements to code. The best solution to problem will be developed together.
- Feedback: Every iteration commitment will be taken seriously to deliver working software. Software is demonstrated early while the developers listen carefully to feedback and make any changes necessary.
- Respect: Everyone gives and receives the respect deserved as a valued team member. Management respects our right to accept responsibility and receive authority over our own work.
- Courage: We will tell the truth about progress and estimates. We don't document excuses for failure because we plan to succeed. We don't fear the job at hand because no one works alone. We adopt to changes whenever they happen.
The most surprising aspects of Extreme Programming Methodology are its simple rules. The rules may seem awkward and perhaps even naive at first, but are based on sound values and principles. [16] The rules for Extreme Programming Methodology are outlined and explained below.
- Planning: In the planning stage user stories are written. User stories are used to create time estimates for release planning meeting. In this stage developers are frequently releasing small releases of iterative versions of the system to customers. And project is divided into iterations. Iterations are scheduled for one to three weeks in length.
- Managing: This rule requires that the work space be open and barriers such as cubicles that divide people be taken down. Setting up pace is having the most completed and production ready software each iteration.This rule also requires to move people around to avoid serious knowledge loss and coding bottle necks.This rule also requires a stand up meeting. most attendees do not contribute, but attend just to hear the outcome. A large amount of developer time is sacrificed to gain a trivial amount of communication.
- Designing: This rule requires that designing a model must have simplicity to it. A simple model always takes less to finish than a complex one. Spike solutions are required by this rule which serve to figure out answers to tough technical and design problems. A spike solution is a very simple program to explore potential solutions. This rule also requires for functionality to never be added early since only 10% of the extra stuff will ever get used.
- Coding: This rule requires that the customer always be available, not only to help the development team but to be a part of it as well. This rule also requires code to be written to agreed standards. It is required of the Coding rule to create the test first before creating the code because it will be much easier to create the code later. Collective ownership encourages everyone to contribute new ideas to all segments of the project.
- Testing: All code must undergo unit tests, unit tests are the corner stones of Extreme Programming. When a bug is found tests are created to guard against it coming back. Acceptance tests are created from user stories. During iteration the user stories selected during the iteration planning meeting will be translated into acceptance tests.
Customers enjoy being partners in the software process, developers actively contribute regardless of experience level, and managers concentrate on communication and relationships. Unproductive activities have been trimmed to reduce costs and frustration of everyone involved. [16]
Extreme Programming Core Practices:
Extreme Programming methodology, used to implement software projects, consists of twelve core practices grouped into four areas, derived from the best practices of software engineering.
- Fine Scale Feedback:
- Pair Programming: Two people participate in one development effort on one workstation. Each member performs the action the other is not currently doing. One maybe typing a unit test while the other thinks about the class that will satisfy the test. [22]
- Planning Game: This practice is where developers develop a little emotional distance from planning by treating it as a game. The game has a goal, playing pieces, players and rules for allowable moves. Playing piece is the user story. The goal is to put the greatest value of stories into production over the life of the game. Players are developers and customers.
- Whole Team: This practice is considered putting everyone who is involved in the development of the project in one room. This would limit the size of the largest projects.
- Unit Tests: Under the strict definition of this practice, for Questions and Analysis purposes, a failure of a unit test implicates only one unit. You know exactly where to search for the bug when using Unit Testing.
- Continuous Integration: The macro process of object-oriented development is one of "continuous integration." Each time someones code improves, they should send each re-factor and addition that improved it to all the other developers. [22]
- Design Improvement: Design improvements does not always mean re-factoring. Sometimes it means convincing people to remove features in the code that are not really needed anymore, or which will never be needed for the current release of the product.
- Small Releases: Small releases are core practice of Extreme Programming. Each cycle is short and you only provide the code for a very small set of functionality.
3. Shared Understanding:
- Simple Design: Doing that which does not have Business Value is wasteful, therefore developers should stick to a simple design and avoid complex designs. [22]
- System Metaphor: Extreme Programming uses metaphors to unify an architecture and provide naming conventions. Metaphor is a simple shared story of how the system works. This story typically involves a handful of classes and patterns that shape the core flow of the system being built.
- Collective Code Ownership: Extreme Programming considers code to belong to the project, not the individual engineer. As engineers develop required functionality, they may browse into and modify any class. They are responsible for keep all the Unit Tests running.
- Coding Standard: - Here, developers on a team are having a hard time agreeing on a naming standard. Some prefer BumbyCase (example: dueDate), while others prefer underscores (example: due_date). BumpyCase has the advantage because it makes individual program statements a little shorter and less likely to wrap across multiple lines.
4. Programmer Welfare:
- Sustainable Pace: The rule should be called sustainable pace not forty hour work week. The productivity does not increase with hours work. Tired developers are less productive then well-rested ones. [22]