jump to navigation

Extreme Programming August 2, 2005

Posted by Coolguy in Software Development.
Tags: ,
add a comment
  • The main aim of XP is to lower the cost of change.
  • In traditional system development methods the requirements for the system are determined at the beginning of the development project and often fixed from that point on.
  • This means that the cost of changing the requirements at a later stage in the projectc will be very high.
  • XP sets out to lower the cost of change by introducing basic values, principles and practices. By applying XP, a system development project should be more flexible with respect to changes
  • Risky projects with dynamic requirements are perfect for XP
  • XP is set up for small groups of programmers.You can not use XP on a project with a huge staff
  • XP requires an extended development team. The XP team includes not only the developers, but the managers and customers as well.

XP core practices
12 core practices of XP are as follows:

  • Test driven development : Within XP, unit tests are written before the eventual code is coded
  • Planning game
  • Onsite customer: XP says that the customer should be at hand at all times and available for questions
  • Pair programming : Pair Programming means that all code is produced by two people programming on one task on one workstation.
  • Continuous Integration
  • Refactor: Because XP doctrine advocates programming only what is needed today, and implementing it as simply as possible, at times this may result in a system that is stuck
  • Small Releases
  • Simple design
  • System metaphor
  • Collective code ownership
  • Coding standards

XP values
The five values are:

  • Communication
  • Simplicity
  • Feedback
  • Courage
  • Respect (the latest value)


  • A fundamental task of building software systems is communicating system requirements to the developers of the system.
  • In formal software development methodologies, this task is accomplished through documentation
  • Extreme Programming favors simple designs, metaphor, collaboration of users and programmers, frequent verbal communication and feedback.
  • Unfortunately, XP also makes a big issue about not doing any documentation (or at least very little, or none at all).


  • eXtreme Programming encourages starting with the simplest solution and refactoring to better ones
  • The difference between this approach and more conventional system development methods is the focus on designing and coding for the needs of today instead of those of tomorrow
  • XP promotes a throwaway approach to source code (i.e. write, toss, rewrite).
  • A simple design with simple code can be easily understood by every programmer in the team


  • Feedback from the system: by writing unit tests the programmers have direct feedback from the state of the system after implementing changes.
  • Feedback from the customer: The functional tests are written by the customer and the testers. They will get concrete feedback about the current state of their system. This review is planned once in every two or three weeks so the customer can easily steer the development.
  • Feedback from the team: When customers come up with new requirements in the planning game the team directly gives an estimation of the time that it will take to implement


  • Courage enables developers to feel comfortable with refactoring their code when necessary.
  • This means reviewing the existing system and modifying it so that future changes can be implemented more easily
  • Another example of courage is knowing when to throw code away

Activities of XP

XP describes four basic activities that are performed within the software development process

  • Planning
  • Coding
  • Designing
  • Testing


  • The main planning process within eXtreme Programming is called the planning game.
  • The planning process is divided into two parts
    • Release Planning
    • Iteration Planning
  • Typical activities in planning process are:
    • User stories are written.
    • Release planning creates the schedule.
    • Make frequent small releases.
    • The Project Velocity is measured.
    • The project is divided into iterations.
    • Iteration planning starts each iteration.
    • Move people around.
    • A stand-up meeting starts each day.
    • Fix XP when it breaks

Release Planning:

  • This is focused on determining what requirements are included in which release and when it’s going to be delivered.
  • The customers and developers are both part of this
  • Release Planning consists of three phases
    • Exploration Phase: In this phase the customer will give all his requirements for the system. These will be written down on user story cards.
    • Commitment Phase:Within the commitment phase business and development will commit themselves to the functionality that will be included and the date of the next release
    • Steering Phase: In the steering phase the plan can be adjusted, new requirements can be added and or existing requirements can be changed or removed.

Exploration phase – Release planning

  • This is an iterative process of gathering requirements and estimating the work impact of each of those requirements
  • Get Requirement from Customer: In this phase the customer will give all his requirements for the system. Business has come with a problem; during a meeting, development will try to define this problem and get requirements. These will be written down on user story cards.
  • Write a Story: Based on the business problem, a story has to be written. This is done by business, where they point out what they want a part of the system to do. It is important that development has no influence on this story for so far the functionality. The story is written on a so called user story card.
  • Split a Story: If development isn’t able to estimate the story (next item), it needs to be split up and written again. Again, this may not influence the business requirements
  • Estimate a Story: Development estimates how long it will take to implement the work implied by the story card.

Commitment Phase – Release planning

  • This phase involves the determination of costs, benefits, and schedule impact. It has four components.
  • Sort by Value: Business sorts the user stories by business value. Critical,Significant Business Value,Nice to have.
  • Sort by Risk: Development sorts the stories by Complexity,Volatility,Completeness
  • Set Velocity: Development determines at what speed they can perform the project. Programming Units. 1 Unit = X Man days
  • Choose scope: The user stories that will be finished in the next release will be picked. Based on the user stories the release date is determined

Steering phase – Release planning

  • Within the steering phase the programmers and business people can “steer” the process.
  • That is to say, they can make changes. Individual user stories, or relative priorities of different user stories, might change; estimates might prove wrong.
  • This is the chance to adjust the plan accordingly.

