XP

Some of the source material was extracted from here: Extreme Programming: A Gentle Introduction.

XP, originally described by Kent Beck, has emerged as one of the most popular and controversial agile methodologies. XP is a disciplined approach to delivering high-quality software quickly and continuously. It promotes high customer involvement, rapid feedback loops, continuous testing, continuous planning, and close teamwork to deliver working software at frequent intervals, typically every 1-3 weeks.

The XP recipe is based on five values – simplicity, communication, feedback, respect and courage – and twelve supporting practices:

• Planning Game
• Refactoring
• Small Releases
• Continuous Integration
• Customer Acceptance Tests
• Collective Code Ownership
• Simple Design
• Coding Standards
• Pair Programming
• Metaphor
• Test-Driven Development
• Sustainable Pace

Don Wells has depicted the XP process in a popular diagram.
In XP, the “Customer” works very closely with the development team to define and prioritize granular units of functionality referred to as “User Stories”. The development team estimates, plans, and delivers the highest priority user stories in the form of working, tested software on an iteration by iteration basis. In order to maximize productivity, the practices provide a supportive, lightweight framework to guide a team and ensure high-quality software.

Simplicity: We will do what is needed and asked for, but no more. This will maximize the value created for the investment made to date. We will take small simple steps to our goal and mitigate failures as they happen. We will create something we are proud of and maintain it long term for reasonable costs.

Communication: Everyone is part of the team and we communicate face to face daily. We will work together on everything from requirements to code. We will create the best solution to our problem that we can together.

Feedback: We will take every iteration commitment seriously by delivering working software. We demonstrate our software early and often then listen carefully and make any changes needed. We will talk about the project and adapt our process to it, not the other way around.

Respect: Everyone gives and feels the respect they deserve as a valued team member. Everyone contributes value even if it’s simply enthusiasm. Developers respect the expertise of the customers and vice versa. 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 anything because no one ever works alone. We will adapt to changes when ever they happen.

They are used to create time estimates for the release planning meeting. They are also used instead of a large requirements document. User Stories are written by the customers as things that the system needs to do for them.

User stories also drive the creation of the acceptance tests. One or more automated acceptance tests must be created to verify the user story has been correctly implemented.

Developers estimate how long the stories might take to implement. Each story will get a 1, 2 or 3 week estimate in “ideal development time”.

Longer than 3 weeks means to break the story down further. Less than 1 week means at too detailed a level, combine some stories. About 80 user stories plus or minus 20 is a perfect number to create a release plan during release planning.

A release planning meeting is used to create a release plan, which lays out the overall project. The release plan is then used to create iteration plans for each individual iteration.

An ideal week is how long you imagine it would take to implement that story if you had absolutely nothing else to do.

The customer then decides what story is the most important or has the highest priority to be completed. (Exploration Phase).

Developers and customers move the cards around on a large table to create a set of stories to be implemented as the first (or next) release. (Commitment Phase).

Plan by time or by scope. The project velocity is used to determine either how many stories can be implemented before a given date (time) or how long a set of stories will take to finish (scope). (Steering Phase).

Individual iterations are planned in detail just before each iteration begins and not in advance. The release planning meeting was called the planning game.

The base philosophy of release planning is that a project may be quantified by four variables; scope, resources, time, and quality. Scope is how much is to be done. Resources are how many people are available. Time is when the project or release will be done. And quality is how good the software will be and how well tested it will be.

This plans the activities and tasks of the developers. In this process the customer is not involved. Iteration Planning also consists of three phases:

Exploration Phase: The requirement will be translated to different tasks. The tasks are recorded on task cards.

Commitment Phase: The tasks will be assigned to the programmers and the time it takes to complete will be estimated.

Steering Phase: The tasks are performed and the end result is matched with the original user story.

Iterative Development adds agility to the development process. Divide the development schedule into about a dozen iterations of 1 to 3 weeks in length. One week is the best choice even though it seems very short.

Don’t schedule programming tasks in advance. Instead have an iteration planning meeting at the beginning of each iteration to plan out what will be done. Just-in-time planning is an easy way to stay on top of changing user requirements.

If it looks like tasks will not be completed then call another iteration planning meeting, re-estimate and remove some of the tasks.

An iteration planning meeting is called at the beginning of each iteration to produce that iteration’s plan of programming tasks. Each iteration is 1 to 3 weeks long. User stories are chosen for this iteration by the customer from the release plan in order of the most valuable to the customer first. Failed acceptance tests to be fixed are also selected. The customer selects user stories with estimates that total up to the project velocity from the last iteration.

The user stories and failed tests are broken down into the programming tasks that will support them. Tasks are written down on index cards like user stories. While user stories are in the customer’s language, tasks are in the developer’s language. Duplicate tasks can be removed. These task cards will be the detailed plan for the iteration.

Developers sign up to do the tasks and then estimate how long their own tasks will take to complete. It is important for the developer who accepts a task to also be the one who estimates how long it will take to finish. Each task should be estimated as 1, 2, or 3 (add 1/2 if you need to) ideal programming days in duration.

Total up the time estimates in ideal programming days of the tasks, this must not exceed the project velocity from the previous iteration.

We computer programmers hold onto our software designs long after they have become unwieldy. We continue to use and reuse code that is no longer maintainable because it still works in some way and we are afraid to modify it. But is it really cost effective to do so?

Extreme Programming (XP) takes the stance that it is not. When we remove redundancy, eliminate unused functionality, and rejuvenate obsolete designs we are refactoring. Refactoring throughout the entire project life cycle saves time and increases quality

Refactor mercilessly to keep the design simple and to avoid needless clutter and complexity. Keep code clean and concise so it is easier to understand, modify, and extend. Make sure everything is expressed once. It takes less time to produce a system that is well groomed.

There is a certain amount of Zen to refactoring. It is hard at first because you must be able to let go of that perfect design you have envisioned and accept the design that was serendipitously discovered for you by refactoring. You must realize that the design you envisioned was a good guide post, but is now obsolete.

All code to be sent into production is created by two people working together at a single computer. Pair programming increases software quality without impacting time to deliver. It is counter intuitive, but 2 people working at a single computer will add as much functionality as two working separately except that it will be much higher in quality.

The best way to pair program is to just sit side by side in front of the monitor. Slide the key board and mouse back and forth. Both programmers concentrate on the code being written.

Pair programming is a social skill that takes time to learn. You are striving for a cooperative way to work that includes give and take from both partners regardless of corporate status. The best pair programmers know when to say “let’s try your idea first.” It helps if you have someone on your team with experience to show everyone what it should feel like.

One thing pair programming is not is mentoring. A teacher-student relationship feels very different from two people working together as equals even if one has significantly more experience. It takes time to get used to pair programming so don’t worry if it feels awkward at first.

When you create your tests first, before the code, you will find it much easier and faster to create your code. The combined time it takes to create a unit test and create some code to make it pass is about the same as just coding it up straight away. But, if you already have the unit tests you don’t need to create them after the code saving you some time now and lots later.

Creating a unit test helps a developer to really consider what needs to be done. Requirements are nailed down firmly by tests. There can be no misunderstanding a specification written in the form of executable code.

You also have immediate feedback while you work. It is often not clear when a developer has finished all the necessary functionality. Scope creep can occur as extensions and error conditions are considered. If we create our unit tests first then we know when we are done; the unit tests all run.

There is also a benefit to system design. It is often very difficult to unit test some software systems. These systems are typically built code first and testing second, often by a different team entirely. By creating tests first your design will be influenced by a desire to test everything of value to your customer. Your design will reflect this by being easier to test.