In this chapter, we will learn about some additional features of Extreme Programming.
The charm of Extreme Programming is continuous feedback that keeps everyone focused and development continues in the right direction without any delays.
In Extreme Programming, feedback is accomplished at different levels, to the required and sufficient detail. This is done continuously and constantly across the iterations and releases as well.
The following table illustrates the feedback events and the feedback duration.
|Feedback Event||Feedback Duration|
|Clarifications among Team and with the Customer||Hours|
|Progress||In a Day|
In Extreme Programming, Project Management is not given emphasis and the manager role performs the minimal and the most essential management activities.
However, these activities embed the project management requirements.
Scope is defined by user stories in story cards.
Estimates are story estimates, that can be in story points.
Delivery milestones are captured by release plans.
Release is divided into iterations.
Stories are blown into tasks in task cards.
Estimates are task estimates.
Allocation of tasks done by balancing load factor across the team.
Task acceptance is by team commitment and accountability.
Velocity in terms of story points from actual time for implementation done at project level.
Productivity in terms of task estimates from actual time for implementation done at developer level.
From the Extreme Programming projects executed across the industry, there are certain learnings useful for the teams.
In the following sections, you get an understanding of these learnings.
Simple Design − A simple design is efficient, easy to build and maintain.
Metaphor − The main intention of using metaphor is to use domain specific names throughout development and that enables the customer also to actively participate in the development.
Collective Ownership − Each one is proud of their good code. By working together, each one is proud of everyone's code.
Planning − In case the team completes many user stories in an iteration, make the iterations smaller. Have the team consensus to alter a plan.
Initially, Extreme Programming was perceived to be effective in smaller teams, with a team size up to 12-16 developers.
Later, it was observed that it is possible to scale Extreme Programming up to teams of 40-50. However, it is recommended to do the scaling by building recursive teams. Build a small team first, grow the team incrementally, using the first team to seed recursive teams.
Extreme Programming is not against any documentation. It encourages documenting what is required, when it is required and only to the required and sufficient Detail. This may differ from project to project and it is for the project to decide on the extent of documentation. However, skipping documentation is not allowed by the Extreme Programming practices.
Extreme Programming is found to be advantageous when applied in −
Environments that are highly uncertain
Extreme Programming is found to be disadvantageous when −
The environments are large and complex.
The requirements are well understood.
The customer is at a distance or unavailable.
There are some misconceptions about Extreme Programming. The following table gives the clarifications of the misconceptions that exist.
|No written documentation||Minimal and sufficient documentation needs to be there. However, there are no formal standards for how much or what kind of documents are needed.|
|No design||Minimal explicit and up-front design needs to be there that evolves as the development progresses.|
|Extreme Programming is just pair programming and easy||Pair Programming is just one of the Extreme Programming practices. It requires great discipline and consistency that is achieved in conjunction with the other Extreme Programming practices.|
|Extreme Programming is the one, true way to build software||Extreme Programming is effective only in certain type of projects.|