In my previous article, we learn about Extreme Programming and its values. In this article, we will see all 12 core XP Practices.
12 Core Practices of Extreme Programming
![Extreme Programming]()
Reference: Ace the PMI-ACP exam book
Planning Game
In XP the main planning process is called Planning Game. There are 2 levels of plans in XP; level one is release planning and level 2 is iteration planning.
In both levels, there are 3 steps
- exploration
- commitment
- steering
The first phase is release planning. The team and stakeholders/customers collaboratively decide what are the requirements and features that can be delivered into production and when. This is done based on priorities, capacity, estimations, and risk factors of the team to deliver.
In Iteration planning the team will pick up the most valuable items from the list and break them down into tasks then estimates and a commitment to delivering at the end of the iteration.
Simple Design
In the XP, the team will not do complex or big architecture and designs upfront; instead, the team will start with a simple design and let it emerge and evolve over a period of iterations. The code is frequently refactored so that it will be maintainable and free of technical debt. Simple designs make the 'definition of done' easier.
XP teams conduct a small test or proof-of-concept workout called spike. The outcome of the spike helps the team to apprehend the validity of the hypothesis, gauge the complexity of the solution, and feel assured to estimate and build something primarily based on the test.
Test-Driven Development (TDD)
In XP Developers write the unit test cases before starting the coding. The team automates the unit tests and it helps during the build and integration stage. The main benefit of TDD is that programmers have to only write the code that passes the tests.
Basics steps of TDD
- Write the unit test case first
- Write a minimal amount of code to pass the test.
- Refactor it by adding the needed feature and functionality, While continuously making sure the tests pass.
Code Standard
Organizations want their programmers to hold to some well-described and standard style of coding called coding standards. It is a guideline for the development team as in XP. Since there are multiple programming pairs at play coding standards are very useful to make consistency in code, style, naming conversion, exception handling, and use of parameters.
These standards must be defined and agreed upon before the team starts the coding.
It will make the code simple to understand and help detect the problem or issues quickly and also increase the efficiency of the software.
Refactoring
Refactoring as the word suggests, is restructuring or reconstructing existing things. In XP over a period of time the team produces lots of working code increases the complexity and contributes to technical debt. To avoid this, we should consider the below points,
- Ensure code or functions are not duplicated.
- Ensure all variables in scope, are defined and used.
- No long functions or methods
- Removing unnecessary stuff and variables
- Proper use of access modifiers etc.
By refactoring, the programmers look to improve the overall code quality and make it more readable without altering its behavior.
Pair Programming
This is my favorite and most used practice. Pair programming consists of two programmers operating on the same code and unit tase cases, on the same system (one display and one keyboard). One programmer plays the pilot role focuses on clean code, and compiles and runs. The second one plays the role of a navigator focuses on the big picture and reviews code for improvement or refactoring.
Every hour or given a period of time this pair is allowed to switch roles so that the pilot will play the role of navigator and vice versa.
The pairs of pilots and navigators are also not fixed and they are frequently swapped, the main benefit of that over a period of time is that everyone gets to know about the code and functionality of the whole system.
Collective Code Ownership
By following pair programming practices the XP team always takes collective ownership of code. Success or failure is a collective effort and there is no blame game. There is no one key player here, so if there is a bug or issue then any developer can be called to fix it.
Continuous Integration
CI is Continuous Integration. In XP, Developers do pair programming on local versions of the code. There is a need to integrate changes made every few hours or on a daily basis so after every code compilation and build we have to integrate it so that all the tests are executed automatically for the entire project.
If the tests fail, they are fixed then and there, so that any chance of defect propagation and further problems are avoided with minimum downtime.
The team can use CI tools like Jenkins, shippable, Integrity, Azure DevOps Pipelines, etc.
Small Release
A cross-functional team in XP releases Minimum Viable Product (MVP) frequently. Small releases also help to break down complex modules into small chunks of code. This helps the developer team as well as the on-site customer to demonstrate the product and focus only on the least amount of work that has the highest priority.
System Metaphor
This is majorly connected with the user story, the story must be simple enough to be easily understood by users and developers and to relate it with code.
It could be a naming conversion practice used in design and code to have a shared understanding between teams. For example, Order_Food() is easily explained -- this will be used to order food.
It is easy for the team to relate to the functionality of the particular component by just looking at its name.
Onsite Customer
This is a similar role to a Product Owner in Scrum. The onsite customer plays a major role here and is responsible for crafting the vision, defining user stories and acceptance criteria, the definition of done, and release planning.
They are the experts who know the domain or product and know how to generate a return on investment (ROI) by delivering the minimum viable product (MVP).
If the onsite customer role is not full-time, the role can be filled with product managers, product owners, UI-UX designers, and business analysts who are called proxies.
The word “on-site” implies that the customers or their proxies sit together with the rest of the team to ensure that communication flows freely.
Sustainable Pace
This is a people-centric practice. In XP practices like TDD, continuous integration and refactoring of code help to proactively improve the quality and stability of the working software.
XP maintains a sustainable pace by introducing downtime during the iteration. The team is not doing actual development at this time but acts as a buffer to deal with uncertainties and issues. Teams can use the slack time to pay down technical debt by refactoring code or doing research to keep up the pace.
I hope you find this article helpful, kindly leave a comment and share it with your friends.