Extreme Programming (XP) Methodology

Extreme Programming (XP) is a software engineering methodology that has been formulated in 1996 by Kent Beck. It is a lightweight development methodology, XP is one of several popular agile processes. Extreme Programming has received fair media attention, and is most renowned for its practices that are sometimes regarded as controversial, such as pair programming and test-driven development. It has already been proven to be very successful because it reaches to the customer satisfaction. Instead of delivering everything at the same time the XP focus on some date far in the future, this process delivers the software you need as you need it, in other words Extreme Programming empowers the developers to confidently respond to changing customer requirements, even late in the project development life cycle. The philosophy of Extreme Programming is teamwork, in other words Managers, Customers and Developers are all equal partners in a collaborative team. The implement is simple regarding Extreme Programming, yet effective environment enabling teams to become productive.

Extreme Programming is built on four values:

  1. Communication: Extreme programmers constantly communicate with their customers and fellow programmers.
  2. Simplicity: The keep their design simple and clean.
  3. Feedback: They get feedback by testing their software starting on day one
  4. Courage/ Respect: They deliver the system to the customers as early as possible and implement changes as suggested. Every small success deepens their respect for the unique contributions of each and every team member.

Extreme Programming accepts that humans are imperfect and builds a process that not only accepts progressive elaboration, but makes this reality a central theme to all of its other practices. There is also recognition that the proscribed practices in the real world can be very challenging, to overcome this difficulty the practices interlock and complement each other.

12 Practices of Kent Beck used in an Extreme Programming (XP) Project

There are strong relationships between Extreme Programming and its practices. Without practices it’s not XP, and without practicing the practices of XP it cannot deliver benefits.

  1. Planning Game: This is focused on determining requirements details. The customers and developers are both part of this. In a planning game the customers and the developers sit in a room together. They make plans for software releases and iterations together, identifying each role clearly. Planning game involves the making of story cards from each user’s point of view and splitting each story into task cards for individual developers then they make plans that take into consideration the volume of work and the schedule based on these cards.
  2. Small Releases: In small releases developers put quickly a simple system into production, and then release new versions in a very short time.
  3. Metaphor: In metaphor, developers in the team share story or understandings about how their programs work.
  4. Simple Design: The system should be designed as simply as possible at any given moment. Keep code simple and extra complexity is removed as soon as it is discovered. Always keep in mind the principle of YAGNI (“You aren’t going to need it”).
  5. Testing: Programmers continually write unit tests, which must run flawlessly for development to continue. Customers define test cases for system releases.
  6. Refactoring: Without changing their behavior, improve the internal structures of programs.
  7. Pair Programming: Production code which is actually used in the final product, is written with the celebration of two programmers at same machine.
  8. Collective Ownership: Programming code is the property of few programmers it owned by the team collectively, and anyone can change code anywhere and at anytime.
  9. Continuous Integration: Integrate and build the system many times in a day, every time a task is implemented.
  10. 40-hour Week: This is the rule of Extreme Programming that no work more than 40 hours. Never work overtime a second week in a row.
  11. On-site Customer: In whole project include a real, live user on the team who is available full-time on site to answer questions.
  12. Coding Standards: Programmers write common rules to standardize coding styles in the team.

Leave a Reply

Your email address will not be published. Required fields are marked *