Extreme programming practices and principles

¶ … Programming software development is a process of experimentation and improvement. The process of Extreme Programming is based upon the methodology's aims to be efficient, simple, and follow the key values of communication, simplicity, feedback, and courage. In a new project scenario, the process begins with collecting user stories. The development team then creates spike solutions, a complete release plan, a series of iteration and acceptance tests, and develops small releases.

Extreme Programming, often referred to as XP, is a relatively new approach to software development. First created about eight years ago by Kent Beck, Extreme Programming aimed to make software development simpler and more efficient (Wells). In addition, Extreme Programming focuses on teamwork, customer satisfaction, and aims to deliver software as quickly possible to the customer (Wells). Programming in pairs and communal ownership of code are also key to success in Extreme Programming (Kent).

The Extreme Programming methodology is based on four key values, each of which is aimed at improving any software project. These four values are: communication, simplicity, feedback, and courage (Wells).

Extreme Programming is not only a relatively new software development tool; it is also significantly different from other software development processes. Programmers who adhere to Extreme Programming often test software even before programming begins, and deliver early. Further, Extreme Programming is designed to function in many small pieces that only seem coherent when pieced together. Notes Wells, "This is a significant departure from traditional software development methods and ushers in a change in the way we program."

Given that Extreme Programming differs so significantly from traditional software development in concept, it is perhaps not surprising that the actual process of Extreme Programming is different. For example, in extreme programming, "you test first, then code" (Beck). Above all, however, Extreme Programming is innovative and experimental in its process.

Extreme Programming as a process can be used most easily in a new project. The process can begin by collecting user stories. These are written by the customers, and focus on things that the software must accomplish for them. User stories are about three sentences in length, and are written in the terminology of the customer. Developers then estimate how long it will take to implement each story (Wells).

Spike solutions are developed in order to devise answers to design and technical problems. Ideally, the spike solution is a simple solution that will address the specific problem (Wells).

User stories and spike solutions then feed into a release plan. This plan describes the entire project, and describes individual user stories in terms of ideal programming weeks (how long it would take to program the solution if there were no distractions) (Wells).

The complete release plan is then used to create iteration plans for each iteration of the project. The Extreme Programming process divides software development into about 12 iterations of one to three weeks each. Iteration plans are useful in measuring progress, and keeping planning simple (Wells).

The next step in the Extreme Programming process is acceptance tests. These are created from user stories used in iteration planning, and are automated. Quality assurance is a part of this process.

After the required series of iteration and acceptance tests, the next step in Extreme Programming is small releases. This experimental stage is designed to get feedback in time to impact the development of the project (Beck and Andres, 2004).

Extreme Programming can also be incorporated into existing projects, although the process differs somewhat from that in a new project. Wells notes, "Usually projects come looking for a new methodology like XP only after the project is in trouble." In this case, the process of Extreme Programming can begin with reviewing problems with the existing software methodology. This can include looking at requirements specifications, changing requirements, and the number of bugs in production (Wells). As in a new project, the Extreme Programming process in existing projects focuses on improvement and experimentation

One important caveat on the process of Extreme Programming is that it cannot be used successfully in large groups of programmers. Although projects with about 30 programmers have shown success with Extreme Programming, this is unusual. Extreme Programming is instead best suited to groups of 2 to 12 (Wells).