Monday, December 28, 2015

Extreme Programming (XP) |David Tzemach


  • XP was developed by “Kent Beck” and introduced in his first book “Extreme Programming Explained: Embrace Change (Addison-Wesley, 1999)”.
  • It was one of the earliest agile methodologies and the first one that challenge the traditional Waterfall model.
  • XP is a designed to support a small/medium software development teams.
  • It’s called “Extreme Programming” because it takes 12 known proven software development principles/practices and push them to extreme levels. 

Extreme Programming as an Agile Methodology

The Manifesto for Agile Software Development

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

                      Individuals and interactions over processes and tools
                     Working software over comprehensive documentation
                     Customer collaboration over contract negotiation
                     Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.”  -Kent Beck-

The Values of extreme Programming


  • Do the simplest that could possibly work.
  • Remove any code that you will not use.
  • The team members will focus on things that matters and don’t waste time on things that they doesn't ask for.

"XP is making a bet. It is betting that it is better to do a simple thing today and pay a little more tomorrow to change it if it needs it, than to do a more complicated thing today that may never be used anyway."   -Kent Beck-


  • There should be a good communication between the team and the client.
  • The entire team members should work together to complete each task.
  • Face to face communication will reduce the need of documentation.
  • The project coach should validate that there is a good communication (Developers->Developers, Developers->Client etc.)


  • Developers should have the courage to take fast decisions due to the collective ownership.
  • Developers should have the courage to tell the truth about the effort they need to complete tasks (Time Estimations, implementation effort etc.).
  • Developers should have the courage to make real changes in the software design and architecture when needed.


  • Extreme programming embraces Feedback as a great way to evaluate the current state of the development process.
  • Fast feedback will increase the effectiveness of the process.
  • Each resource that involved in the project is relevant, Examples:
    • Developers – Estimate the user stories and respond with estimations.
    • Customer – Test the software and send feedbacks that will increase the quality.


  • Respect the other team members.
  • Respect the customer.
  • Respect the project.

Activities in Extreme programming


  • All developers should follow a predefined code standards.
  • Continuous integration throughout the entire process.
  • The Code is based on the customer user stories.
  • The Customer should be available at all time.
  • First Code is written for Unit tests.
  • Collective code ownership.
  • Pair Programming.


  • Testing is made by the developers (Unit) and by the customer (ATP for functionality).
  • Every part of the code should be tested with a dedicated unit test.
  • You cannot say that your code is working until you test it.
  • All tests should run on every new build.


  • Developers should listen to the client requirements about how the system should develop.
  • Developers should listen to each other to develop a better and resilience software.
  • Developers should listen to the client feedback about the generated code. 


  • A good and simple design will reduce the complexity of the system.
  • Every developer can take an active part in the design process.
  • The Design is made at the start and during the process.
  • Refactoring is a decisive part of the design process.
  • Although Xp embraces fast development that add business value, it doesn't mean that the designing process is excluded.

The 12 Key Practices of Extreme Programming

The Planning Game

  • The company evaluates the client requests against the cost estimations and development time.
  • The primary goal is to produce the maximum business value in the fastest way.
  • There are three basic rules to follow on this phase:
    • Business comes up with the list of requirements from the client (User Stories).
    • Engineering team review the “User Stories", and then answer these two questions:
      • How much effort the team can produce per iteration (How many user stories they can deliver per iteration)..?
      • What is the time estimation and effort will they need to put in order to deliver each item?
    • Business review the estimations and decide what are the user stories that will be developed and in what order.

Small Releases

  • The first release is developed with the smallest useful set of features to increase the business value.
  • The main target is to release a working and tested software early as possible.
  • Software updates should be developed often to support fast releases.
  • The customer can use this software in its own environment that involve real users (Which allowing the customer to evaluate the software and send his feedbacks).

System Metaphor

  • Another responsibility of the “Metaphor”, is to determine a set of keywords that describes a common technical entities (Common Terms, Class Names etc.).
  • Each project as its “Metaphor”, is job is to guide the project resources on how the whole system works (Components, integrations, etc.).
  • Metaphor in XP is the common vision of the team members on how the program should develop and work. 

