12 Core Practices In Extreme Programming XP🧙‍♂️

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

 
12 Core Practices In Extreme Programming XP
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, and 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 risks factor 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 committment 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 define and agreed before the team starts the coding.
 
It will make the code simple to understand and helps detect the problem or issues quickly and also increases 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 and it increases the complexity and that contributes technical debt. To avoid this, we should consider the below points,
  • Ensure code or functions are not duplicated. 
  • Ensure all variables in scope, 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 and focuses on clean code, and compiles and runs. The  second one plays the role of navigator and 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 benefits 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 pairs 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 where 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 breakdown complex modules in a small chunk 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 user 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 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 as Product Owner in Scrum. 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 of 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 down time 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 do research to keep up the pace.
  
I hope you find this article helpful, kindly leave a comment and share with your friends.