Iteration Planning:

  • This plans the activities and tasks of the developers.
  • In this process the customer is not involved. Iteration Planning also consists of three phases:
    • Exploration Phase: Within this phase the requirement will be translated to different tasks. The tasks are recorded on task cards
    • Commitment Phase: The tasks will be assigned to the programmers and the time it takes to complete will be estimated.
    • Steering Phase: The tasks are performed and the end result is matched with the original user story.

Exploration phase – Iteration planning

  • The exploration phase of the iteration planning is about creating tasks and estimating their implementation time.
  • Gather User Stories: Gather and write all user stories for the next release
  • Combine/Split task: If the programmer cannot estimate the task because it is too big or too small, the programmer will need to combine or split the task.
  • Estimate task: Estimate the time it will take to implement the task.

Commitment phase – Iteration planning

  • Within the commitment phase of the iteration planning programmers are assigned tasks that reference the different user stories.
  • A programmer accepts a task: Each programmer picks a task for which he or she takes responsibility.
  • Programmer estimates the task: Because the programmer is now responsible for the task, he or she should give the eventual estimation of the task.
  • Set load factor: The load factor represents the ideal amount of hands-on development time per programmer within one iteration. For example, in a 40-hour week, with 5 hours dedicated to meetings, this would be no more than 35 hours.
  • Balancing: When all programmers within the team have been assigned tasks, a comparison is made between the estimated time of the tasks and the load factor. Then the tasks are balanced out among the programmers. If a programmer is overcommitted, other programmers must take over some of his or her tasks and vice versa.

Steering phase – Iteration planning

  • The implementation of the tasks is done during the steering phase of the iteration planning.
  • Get a task card: The programmer gets the task card for one of the tasks to which he or she has committed.
  • Find a Partner: The programmer will implement this task along with another programmer. This is further discussed in the practice Pair Programming.
  • Design the task: If needed, the programmers will design the functionality of the task.
  • Write unit test: Before the programmers start coding the functionality they first write automated tests. This is further discussed in the practice Unit Testing.
  • Write code: The programmers start to code.
  • Run test: The unit tests are run to test the code.
  • Refactor: Remove any code smells from the code.
  • Run Functional test: Functional tests (based on the requirements in the associated user story and task card) are run.


  • Simplicity : A simple design always takes less time to finish than a complex one.
  • Choose a system metaphor :Choose a system metaphor to keep the team on the same page by naming classes and methods consistently
  • Use CRC cards for design sessions:Individual CRC Cards are used to represent objects.
  • Create spike solutions to reduce risk : Create spike solutions to figure out answers to tough technical or design problems. A spike solution is a very simple program to explore potential solutions.
  • No functionality is added early : Keep the system uncluttered with extra stuff you guess will be used later
  • Refactor whenever and wherever possible: Refactor mercilessly to keep the design simple as you go and to avoid needless clutter and complexity. Keep your code clean and concise so it is easier to understand, modify, and extend.


  • The customer is always available : All phases of an XP project require communication with the customer, preferably face to face, on site.
  • Code must be written to agreed standards : Code must be formatted to agreed coding standards
  • Code the unit test first.
  • All production code is pair programmed.
  • Only one pair integrates code at a time.
  • Integrate often : Developers should be integrating and releasing code into the code repository every few hours, when ever possible.
  • Use collective code ownership.
  • Leave optimization till last.
  • No overtime.


  • All code must have unit tests.
  • All code must pass all unit tests before it can be released.
  • When a bug is found tests are created.
  • Acceptance tests are run often and the scoreis published: The customer specifies scenarios to test when a user story has been correctly implemented. A story can have one or many acceptance tests, what ever it takes to ensure the functionality works.

XP Roles

  • Customer
    • The on-site customer (or customer team) is there to make day-to-day business decisions about what functionality goes into the project and what stays out.
    • The programmers and the XP Coach lead the customer by the hand
  • Programmer
    • XP requires programmers to have a broader skill set than simply programming. Suddenly they are not only coders but customer-facing analysts
  • Tester
    • Programmers perform unit testing, and either the programmers or the customer perform acceptance testing

Controversial aspects

  • Detailed specifications are not created or preserved
  • Programmers are required to work in pairs – not all software developers expect to be asked to work this way
  • A customer representative is attached to the project. This role can become a single-point-of-failure for the project and some people have found it to be a source of stress

More info:


Up Front and Test Driven: Excerpt from Agile Development with ICONIX Process May 12, 2005

Posted by Coolguy in Software Development.
add a comment

Up Front and Test Driven: Excerpt from “Agile Development with ICONIX Process”

XP DAY April 1, 2005

Posted by Coolguy in Software Development.
add a comment


The New Methodology January 18, 2005

Posted by Coolguy in Software Development.
add a comment

The New Methodology

XP November 25, 2004

Posted by Coolguy in Software Development.
add a comment

Principles of XP:

Planning game

Pair programming



Simple design

Collective code ownership

Continuous integration

On-site customer

Small releases

Coding standard

System metaphor