Extreme Programming

Similar to Scrum, XP starts the process by creating a backlog of work to perform during
a sprint/iteration. XP creates the backlog by working with customers and creating
user stories. In parallel with this work, the team performs an architectural spike, during which they experiment with the features to envision the initial architecture. XP
classifies this work as the exploration phase.

The planning phase follows exploration. This phase focuses on identifying the most
critical user stories and estimating when they can be implemented. Tasks are defined
for each feature, to aid with estimating complexity. The team outlines an overall
release schedule, with an understanding that a high level of uncertainty exists until
the work begins. A release will have one to many iterations, which are typically 2- to 4-
week construction windows.
When an iteration begins, the specific plan for the iteration is revisited. The team
adds any new user stories and tasks that have been discovered since the overall release
was outlined.
XP integrates customer testing into the development iteration. The customer is
asked to identify the acceptance tests, and the team works to automate these tests so
they can be run throughout the iteration.

The planning phase is followed by the productionizing phase, during which the code
is certified for release. Certified means the code passes all customer tests plus nonfunctional requirements such as load testing, service-level requirements, and response time requirements. You can see an overview of XP in below image:



XP's characteristics:

• Specific practice —Unlike Scrum, XP is specific about the practices that should be
used during a software project. These practices include pair programming,
TDD, continuous integration, refactoring, and collective code ownership.
• Simplicity —Teams perform the minimum work needed to meet requirements.
• Automation —Unit and functional tests are automated.
• Quality through testing —Features are tested constantly, and developers check
each other’s code via pair programming.

XP’s strengths :

• Customer-focused (it’s all about user stories)
• Quality via frequent testing
• Constant focus on identifying and delivering the critical user stories
• High visibility on project status
• Great support for volatile requirements

XP's weaknesses:

• Need for team maturity —Practices such as pair programming and TDD require
responsible developers, and they aren’t always easy to obtain.
• Dependency on testing —If developers know that significant testing will take place
downstream, they may be less than diligent when they’re creating designs.
• Scalability —XP may not work well for large projects.
• Dependency on team member co-location —The team usually has a team room.


XP supports many of the critical goals of an agile process, such as dealing with volatile
requirements and delivering prioritized, working software as soon as possible. XP also
supports the principle of just enough, keeping with the lean philosophy of minimizing
waste.

XP has sometimes been criticized for its lack of formality in system documentation
and system design. In recent years this has changed, and XP teams now create the documentation needed to support a project’s customers.