Simple Design

In Agile methodology the requirements are frequently changed, Based on this assumption, you should always use the most simplified software designs that allowing you to make the job done.

Continuous Testing

  • Testing is done throughout the entire process.
  • All tests must run and pass with 100% before a new development.
  • There are two types of tests that involve in this process:

Test Driven Development (TDD)
  • Automated tests that are written by the development team (Per functionality).
  • Programs write the tests prior to the application code development.
  • The code is produced with almost 100% test coverage.

Acceptance Tests
  • This tests is the “Contract” between the customer and the company.
  • The client can validate that the software is developed as specified.
  • Tests that are specified by the customer. 


  • To achieve value per iteration, the development team must build the software based on a simple and effective design.
  • Refactoring cannot be made without a corresponding testing to ensure that nothing was broken.
  • Refactoring is a design continues improvement that developers can do at any time.
    • During the refactoring phase, programmers can:
    • Edit their code (Edit code, but without changing the functionality).
    • Improve the software design.
    • Remove any code duplication.

Pair Programming

Two programmers are working on the same computer to complete a single Task.
  • Programmer no’1 – Responsible to write and implement the code.
  • Programmer no’2 – Watch the implementation and identifies any code errors.

The assumptions
  • Programmers will gain more confidence in their code.
  • Developers will enjoy working together.
  • Tasks will be resolved faster.
  • Produce higher quality code.

Continuous Integration

  • New builds are created Daily with the full code (the entire code that was developed by this point).
  • Any development is integrated to a single location when the code is ready.
  • IN XP developers must keep the system fully integrated at all times
  • All Unit tests must be run and pass with 100%.

Collective Ownership

  • Any developer must have the ability to work on any part of the code.
  • No specific developer that responsible for a specific component.
  • Code can be changed by any developer without delay.
  • A new code is reviewed by the entire team.
  • Increase the responsibility of developers.

On-site Customer

  • Developers can access to a real client environment (where the software is implemented.).
  • The customer should lead the project (Requirements, Priorities and timelines).
  • The customer should be available at all time (Face to face communication).
  • Developers will not use any assumptions during the development process.
  • The customer is one of the most important resources in XP process.
  • The customer should answer any open questions.

The 40-hour Week

  • In most projects, this practice is not relevant, the real world is different from the theoretical one J
  • Consecutive overtime hours will indicate that there is something wrong in the process.
  • The team will go home on time, there is no reason to do overtime hours
  • The project shouldn’t interfere with the developer’s personal life.
  • The work week should be no more than 40 hours.
  • Tired developers do more coding mistakes.

Coding Standards

  • Coding standards will help to develop a better code.
  • Every developer should follow the code standards.
  • Code review should be used as a method to validate that the expected standard is enforced.
  • Examples for “Code Standards”:
    • The code must include comments per method.
    • Coding conventions (Formatting, Naming, etc.).
    • Develop based on a specific design pattern.
    • The code should be easy to maintain. 

Extreme Programming Participants Roles

Image result for RolesCustomer

  • Responsible to specify and test the software functionality.
  • Specify the software requirements and specifications.
  • Determines the development priorities.
  • Create and explains the user stories.


  • Monitor the entire process and validate that the project stays on course.
  • Guides and mentors the team members.
  • Should lead by example.


  • Maintain the software through the process and after implementation.
  • Make the code implementation (User stories into working code).
  • Estimates the time and effort of the user stories.
  • Test the code (automated unit tests).


  • Responsible to make sure that small issues remain small and not get out of proportion.
  • Responsible to make sure that when a crises occurs, everyone will know about it.
  • Validate that each resources knows the risk involved.


  • Validate that each developer is on track with his assigned tasks.
  • Validate that each developer is synchronized at all time.
  • Arrange meetings with the client when necessary.
  • Validate that the project is going as scheduled.


  • Report for defects and any other issues that may affect the user experience.
  • Test the software functionality.

No comments:

Post a Comment

My Presentations