Extreme Programming (XP) is an agile project methodology created by Kent Beck. It is a style of management that focuses on short releases with small features, and encourages frequent communication with customers in an iterative way. In many cases, extreme programming is used when a system is required to dynamically change its functions over the period of a few months. It is a successful methodology because it boosts customer satisfaction. During development, the most important component of XP is teamwork. Everyone is involved in the project: managers, developers, testers and customers must all be partners and form a good team. There are situations when a customer isn’t sure what they want, so changing requirements and potential solutions can always be discussed and considered. This allows customers to actively participate in product development. This is why communication is a vital aspect of extreme programming.
Since extreme programming was first introduced, it has represented four key values: communication, simplicity, feedback and courage. As extreme programming developed and joined forces with software engineering, ‘respect’ became the fifth key value within this methodology. This is documented and described by Kent Beck, in his book “Extreme Programming Explained EMBRACE CHANGE”.
Software development requires continuous communication with all teams, team members and customers; this is important to understand the needs of the customer. Similarly, communication is necessary to facilitate successful collaboration between a customer and their developer. A developer’s experience can be drawn from to identify the possibilities of transforming the customer’s vision into a reality. Finally, communication is integral because it is considered the primary value in pair programming and software development in general.
First – System Feedback: unit and integration tests provide useful information to developers about implemented solutions and their elements.
Second – Customer Feedback: a functional test developed by testers and customers, which obtains details about the working system.
Third – Team Feedback: after the Customer Needs presentation, the team estimates the time they need to develop particular solutions and functions.
The team must be prepared for changes that could happen mid-way through iteration, and they should be capable of successfully and productively reacting to them. Team members involved in the project don’t need to be concerned about these changes, because they can work together to resolve them. The team is obligated to maintain transparency surrounding their progression and time estimation. Every team member is oriented to a project’s success, regardless of their individual role.
Each member of the team deserves respect, and should give it to others. Everyone from the team contributes value, even if this is simply enthusiasm. Programmers appreciate the work of testers and customer feedback, and vice versa.
In 1999, the first rules of Extreme Programming were published. These contained the key features of software development that seemed revolutionary at the time; they included fundamental principles relating to planning, managing and designing. Enumerated steps are set out in a closed loop system within Extreme Programming, and they iterate on a one-by-one basis during project development. Exemplary iteration is represented by the stages below:
"Pair programming is a dialog between two people trying to simultaneously program (and analyze and design and test) and understand together how to program better. It is a conversation at many levels, assisted by and focused on a computer... The conversational nature of pair programming also enhances the software development process"
- K. Beck, "Extreme Programming Explained"
Pair programming is a technique that involves two programmers working at a single computer, focused on one code, at the same time. The core principle of pair programming is the division of work between two programmers – a driver writes code, and an observer reviews the created code. The driver and observer switch roles frequently. This method allows the driver to focus on a complete goal, while the observer provides direction and shares their thoughts. This practice increases software quality, and the resulting code has fewer defects which could potentially be identified by the tester at a later time. Management teams must be made aware that this technique works the best in teams with well experienced programmers.