- Home
- Introduction
- Values and Principles
- Practices
- Supporting Practices
- Evolving Practices
- Process Cycle
- Pair Programming
- Roles
- Activities and Artifacts
- Rules
- Additional Features
- Scrum + Extreme Programming
- Tools
- Useful Resources
- Quick Guide
- Useful Resources
- Discussion
Extreme Programming - Process Cycle
Extreme Programming is an Agile process.
Extreme Programming is an Agile process because it −
Emphasizes plenty of communication and feedback −
Within the team (pair programming, collective code ownership, simple design)
With the customer (on-site customer and acceptance testing)
For release planning (with customer and developers participating in estimation)
Extreme Programming employs a coach whose job is noticing when people are not communicating and reintroduce them.
Embraces change with −
Frequent iterations (short releases)
Designing and redesigning easily (simple design)
Coding and testing continuously (pair programming)
Keeping the customer constantly involved (on-line customer)
Delivers working product to the customer in short iterations (short releases).
Eliminates defects early, thus reducing costs (pair programming)
Code reviews
Unit testing
Integration for every set of changes and testing
Extreme Programming Process Cycle
Extreme Programming is iterative and incremental and is driven by Time-Boxed Cycles. Therefore, the rhythm of the Extreme Programming process is crucial.
Extreme Programming has the following activity levels −
Product Life Cycles
Releases
Iterations
Tasks
Development
Feedback
Each of the activity levels provides the minimal inputs required for the next level. They are −
Product life cycle activities provide inputs for release cycles.
Release planning sessions provide inputs for iteration cycles.
Iteration planning sessions provide inputs for task cycles.
Task development provides inputs for development episodes.
Development produces the product.
Feedback is a continuous activity throughout the project and across all the above activity levels.
Product Life Cycles
This is also referred to as the Exploration phase. It involves feature set definition and planning. The customer arrives at high value requirements and the requirements are given as user stories.
Stories are the primary deliverable of this level activity.
Releases
This is also referred to as the Commitment phase. In this activity −
The whole team gathers so that −
Progress is reviewed.
New requirements can be added and/or existing requirements can be changed or removed.
Customer presents stories.
Stories are discussed.
The developers determine the technical approach and risk. They provide first-level estimates and options.
The customer prioritizes the stories and chooses target release time box.
The customer and developers commit themselves to the functionality that are to be included and the date of the next release.
The developers −
Arrange stories into probable iterations.
Include defect fixes from acceptance testing of the previous release.
Begin the iterations.
Release plan is the primary deliverable of this level activity.
Iterations
This is also referred to as the Steering phase. The whole team gathers so that the progress is reviewed and the plan can be adjusted. The customer presents stories for the iteration and the stories are discussed in greater detail.
The iteration Plan is the primary deliverable of this activity.
The developers −
Determine detailed technical approach.
Create task list for each story.
Begin the development.
Deploy the system as far as
Deployable System is the final deliverable of this activity.
Tasks
The developers Sign-up for the tasks and begin development episodes to implement the stories. They ensure the tasks for the iteration are complete. The developers also ensure that the stories for the iteration are complete with acceptance tests.
Development
The developers form pairs, which can be a continuous and dynamic activity.
Each Pair −
Verifies their understanding of the story.
Determines detailed implementation approach, ensuring simple design.
Begins test-driven development, i.e., write unit test, implement code to pass the unit test, refactor to make the code simple.
Integrates their code to the system code base at appropriate intervals.
Reviews the progress frequently.
Feedback
Pairs constantly communicate within themselves and outward to the team as well. On-line customer is also involved in the communication on a continuous basis. Certain teams resort to daily stand-up meetings to discuss the overall team status quickly and the possible re-synchronization and micro-planning if necessary.
The iteration and release reviews provide overall status and points for process adjustment and improvement.
Development episodes may cause rethinking of tasks.
Task development may cause rethinking of stories.
Story re-estimation may cause iteration changes or recovery.
Iteration results may cause changes to release plan.
The Extreme Programming process cycle is illustrated below.
