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.
Principles 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:
- Planning – planning game
The planning game is a meeting that performs once per iteration. Firstly, the customer holds a presentation to introduce their needs for the system, and identifies their high-priority targets to the wider team. This information is documented in user stories. It is useful to refer to customer needs in this way, using language that is relevant for the customer. After this presentation the team begins building a schedule, and divides projects into small iterations. An iteration shouldn’t last any longer than three weeks. It is good practice to create a timeline or chart to visualize a schedule in a readable way. The second part of planning a game is dividing tasks and activities, and forwarding them to developers.
The management team should create a comfortable workspace for the team involved in project development, and prepare developers to work collaboratively with them. Each developer should be designated tasks that are relevant to their knowledge and skills. The schedule created by the Project Manager should cover daily meetings and the estimated rate of project velocity.
Kent Beck and Ward Cunningham created Class-Responsibility-Collaboration cards which explain system design, and clearly identify how elements of design interact with each other. Everything should be simplified because basic elements can become more complex, but not always vice versa. Project features created in a time-pressured environment have the potential to become problematic at a later stage. However, if they are identified and resolved early on in the project timeline, then these problems can be avoided.
The most important thing for developers to ensure is that their code is clean, and that they preserve all code standards. Everyone should take responsibility for this. Every feature of a project is integrated in a continuous way, to keep the project alive. The customer needs to be permanently available to work with developers to ensure this. A frequent practice involved in coding is pair programming insertion, which involves two programmers working on one part of code.
The developer team works in close cooperation with testers, so that all bugs are detected and fixed during one iteration before release.
FOR DEVS – Pair programming
“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.
- Large projects are divided into smaller, manageable iterations with small releases
- The process saves costs and time because it requires minimal documentation
- The simplicity of code and design provides quality results and fewer defects
- Risk mitigation is managed by multiple team members
- This process is focused on code instead of design
- Detailed planning is required from the start, and dynamic changes should be anticipated which could increase costs and time
- Significant discipline is required from the team. The customer is also expected to be constantly available, which incurs greater costs. This could also become inconvenient for the customer.
- To practise pair programming, experienced developers are required, with expert knowledge.