Extreme Programming (XP) is an iterative, evolutionary and agiles procedural model in the software technology. It was developed by Kent Beck, Ward Cunningham and Ron Jeffries during its work in the project Comprehensive Compensation system with Chrysler. The so-called C3-Projekt lasted from 1995 to 2000. XP identifies numerous core disciplines of the software development, and uses themselves to Best Practices, thus in practice as usable proven standards, in an extreme way.

The method considers that the customer does not know the real requirements at the start of the project usually yet completely and/or all (technical) information does not have the developer team, in order to give a reliable estimation. In the course of a project beyond that also priorities change. At the beginning demanded features are needed possibly in another form or are completely void in the course of the time.

The developer considers customer's requests, which result also during the software development. In demarcation to the classical water drop model the development process goes through all disciplines of the classical software development (requirement analysis, Design, implementation, test) again and again in short cycles. Only the characteristics needed in the current iteration step are implemented. XP is not easy weighty, it a complete technical specification of the solution which can be developed is presupposed (in such a way there is for example no product requirement specifications).

XP is not a charter to the chaos, it follows rather a clear, structured procedure, and required all openness and discipline involved of.

Principles

Extreme Programming is the sum of individual Best Practices. Although it usually completely all to be together used is not compellingly necessary this. XP does not define itself with this Prinzipen however as universal remedy. Where it the individual requirements been sufficient is not to be adapted it. Many principles interlink interlocked. Individual principles are not new actually, are partly already alone for a long time used.

• Communication - speak with others in the team, in order to exchange information, openly, honestly, respectfully. The process requires high communication readiness.
• Courage - to the truth. Example: direct communication if a requirement in an iteration be converted cannot.
• Collective property - activities are distributed to the team, first not to individual persons; to be successful general obligation as a team; no knowledge monopoly; Pair Programming.
• Pair Programming - two programmers divide computers, monitor, keyboard and mouse - one coded (the Driver), one thinks along and has the large picture in the head (the partner) (regularly the roles to exchange, four-eye principle). Knowledge transfer, - distribution. Better Design.
• Integration of the individual components to an executable overall system in short time intervals (e.g. by CruiseControl).
• Test-driven development - only the unit tests are written, before actual functionality is programmed. The tests are implemented after each programming step and supply feedback over the level of development. One speaks also of Grey box tests. The tests are automated. It is differentiated between involution test and module test. Also performance tests are usual.
• Confine inclusion of the customer, i.e. the customer gives the iteration goal with the help of so-called '' Story Cards '' and has the possibility acceptance test to accomplish immediately. "Story Cards" with its user Stories describe applications exemplary in form of short stories. The customer must be very often present or at least seizable.
• Current Refaktorisierung, constant architecture improvement, to also repair in order anti- Patterns time near. These are usually accomplished in real time or defined as nose, which is repaired in a later iteration.
• 40-Stunden-Woche, i.e. overtime are to be avoided dringendst, because from it the joy in the work suffers, medium-term the concentration ability of the programmers and thus also the quality of the product. Demonstrably the productivity of the developer sinks by overtime. Work outside of the Sweet Spot may be waited in individual cases, but particularly remunerates in no case or expects. Overtime witnesses usually simply only from wrong planning.
• Short iterations, in order to supply to the customer with in regular time intervals executable intermediate conditions of the product.
• Daily, short condition UP Meeting. Each participant reports which it the day before carried out, what out he would like to carry today and where there were if necessary problems. Furthermore situativ pairs can be formed (Pair Programming).
• Documentation only where really necessarily: a documentation is not to describe that which was developed, it is to the whole product a genuine increase in value to give. Executable software is more important than sumptuous documentation.
• Requirements described with the technical vocabulary of the customer, optimalproves also by it, in the form of user Stories

Requirement management

Handling the requirements and its realization, thus the requirement management, is a central component XPs. The quality and flexibility of the software are to be increased by a mixture of different measures, so that the connection between the time, when a demand is made, and which thereby developing costs is to a large extent linear.

With a to a large extent linear process of the cost curve a complete collection of all requirements at the beginning of the project one does without. Instead only in the course of the realization resulting in the requirements with consider themselves. This procedure resulted from the observations that on the one hand the customer at the beginning of the project still not exactly white which he would like on the other hand these requirements in the course of a project it changes. Beyond that errors are the more expensively the later one her find. In the worst case the customer after a long project something supplied which it not to have would like. Constant customer exchange, openness for changes and constant integration work against these risks.

New requirements are measured either in ideal days or in story POINTs.

Articles in category "Extreme Programming"

We found here 3 articles.

Related Websites

We found here 3 related websites.

• Extreme Programming: A Gentle Introduction
  Introduction to Extreme Programming, one of several new lightweight software development methodologies....


• Extreme Rules
  The Rules and Practices of Extreme Programming. Lessons Learned. Planning. User stories are written. Release planning creates the schedule. ...


• XProgramming.com
  Extreme programming practices, discussion, and support, from Ron Jeffries. ... Isaac Gouy is a perenniel poster on comp.software.extreme-programming, ...