What is Extreme Programming (XP) - Values, Process Activities

Zia

2 Followers

Follow

May 26, 2024

-

1 sec read

371

0

0

0

Introduction

Extreme Programming (XP) is one of the many popular Agile processes. It concentrates on software development rather than software project management. The first XP project was started in March 1996. XP was designed in such a way that organizations could either adopt the whole methodology or parts. This process has been proven to be very successful for many companies worldwide.

The main focus of XP is customer satisfaction. This process delivers the software as and when it is required rather than delivering everything in bulk, at the end. The advantage of XP is that it empowers. Developers can handle changes in customer requirements confidently, even late in the life cycle.

XP also emphasizes teamwork. Customers, developers, and managers coordinate as a team and work together as equal partners. This methodology enables teams to become highly productive by implementing a simple and effective environment. The team organizes itself around the issues and efficiently solves them.

XP methodology brings together the whole team with the help of simple practices. It also provides feedback which enables the team to see where they are and helps them to adapt practices to their unique situation. In XP, every contributor to the project is an indispensable part of the whole team. The customer is also an integral part of the team who sits along with the team and works with them daily.

The primary practices of XP are as follows:

• Sit together: The whole development team sits and operates in one single open space.
  
  
• Cross-functional team: XP utilizes a cross-functional team consisting of everyone essential to the success of the product.
  
  
• Informative workspace: XP encourages an informative workplace by placing informative charts around the workspace so that team members and stakeholders get an idea of the status and progress of the project.
  
  
• Energized team: XP teams are not encouraged to work overtime. The idea behind this is to keep the quality of the code high and the programmers happy.
  
  
• Pair programming: This refers to the practice where two programmers work together on one computer, working on the same design of production software.
  
  
• User stories: The team writes short statements of customer-visible functionality required in the product. The customer prioritizes the stories and the developers estimate them.
  
  
• Weekly cycle: A meeting is held at the beginning of each week to review the progress of the project. The customer decides on the stories that are to be implemented that week and divides them into tasks. By the end of the week, acceptance test cases for these stories should be ready for demonstration to the customer. The feedback from this will drive the next weekly cycle.
  
  
• Quarterly cycle: The whole team picks a theme or theme for the quarter. Themes enable the team to reflect on the bigger picture. This business value is delivered at the end of the quarter.
  
  
• Slack: In each iteration, a few of the lower-priority tasks are planned, so that they can be dropped if the team lags in their work. This way, the most important functionality is still delivered to the customer.
  
  
• Ten-minute build: The project structure is designed in a way that facilitates frequent testing. This allows tests to be run in ten minutes. This practice promotes regular testing.
  
  
• Test-first programming: All stories have at least one preferably automated acceptance test. The user story is considered fulfilled when it passes the acceptance test. Automated unit tests are also incrementally written using Test-Driven Development (TDD) practices. TDD is a software development process that relies on the repetition of a very short development cycle. First, the developer writes an automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards.
  
  
• Continuous integration: Programmers check in on the completed code and the associated tests several times a day. Code is only checked in if all associated unit tests are passed.
  
  
• Incremental design: Rather than designing the whole system in advance, it is designed every day using the experience gained from the previous day. Refactoring is done to improve the design of previously written code. Teams with strong unit tests can safely experiment with refactoring as a safety net is in place.
  
  
  

Values of Extreme Programming

XP has well-defined practices and guidelines. The first step in the process is collecting short use cases which can be put on an index card. The short use cases or stories as they are called, must be testable, esumable, and business-oriented. The customer prioritizes the stories and selects the most valuable ones. This group makes up an iteration and is coded first. Coding is done in pairs, where two people code on one machine, and an iteration is typically one to two weeks long. Once the coding is complete, the code is tested and put into production.

XP methodology is based on five values:

• Communication
• Feedback
• Simplicity
• Respect
• Courage
  
  
• Communication: XP has an oral communication culture and its practices encourage interaction. Communication is given importance based on the observation that issues in most projects occur due to a lack of communication.
  
  
• Feedback: The customer provides feedback to the development team at the end of each iteration and release. This feedback drives the next iteration. Design and implementation feedback loops are also built into the.
  
  
• Simplicity: An important aspect of this value is to design and code only what is in the current requirements and develop the simplest product that meets the customer's requirements.
  
  
• Respect: Team members are to respect each other as valued team members. They must also respect customers' expertise.
  
  
• Courage: Other values such as transparency about project progress and estimates enable the team to be courageous in its performance and decisions.
  
  
  

XP Process Activities

The life cycle of XP consists of phases:

• Exploration
• Planning
• Iterations to Release
• Productionizing
• Maintenance
• Death
  
  
• Exploration Phase: In this phase, the customers write the story cards that they desire to include in the first release. The story cards describe the features to be added to the program. Meanwhile, the project team familiarizes themselves with the project, including the technology, tools, and practices that are to be used. The team builds a prototype of the system to check its technology and architectural capabilities. The duration of the exploration phase depends on how familiar the programmers are with the technology and takes anywhere between a few weeks and a few months. Paradigm
  
  
• Planning Phase: This phase usually takes a couple of days. In this phase, the stories are prioritized and the contents of the first release are decided. The schedule is drawn after the programmers estimate the effort required for each story. The scheduled duration of the first release normally does not exceed two months.
  
  
• Iterations to Release Phase: This phase includes several iterations of the system before the first release. The schedule fixed in the planning phase is divided into several iterations each of which takes between one and four weeks to implement. The first iteration creates a prototype of the whole system. The customer decides and selects the stories for each iteration, and creates the functional tests to be run at the end of each iteration. The system is ready for production at the end of the last iteration.
  
  
• Productionizing Phase: In this phase, the system goes through extra testing and performance checks before being released to the customer. New changes can still be suggested by the customer and the decision to include them in the current release has to be taken. The duration of iterations is shortened in this phase. The ideas and suggestions that were postponed are documented for implementation during the maintenance phase.
  
  
• Maintenance Phase: After productionizing the first release for customer use, the XP project must keep the system under development running and also produce new iterations. To do this, customer support tasks are also taken up during this phase. Thus, the development velocity decreases once the system is in production. To compensate for this deceleration, changes in the team structure may be required and additional people may have to be included in the team.
  
  
• Death Phase: In this phase, the customer requirements are met, and no additional stories are to be implemented. As there are no more changes to the architecture, code, or design, the necessary system documentation is done. Death also occurs if it gets too expensive for further development or if the system is not delivering the desired output.