Extreme programming

from Wikipedia, the free encyclopedia

Extreme Programming ( XP , even extreme programming ) is a method that is solving a programming task in the forefront of software development and it attaches a formalized approach less important. This approach defines a process model for software technology that approaches the customer's requirements in small steps.

Basics

XP lifecycle

XP is a process model that is structured through continuous iterations and the use of several individual methods. XP was created through the synthesis of various software development disciplines and is based on methods that have been tried and tested in practice, also known as best practices .

XP follows a structured approach and focuses on teamwork, openness and constant communication between all those involved. Communication is a basic pillar here.

The method assumes that the customer does not yet fully know the requirements for the software to be created at the beginning of the project and cannot structure it adequately, or that a development team entrusted with the implementation does not have all the information to make a reliable estimate of the effort required over the required duration to give up to graduation. In the course of a project, priorities and weights often change. Software functions that are required at the beginning may be required in a different form or may even become completely obsolete over time.

With a consistent focus on XP, the software to be created should be provided more quickly and a higher software quality and customer satisfaction should be achieved than with traditional approaches. The customer should receive a ready-to-use product in the manufacture of which he has actively participated.

New functionalities are constantly being developed, integrated and tested. For the functionalities to be developed, the steps of risk analysis, benefit analysis, the provision of a first executable version ( prototyping ) and an acceptance test are carried out.

Use

According to representatives of this procedural model, XP is risk management . It affirms the risk, takes an active part in it and tries to minimize it. This implicit handling of the risk factor is in contrast to more explicit procedures, such as drawing up a risk list . Software development projects are exposed to different dangers for which Extreme Programming should offer solutions.

Customer perspective

Thanks to its short development cycles, XP offers the customer the possibility of influencing the project at any time. This is intended to ensure that the product adapts to current requirements, instead of satisfying outdated requirements from a long-gone analysis phase and thus being out of date when it is introduced. In addition, the customer can use an incomplete but at least functional product after a short time. In the best case scenario, the customer is always up-to-date with the latest information on the project as the development team.

A common approach in traditional software development is: “Maybe one day we will need this or that program function” , also known as a feature . XP contrasts this: Leave it! (see also YAGNI - "You Ain't Gonna Need It"). Before each of the short development steps, we work with the customer to determine exactly what is really useful to be developed. The so-called “ featuritis ” should be avoided.

One of the greatest risks in software development is that the customer is provided with a product that they do not want in this form. XP would like to prevent this through constant, active involvement of the customer in the development process. He can view intermediate versions and directly express change requests.

In order to be able to use these advantages, the customer has to accept a number of restrictions and demands in return. XP requires him to work with the development team throughout the development process. Furthermore, he has to forego formal definition of the project content (specification) (see also The ideal customer ).

Programmer's View

There is no strict separation of roles, as tasks are distributed depending on the situation and skills. The general exchange of knowledge and constant communication prevent a knowledge monopoly . This should relieve the individual, otherwise the pressure will be on a person if he is the only one who is familiar with a module .

In order to avoid unusability due to program errors as well as incorrect integration of individual components , many tests as early as possible are aimed for in XP. Each component has a module test (unit test); in Java for example with JUnit . If a fault is found in a component during development, a test is developed that localizes it. Daily involvement of the individual developers involved in the project with automatic execution of the tests ( regression test ) should lead to a considerable increase in quality. Errors should be found earlier, because the later an error is found, the more expensive it is to correct it. In addition, the test-driven development should lead to program code that is easier to maintain and has a better design.

Since most of the individual methods are geared towards the everyday life of the programmer, XP also means a high degree of challenge and, if necessary, changes for those involved. These aspects are discussed in more detail in The Ideal Programmer section .

Project view

XP offers the project the opportunity to minimize risks. With the correct use of XP, the customer should receive software the scope of which does not surprise him. The team should also no longer be so susceptible to failure (illness, accident, change of job) of individuals. Honest dealings with the customer should increase credibility and satisfaction and minimize the fear that may arise between the customer (“Did they understand me?”, “What will they deliver?”) And development (“What exactly does he want? "," Will he be satisfied with what we deliver? ") Prevails.

Are expensed estimates reliable since they met as a team and constantly a critical review ( Review ) undergo. Team spirit is promoted according to XP. It should be clear to everyone in the team that the goal can only be achieved as a unit. If a project is discontinued prematurely, for example for cost reasons, the regular iterations will still result in a mostly usable product.

In many projects it is not possible to complete the product in the desired time, in the desired scope and with the planned resources. In XP, only that which actually has a benefit for the customer should be realized. The functions that need to be created should be identified through constant exchange with the customer and priority analyzes. You should start with the functions that have the greatest benefit and involve the greatest (technical) risk.

Business point of view

From an economic point of view, extreme programming represents a form of organization that directly describes the processes of value creation . In economics, findings from other social sciences , especially sociology , are also used to evaluate extreme programming .

In terms of risk management , this alternative is primarily used to control risks . As with many value creation processes, especially in software development, risks are mostly operational risks: Value creation is ineffective if the customer's wishes are not met and the goals set are therefore not met. The added value is inefficient if too much effort was put into achieving the result. Risk reduction, and thereby effectiveness and efficiency, should be achieved with Extreme Programming through the way of dealing with errors, with employees and with customers:

  • Compensation for sick leave
  • Customer-oriented development
  • Less errors in the result

The most precise possible identification of risks by the process itself should enable an assessment of the risk to be accepted by means of adapted cost estimates. Extreme programming, on the other hand, can make it more difficult to shift risk. From a risk management perspective, extreme programming is just one way of dealing with risk, and one that has both advantages and disadvantages.

The human resources in companies considered extreme programming in particular as regards its impact on employee satisfaction. Extreme programming should consciously or unconsciously contribute to cooperative learning . This procedure is particularly interesting for human resources from the perspective of human resource development . The overall productivity should be increased through higher employee satisfaction and the avoidance of overtime. From a purely mathematical point of view, however, the practice of pair programming suggests the opposite. Avoiding specialization and individual possession of knowledge about parts of the software serves the collective knowledge construction and can simplify the replacement of developers.

In recent years, business administration as a whole has moved from process and value-added oriented to customer and market-oriented corporate management. Even if extreme programming describes the added value, it offers possibilities for a customer-oriented approach. Extreme programming should - as has long been common in other industries - enable the customer to be more closely involved in the value creation process. This becomes all the more important when software is created and sold more as a preliminary product and less as a factor good .

Extreme programming and its effort must also be considered from the point of view of information management , which defines and economically evaluates the effort for the absolutely necessary exchange of information. Findings from information and communication science are used for this purpose . In particular, the media richness theory can be used: Because the issues to be discussed and communicated are usually complex, complex, rich communication media are also chosen: direct, personal conversations. The difficult spatial distributability of the development processes as well as the involvement of the customer, since there may be a spatial separation between the developer and the customer, should be critically examined.

Action

Extreme programming is occasionally referred to as an informal (and therefore non-binding) method. However, that is neither the approach nor the goal. In fact, the formalization of the Extreme Programming method is deliberately kept flat and lean. On the other hand, an agreement between the customer and the programmer must be established with regard to the binding nature of the documents created, as long as they have not yet been replaced by newer versions. Furthermore, the process of replacing a version of a document with a more recent version of this document must be formalized to such an extent that both parties are aware of this replacement and accept this replacement.

Organizational structure

In addition to the development team, there are essentially the customer and the product owner . There should be no separation of roles within the development team. No distinction is made between who in the team has which specialty or which special skills they bring with them. Each person on the team is as a developer ( Developer referred). A manager is usually someone with managerial authority, i.e. a disciplinary supervisor. This is of less importance in XP. On the other hand, there is a “leader” of the team, someone who coordinates communication with customers or with each other. The user of the software to be created can also guide the team through the project. The distinction between manager and “leader” is typical for agile process models. The product owner, who decides on the exact procedure, is responsible. Product owner in the sense of XP can, for example, be a representative of product management, a customer or a user of the product. The roles are distributed differently depending on the project and environment, often also in personal union.

The roles in XP
role example tasks
Product owner Product management, marketing, a user, customer, manager of the user, analyst, sponsor Has responsibility, sets priorities, makes decision-makers for the best ROI
customer Client, can also be the product owner, can, but does not have to be, the user Decides what to do, gives regular feedback, client
developer Part of the team, the entire development team consists of developers: programmers, testers, DB experts, architects, designers Develop the product
Project manager Usually is the product owner. Can also be a developer but not a manager of the team Leadership of the team
user The user of the product to be created Will use the product being created

Requirements management

The handling of the requirements and their implementation is a key component XPs. The quality and flexibility of the software should be increased by a mixture of different measures presented in the following sections, so that the relationship between the point in time at which the request was made and the costs incurred is largely linear.

Change cost curve depending on the time of the change

In the case of a largely linear course of a derivable change cost curve , a complete survey of all requirements at the beginning of the project is dispensed with. Instead, the requirements that only arise in the course of implementation are taken into account. This procedure results from the observations that on the one hand the customer does not know exactly what he wants at the beginning of the project, on the other hand these requirements change in the course of a project. In addition, the later you find them, the more expensive they are. In the worst case, the customer receives something delivered after a long project that he does not want in this form. Constant exchange of ideas with the customer, openness to changes and constant integration counteract these risks. Requirements are often first provided as prototypes . These are versions that do not yet have the full, final functionality.

planning

Release, iterations, user stories and tasks

As part of planning, the following distinction is usually made: a release contains the functions that collectively and individually justify the provision of a new version of the product. In order to get to the release, a release plan must be drawn up, which essentially consists of iterations . Among other things, the number and duration of the iterations are determined depending on the estimated development time of the release. Iterations typically last between one and four weeks. The time of completion is discussed as a time interval, the size of which continuously decreases in the course of the release due to the knowledge gained and the progress made.

Risk-value comparison and distribution of priorities

User stories

The individual innovations to be implemented within the iterations are described with the customer through user stories .

The whole team is involved in the creation. The requirements to be processed are written on individual cards ( story cards ) and placed so that they can be seen by everyone. In addition to this procedure, it is also common to write Class Responsibility Collaboration Models on CRC cards . CRC models take on an actor in the system and describe their responsibilities and interactions with other actors.

The user stories are assigned priority values. To do this, the team and the customer must first gain clarity as to which user stories have the highest risk in terms of schedule, costs or functionality and which user stories offer the product the highest or lowest added value, whereby a diagram can be helpful. The release should begin with the user stories that combine the highest risk and benefit. Then those user stories are to be realized that have a low risk but a high benefit. Then the team tackles the user stories that combine low risk and low benefit. The completion of user stories with little benefit but high risk should be avoided.

Customer satisfaction

In addition to an assessment of the benefit and risk, an analysis of the customer's wishes is important for deciding which user stories should be implemented in the release or in the first iterations. An XP project often uses the Kano model . In a systematic customer survey, questions are asked in a functional form and in a dysfunctional form . It can then be determined which user stories have to be completed ( must-haves ), which are linear in nature (the more, the better; see linear .) And which are exciters (the customer does not expect these features, uses that Product also without it. This increases the price.). The knowledge gained in this way is discussed.

XP is characterized by the fact that the consideration of the size of a unit, such as release or iteration, is independent of its duration.

Estimation of effort

When it comes to release planning, user stories are still quite grainy. If a team deals with a user story in more detail, it is described in more detail together with the customer. User stories are usually estimated in story points , although an estimate in ideal days is also possible. Story points are relative effort estimates , i.e. the development effort for one story compared to others. It is possible that initial estimates are changed in the course of the project. The whole team estimates a number of points for the user stories in several rounds in a planning game .

After user stories have been assessed, prioritized and assigned to an iteration, the team begins implementation. At the beginning of the iteration, user stories are broken down into fine-grained, technical work packages ( tasks ), which usually have a length of hours. The team performs this breakdown and estimates the duration of each task. However, it has not yet been determined who will be assigned the task. At the beginning of the work, the developers each undertake a work package, usually based on skills. This process is briefly discussed in the team. After the initial assignment of the work packages, another task is started if a team member finds time for it, i.e. has completed his previous task. The implementation of a user story, i.e. the functionality, is only complete when all of the individual tasks in this user story have been processed, the tests have been written and all have been successfully passed.

A table with effort estimates in a fictitious doctor's office is intended to demonstrate this procedure. Every doctor has software that helps them manage their patients and their appointments:

User stories with effort estimation in story points
Story No. story Estimation
(story points)
1 As a doctor, I can see all the patients I have during the day. 3
2 As a doctor, I can provide information about the health history of my patients. 5
3 As an assistant, I can make an appointment for a patient. 2
4th As an assistant, I can print out a prescription for a patient. 1

The term velocity (speed) of throughput of the team, so the number of reached within an iteration Story Points. Determining the velocity helps to estimate how long it takes to develop the desired functionality for a release, or how many iterations are necessary. It is normal that the team's speed is not always the same.

Development and completion

Time interval between the steps.

There is a short daily meeting (stand-up meeting) in which each developer reports on what he has done the day before, where there were any problems and what he would like to do today. Furthermore, depending on the situation, working pairs are formed ( pair programming ) . During the day, while the developers are programming the functionality and the tests, further constant exchange (pair negotiations) takes place.

If a user story cannot be completed in one iteration, for example because the tests were unsuccessful or the estimate turned out to be too short or the scope to be too large, it is usually divided into several smaller ones or completely into the next iteration postponed. Even during an iteration, something can change in the composition of the iteration due to changing priorities of the customer or new findings. Once the iteration is complete, management representatives , the customer ( acceptance test ) or other people who are interested in the product take a look at the product in the current expansion stage and provide feedback. So it is conceivable that the customer might set new priorities or bring in further ideas during the acceptance test.

Technical support must be viewed in a differentiated manner. On the one hand, technical aids are deliberately avoided, for example when creating user stories. These are usually created manually. On the other hand, the technology is also used excessively, for example in automated integration and the automated execution of tests. In addition, there are project management tools that have focused on the special framework conditions and requirements of XP.

Differentiation from conventional procedures

The functionality to be developed is described briefly and informally in user stories. Most of the knowledge about the functionality of their development is in the minds of those involved. User stories are usually only valued relative to one another. At the beginning of an iteration, its content is determined. Then the selected user stories are divided into tasks. What is also new about the XP approach is that not only individuals, but the entire team appreciates the effort involved. The estimation process is also new. The point in time when and how the tasks are assigned to the individual developers is also a delimitation criterion. Only in the course of the iteration do the individual developers take on a task, depending on their availability. There are numerous tests for all user stories. A user story is only completely finished when all tests have been successfully completed. The daily short exchange is common for the agile methodology .

Components

XP is made up of values, principles and practices. Although there are also other authoritative sources (see web links and literature ), the compilation of values, principles and practices is based on Kent Beck, whose quite new, evolutionary further developments XPs are also taken into account here. There is no clear definition of XP, although the discussions and explanations of the three original authors shape XP most significantly.

values

XP defines five central values, abstract elements that are of central importance: communication , simplicity , feedback , courage and respect , whereby respect came later. According to XP, it is not possible to develop software successfully without constantly observing these central values.

The central XP values

The team communicates constantly to exchange information. The process itself requires a high level of willingness to communicate. There is a constant exchange between all those involved, including between the development team and the customer. People who are not experts in a technical task that has just been discussed also have their say. In this way, they are included, there is additional feedback and everyone feels obliged to the team and the product. Constant communication with the customer, receiving his feedback and fulfilling his wishes, including an executable product that fully meets his wishes, is more important than contract negotiations . Communication is also characterized by respectful interaction, both within the team and with the customer. Different opinions are accepted.

The developers should be courageous and communicate openly. If a requirement cannot be implemented in one iteration, it is pointed out directly in an open and honest manner. An atmosphere must be created that minimizes conventional disruptions (such as unnatural competition within the team at the expense of the product). In order to promote openness and courage and to face group dynamic , psychological difficulties, a doomsayer can be used to openly and promptly discuss bad news or possible difficulties or a diaboli advocate can be used.

The simplest solution to a problem should be implemented. In each iteration, the entire team focuses precisely on the requirements currently to be implemented. The technical solutions should always be kept as simple as possible.

Principles

There are 14 principles that form a bridge between the abstract values ​​and the concrete applicable practices. These principles should always be taken into account. They are humanity , economic efficiency , mutual benefit , self-equality , improvement , diversity , reflection , running , seizing opportunities , avoiding redundancies , accepting failures , quality , small steps and accepted responsibility .

Software is developed by people. So people are the factor that XP deserves special attention. By creating a human atmosphere, the basic needs of the developer (security, perfection, identification with the group, perspective and understanding) should be met.

The software created or a single functionality must be economical on the one hand and still bring real value. On the other hand, it must be beneficial for both sides and satisfy everyone involved (development team and customer).

The principles of XP

The reuse of existing solutions, including, for example, the numerous different tests that are constantly being run automatically, is important. It is clear to everyone that initial solutions are usually not optimal. The solution is constantly being improved based on feedback and new insights gained. Recognizing ever better solutions is only possible through constant reflection and continuous questioning of the respective approaches in the team. The productivity of this process increases proportionally to the inconsistency of the team consisting of people with different skills and characters . Different opinions are not only tolerated but even encouraged. To this end, a conflict management system must be established.

The functionality of the software must be guaranteed at all times. Although short iterations with constant feedback help keep the project going, failures still need to be factored in. It is quite common and accepted to carry out an implementation that may not be optimal or even flawed at first. These difficulties must be seen as an opportunity and opportunity to further mature the product and the team. An open, constructive approach to the challenges of software development succeeds all the better, the more all those involved are willing to accept their responsibility. Assigning an activity and responsibility to a developer in a disciplinary way is not enough, as he has to actively accept and live the responsibility.

Another important point is the high quality , which according to XP, in contrast to other factors such as resources, functionality or deadline, is not up for discussion. This basic setting differs from many other methods of software development, in which software is to be completed at a certain point in time and with a defined range of functions, which almost always affects the software quality. However, the quality is particularly important in order to keep the product operational, error-free and expandable. In the medium term, software with a good design and high quality is more cost-effective, expandable and less prone to errors than quickly created, so-called quick-and-dirty software .

Good quality also includes avoiding redundancies (unnecessarily repeated or repeated steps or steps that can be automated manually).

By taking quick, small steps, the team remains flexible and can quickly adapt to new framework conditions and respond to feedback. The negative consequences of a single small, unsuccessful step can be compensated for by a new step much faster than would be the case with a single larger step.

Practices

A distinction can be made between traditional and evolutionary practices. The traditional ones are widespread and used in the XP world. The evolutionary ones take on various new findings from the years of use of XP. They refine or modify the original practices slightly, making usage clearer and easier to understand.

XP is often associated with, or reduced to, traditional practices.

Traditional practices

Pair programming
When pair programming , two share programmers a computer - a coded (the driver ) and the other thinks and has the big picture in mind (the partners ). The roles are swapped regularly. This approach increases the transfer of knowledge. Beginners should learn faster from the work of a specialist. The knowledge is distributed. The project is no longer so vulnerable to the failure of an individual. Constant code reviews of development and communication improve the design and find errors more quickly (see also four-eyes principle ).
Collective ownership
Activities are initially not distributed to individuals, but to the whole team. According to the methodology, there is an awareness and obligation to only be able to be successful as a team. Individual team members do not have a monopoly of knowledge . Pair programming and changing areas of application are intended to counteract the tendency for individual people to view parts as their property.
Permanent integration
Continuous integration of the individual components into an operational overall system in short time intervals. According to XP, the more frequently it is integrated, the higher the routine that occurs. Errors are detected early on. The costs associated with the integration should be minimized to almost zero, since the integration is part of a daily step that has to be largely fully automated and stable and tested.
Test-driven development or permanent testing
With test-driven development , the module tests (unit test) are first written before the actual functionality is programmed. As a result, the developer deals early with the design of the code and thinks carefully about his programming work. The tests are carried out after each programming step and provide feedback on the state of development. The tests are automated. Integration tests are carried out in the course of an integration. A distinction is made between a regression test and a module test. While unit tests test individual modules, a regression test is the collective execution of all tests in order to check the unchanged operability of the old functionality that already existed before the iteration. Also, performance tests , where the power and speed characteristics are measured with respect to the required values, are common. The developer receives feedback on how many and which tests were unsuccessful. An acceptance test is the presentation of the status of the product in order to validate the satisfaction of the customer and the usability.
XP best practices
Customer involvement
Close involvement of the customer, that is, the customer specifies the iteration goal with a selection of the user stories to be implemented and shortly afterwards has the opportunity to carry out acceptance tests. Story cards serve as a medium to record the short use cases in the form of user stories . The customer must always be present or at least available. In addition to user stories on story cards, there is also the approach of writing CRC models on CRC cards .
Refactoring
Ongoing refactoring , constant architecture , design and code improvements, also in order to be able to identify and eliminate anti-patterns immediately. XP affirms the existence of code that is imperfect at the beginning. Instead, all parts are subject to constant review. Locations that can be optimized are usually improved immediately or defined as errors ( bugs ) that will be fixed in a later iteration.
No overtime
40-hour week , i.e. H. Overtime should be avoided because it affects the enjoyment of work and, in the medium term, the programmers' ability to concentrate and thus the quality of the product. It has been proven that a developer's productivity decreases through overtime. Work outside of regular working hours is tolerated in individual cases, but is in no way particularly rewarded or expected. Overtime is usually just a sign of bad planning .
Iterations
Short iterations in order to provide the customer with an executable intermediate status of the product at regular intervals. An iteration is a chronologically and technically self-contained unit. Short iterations and the associated acceptance tests allow quick feedback loops between development and customer.
metaphor
Since a latent misunderstanding between the customer and the development team is a common problem in traditionally set up software projects - the developer has difficulties with the customer's technical language and vice versa - the requirements in the customer's technical vocabulary , ideally also by himself, in the form of user Stories described. Everyone speaks one language, which can be reinforced with a glossary . A metaphor is chosen, an everyday story that is similar in content and understandable for both sides.
Coding standards
When programming, the team adheres to standards that enable the team to take responsibility for this task. According to XP, changing use of developers in all areas of the software is only possible if there are common standards.
Simple design
The simplest solution should be sought, i.e. the one that achieves exactly what is desired (and no more). Deliberately general ( generic ) solutions or preparatory measures for potential future requirements are avoided. On the subject of simplicity, the slang acronyms KISS (“Keep it simple, stupid”) and YAGNI (“You Ain't Gonna Need It”) are common.
Planning game
New versions of the software are specified in a planning game , also known as planning poker , and the effort required to implement them is estimated. Both the development team and the customer are involved in this iterative process.

Evolutionary Practices

The evolutionary practices were published five years after the original and replace them. They can be divided into main practices and supplementary accompanying practices . In terms of content, the new practices are comparable to the old, traditional practices. The names of the old practices have been partially modified or broken down into individual sub-practices. Two practices have been dropped: the metaphor was too difficult to convey and, according to the literature, has not caught on. Coding standards are taken for granted and are no longer explicitly mentioned.

Main Practices

The main practices are: Sitting Together , Informative Workplace , Team , Pair-Programming , Energetic Work , Relaxed Work , Stories , Weekly Cycle , Quarterly Cycle , 10-Minute Build , Continuous Integration , Test-First Programming and Incremental Design .

Communication is to be optimized through an open, shared arrangement of the workstations. This form is preferable to a spatial separation of those involved because of the better communication options. The workplace must also be "informative" in that, for example, current tasks, the status of the project and other important information are always clearly visible from the workplace. It is recommended, for example, to attach the user stories centrally on a wall.

The main practices of evolutionary XP

According to XP, the team is more important than the individuals . Joint decisions are made in the awareness that we can only be successful as a community. This is promoted by the fact that the individual technical activities in the planning are not assigned to individual people, but to the team. The team solves problems without the intervention of an outside manager. The essay The Cathedral and the Bazaar also deals with the subject of the self-regulating team . Pair programming with alternating partners should further promote this basic attitude.

The work should run with full motivation and at the same time in a relaxed, collegial atmosphere, as the developers work without overtime and thus maximum productivity is achieved. Safety buffers are taken into account. Promises that cannot be kept are avoided.

The functionality to be developed is described in the form of stories, for example user stories. In a weekly cycle it is decided which customer requests are to be tackled next. The project itself is planned in a quarterly cycle. The specified cycles are guide values, the sizes of which may vary in daily use.

The software to create and perform all the testing required to be completed in a maximum of ten minutes. This 10 minute build minimizes the cost of building and testing the software. Any changes made by a developer should be posted approximately every two hours. This continuous integration is intended to prevent a potential chaos that could arise if the developers rarely entered their changes and enhancements to the product in the central data storage system ( repository ). All employees have the changes quickly available. Both the ten minutes for the build and the two hours for the integration are targets that can vary in specific projects. Especially for large projects with a large amount of source code and developers, a build will take significantly longer and the integration intervals will often be longer. The practices only emphasize direction and provide an ideal value to strive for. Automation can minimize the build time as much as possible.

The development is characterized by the test-first programming approach: the test must be written before the functionality can be implemented. An incremental design that absorbs new knowledge and feedback continuously improves the design of the software.

Accompanying Practices

The accompanying practices are:

  • proper customer involvement
  • incremental deployment
  • Team constancy
  • shrinking teams
  • causal analyzes
  • shared code
  • Coding and testing
  • a central code base
  • daily deployment
  • negotiable, contractual scope of functions
  • Pay-per-use.

The customer takes an active part in the development. He participates in the regular meetings and is actively involved. The inclusion is also evident in the scope of functions to be developed, which must remain negotiable. Several smaller contracts instead of one large contract can minimize risks and increase flexibility in projects operated in this way. Since new versions are constantly being made available iteratively, the customer's payments must be independent of the number of versions made available. The customer does not pay for each version of the software, but per use.

The secondary practices of evolutionary XP

On the one hand, the team should live from its constancy, but it can also be reduced in personnel. The development team must be the same across multiple projects. As part of product development, it acquires the skills to work together as a team, which can be used for further projects. Once the team becomes more productive and productive, its workload should remain constant despite the shift of resources to other teams.

As the central medium, code plays a central role. It is kept in a central, database-like structure ( repository ). There is only one official version (code base) of the system. This code is, figuratively speaking, shared between the developers. Every developer in the team must be able to change "foreign" code at any time (collective code ownership). In addition to the code, there are always the tests that, together with the code, are the only media to be created and made available by the development work (“artifacts”). All other media, for example documentation, are generated solely from code and tests.

Incremental deployment (the transfer of the application to the target system) is carried out to identify difficulties early. If old systems are to be replaced with new software, one part at a time has to be replaced. This procedure is intended to make the conversion easier to plan. The deployment must be carried out incrementally on a daily basis. A new version of the software is to be put into production every day. This makes the deployment routine, minimizes its costs and errors, and enables continuous integration and acceptance tests. If a technical malfunction occurs, a causal analysis must be carried out.

Degree of flexibility vs. stiffness

One of the theoretical foundations of Extreme Programming is the degree of flexibility of the software system to be developed. XP assumes an at least proportional relationship between the opposite of flexibility, known as stiffness , and the maintenance costs for troubleshooting or expanding the system. The more flexible a software system, the lower the maintenance costs, the more rigid, the higher.

Some stiffness criteria:

  • The number of redundant or unused features
  • Bad, missing, difficult to understand or too extensive documentation
  • A difficult to understand or inflexible design
  • Missing regression tests
  • A cumbersome overall system

The flexibility criteria are the opposite of the stiffness criteria, for example an easy to understand and flexible design.

According to XP, some of the mechanisms defined as part of Extreme Programming serve to increase flexibility:

  • The test-driven development ensures sufficient availability of regression tests and improved testability of the software
  • The constant refactoring leads to the elimination of errors, an easily understandable and flexible design as well as good documentation
  • Continuous integration inevitably requires a lightweight overall system
  • User stories are used to determine the functionality to be developed and to work it out between the customer and the development team

Origin and demarcation

XP is a representative of agile software development. Compared to traditional process models, it chooses alternative approaches to address challenges during software development.

Traditional procedural models

In process models that are traditional from today's perspective , the software development process is organized in successive phases . After years of using traditional procedural models, such as the waterfall model used from 1970, those responsible for the project have, from the point of view of the XP representatives, insufficiently understood how to get the problems and risks of software development under control. Many projects never came to a close or exceeded planning in terms of time and / or costs. Many projects that run over a long period of time covered the requirements specified at the beginning, but did not take sufficient account of the fact that requirements can change or that it is only in the course of a project that the customer really knows what the end result should look like. Success and difficulties of software projects delivering Chaos Report from The Standish Group regularly depth research, such as the 1994th

In contrast to traditional process models, the development process in XP runs iteratively in short cycles through all disciplines of classic software development (e.g. requirements analysis, design , implementation , testing ). With this incremental procedure, only the features required in the current iteration step are realized (implemented). This makes XP lighter : no complete technical specification of the solution to be developed is required (for example, there is no requirement specification ).

History of XP

Extreme programming , and with it standards like JUnit, were developed by Kent Beck , Ward Cunningham and Ron Jeffries (all first signatories of the Agile Manifesto ) while working on the Comprehensive Compensation System project at Chrysler to create software. Work on the so-called C3 project began in 1995 and was discontinued in 2000 after the takeover by Daimler. The software developed in the process was used in the area of payroll accounting and was mainly based on small talk . The C3 project was originally implemented according to the waterfall model. After almost a year there was no significant progress, the development approach was changed. The project was characterized by frequently changing requirements and high employee turnover.

XP is an agile process model. The following table compares the core disciplines identified by XP with the historical, widespread approach and its risks of software development. Companies that do not use XP can use procedural models that - consciously or unconsciously - deal positively with these disciplines.

Common XP core disciplines and risks with traditional approach
practice Correct procedure after XP Traditional or wrong approach / risk after XP
communication Constant exchange is encouraged and expected. Everyone has to solve their tasks first.
courage Open atmosphere. Fear of missed appointments and misunderstandings with customers.
Collective ownership Program code, documents, etc. belong to the team. Everyone only feels responsible for their artifacts.
Pair programming Two at the computer. Everyone wants and must first look at their assigned tasks.
integration Continuous integrations allow feedback and increase quality. Seldom integrations, as they are supposedly useless and a waste of time.
Test-driven development Testing is very important. Testing only takes time. Few manual tests.
Customer involvement The customer is called to actively participate. The customer is seldom a real partner, just the "other side of the contract".
Refactoring Sub-optimal design and errors are accepted. Mistakes are frowned upon. Artifacts created supposedly always run perfectly.
No overtime Compliance with regular working hours. Constant, regular exceeding of regular working hours.
Iterations A release is broken down into many handy iterations. Iterations are not necessary, a release is being worked on.
Stand-up meeting Daily, structured exchange. Big, long, infrequent project meetings. The number of people and the content are often too bloated.
documentation Where it makes sense. Important artifact. Everything must be documented in a standardized manner. Documentation is not used, however.
metaphor A common vocabulary. Customer and development speak in two languages, often past one another.
team The team is important. There are no roles. Feedback is expected from everyone. Specialization. Isolation. Knowledge monopolies.
Standards Standards where it makes sense. Overregulation. Rigid process.
quality Inherent component. The first factor to be neglected when time or money is tight.

Due to the growing use, XP is further optimized: the more projects are developed according to XP, the more experience flows into the further development of XP. Since it is also a sum of best practices , it can be said: "In practice, it is adapted for practice".

Other agile process models

The lowest common denominator of all agile process models is the "Agile Manifesto":

  • Individuals and interactions take precedence over processes and tools
  • Executable software has priority over extensive documentation
  • Cooperation with the customer has priority over contract negotiations
  • Responding to changes has priority over strict tracking of plans

In addition to XP, Scrum has also achieved a certain level of awareness. In addition to many similarities with XP, Scrum provides specifications regarding iteration length, logging and procedures in certain areas. Scrum uses its own vocabulary.

Another discipline that is often cited in this context is feature driven development , a methodology that also focuses on the functionality to be provided.

Similarities between XP and Kaizen , a concept developed in Japan primarily in the auto industry ( continuous improvement process ) to ensure quality in the manufacturing process and optimize manufacturing and management costs using “leaner” approaches ( lean production ), cannot be overlooked.

Another agile process model is Crystal , a family of methods whose members are usually marked with colors.

Traditional procedural models , such as the V-model , have since been enriched with new findings in software development. As a result, the successor, the V-Modell XT , uses agile approaches. The V-Modell XT no longer specifies a strict sequence of phases to be run through.

XP in projects

Today, over ten years after the first XP steps, XP and other agile methods are enjoying growing popularity. Research by Forrester Research showed that in North America and Europe in 2005 around 14% of all projects were carried out using agile methods (of which XP is the most common) and many others are considering a deployment.

Users of XPs include both companies that produce and sell software commercially as well as companies whose actual business is not the creation of software: Dresdner Kleinwort Wasserstein , Encyclopaedia Britannica , Fidelity , Progressive , Capital One , Royal & Sunalliance , Channel One , Daedalos International , Gemplus , it-agile , Qwest and O&O Services .

Many companies publicly report their experiences with XP. They describe how they used XP in detail, which difficulties arose and how the success could be assessed. Symantec has published its change in the process model towards XP. With XP, Saber Airline Solutions has reduced both errors in their software and development time:

"It was XP [...] that produced the dramatic quality improvements [...] You have the weaker people paired with the stronger people, and business knowledge and coding knowledge are transferred very quickly."

- Gary Anthes

criticism

This article or the following section is not adequately provided with supporting documents ( e.g. individual evidence ). Information without sufficient evidence could be removed soon. Please help Wikipedia by researching the information and including good evidence.

The all-or-nothing principle

According to some protagonists of the XP approach, the individual methods work so closely together that they should be used without exception. Even not using individual methods should massively limit the effectiveness of the overall approach. However, since the use of the methods is often based on numerous requirements (see e.g. the sections The Ideal Client and The Ideal Programmer ), it is likely that individual methods cannot be used in specific projects. This then provides a simple explanation for the failure of XP projects: Most of the time, a neglected method can be found, so that the failure cannot be attributed to XP as an overall approach, but to the neglect of this method. In the meantime it is controversial whether all methods actually have to be used in order to increase the probability of a successful project through XP.

Moving requirements

One of the main reasons for specifying requirements in classic procedural models is to create a reliable basis for development work so that changes to the implementation that are necessary later remain as small as possible. The implicit assumption of this attitude is that the later changes need to be made, the more expensive it becomes. Although this assumption has been confirmed in many projects, XP assumes to a certain extent that changes are generally “cheap” if they are carried out continuously. XP also implicitly denies the assumption that later changes will be more expensive and justifies this with the fact that the changes then do not have to be implemented in several artifacts at the same time (specification, documentation, source code) - as in other approaches.

The assumptions of XP in this regard certainly apply when the requirements are inevitably subject to changes. In this case, specifying the requirements can sometimes involve greater effort than omitting the specification - if only because the specification always has to be changed. However, it is unclear why it should be detrimental to specify requirements at least if they are certain to last until the end of the project. By not using a specification, you run the risk of overlooking requirements or misjudging their meaning. It is also conceivable that the customer will consciously change his requirements in the course of the project, but tell the development team that his view has so far only been misunderstood. With regard to the assessment that later changes are not more expensive than early ones, the objection is that late changes can be very expensive if they affect the design of the application in a fundamental way. Changing the architecture of an application cannot be carried out without considerable effort, indeed it can possibly be more expensive than a new implementation. It is not evident and therefore appears to be a question of faith whether XP can prevent such situations through the use of its methods.

The ideal customer

The use of XP demands a customer who is keen to experiment, who not only has to forego a number of common approaches, but also has to expend considerable resources himself. Some of the things a customer will not want to do without include:

documentation
Software can be introduced in complex system landscapes , so that a wide variety of participants (e.g. those responsible for interfaces, employees from external providers, etc.) have to gain knowledge of technical details. In such environments, company guidelines usually prohibit the waiver of detailed documentation. But even if this is not the case, it remains to be clarified how knowledge of technical details should be conveyed to those affected if there is no documentation, and even more if it must be assumed that future changes will affect the relevant technical details.
specification
Particularly when concluding work contracts, the question arises for the customer as to what exactly the trade actually consists of that is acquired through the agreed price. Furthermore, company-wide guidelines can require the creation of a specification.
Events
Since the project manager representative of the customer often has to report the project progress himself, the completion of certain functions on fixed dates, i.e. the preparation of a project plan, is often an indispensable part of the joint approach.

Beyond these points, the “customer on site” principle represents a requirement that can only very rarely be implemented in reality. In order to be able to perform his task, the employee must obviously have a considerable amount of knowledge. If this is the case, however, the employee will most likely not be dispensable for several months in his own company either. It is also not uncommon for IT projects to be outsourced to external service providers in order to limit their own resources. The customer-on-site principle thus represents one of the most difficult requirements of extreme programming to meet.

The ideal programmer

XP makes numerous demands on the programmers involved.

  • The programmers must have very good skills, since the frequent change-based approach using refactorings cannot be implemented without extensive programming experience and without the use of suitable tools.
  • Programmers often have a very developed ego, which manifests itself in a great conviction of "correct solutions" and a certain sense of ownership with regard to the written code. Not all programmers can handle the fact that - according to XP - everyone is allowed to modify everyone else's code.
  • XP has a number of features that require a high level of discipline (such as the test-first approach, constantly refactoring, programming in pairs, etc.) and some others that encourage a degree of indiscipline (e.g. B. omitting specification and documentation). There is a risk that the latter approaches will be emphasized over the former. Adhering to the approaches with a high degree of discipline requires capable participants and functioning self-regulation of the team. However, since a person responsible for the project may not have been named, the question is who will ultimately ensure that all aspects are consistently observed.

The requirements show that XP cannot be applied to just any team.

Limited team and therefore project size

Several XP methods require a high degree of mutual information and thus a high degree of communication between those involved. Continuous refactoring, for example, may require changes to shared components that the entire team must be informed about. The lack of a project manager requires mutual agreements on the division of labor. Since there is also a lack of precise specification and documentation, all information for implementation must be available in the minds of those involved. However, with the size of the team the communication effort increases quadratically, so that XP projects have a natural limit in terms of team size. The maximum size is usually set at ten team members.

Not suitable for fixed-price projects

Another common point of criticism is that XP is not suitable for fixed-price projects . Since the customer pays a fixed price, the contractor must ensure in some way that he only has to provide a fixed service for this price. The provision of services until the customer is satisfied can result in ever new customer requirements, so that the effort for the realization cannot be foreseen. Defining the fixed service as the content of the contract for work would, however, correspond to a specification and is therefore frowned upon in XP. There are a few approaches to make XP compatible with fixed-price projects:

  • Insurance premiums on the estimate
  • User stories (or story cards) become the subject of the contract
  • Special pricing models cost price limit , phase fixed price or request unit price .

However, the effectiveness of these approaches is unclear. User stories can be too imprecise to protect the trade against unexpected technical requirements. The mentioned price models only partially correspond to a fixed price and thus a contract for work and services, so that it is questionable whether a customer would accept this by specifying a fixed price. The same applies to insurance premiums.

Fixed completion dates

The iterative approach of XP and the lack of a project plan already suggest that the completion of a technically desired range of functions on a set date cannot be guaranteed without further ado. Although something will be ready by the set date (since the focus of each iteration is on executable, possibly even production-capable software), what technical aspects these actually are cannot be predetermined - all the less than overtime is frowned upon and the extent more necessary Refactorings are difficult to estimate due to flexible requirements.

Use in distributed environments

XP is considered to be more difficult to use than conventional models in distributed environments. The direct contact of the developer with each other and with customers is problematic if different customers exist or the parties working at remote locations, such as in partially outsourced development ( outsourcing ).

Criticism of individual practices

The repeated creation of test cases and the automated, permanent execution of the tests can be time- consuming in complex or concurrent applications and distributed systems . If roles do not develop, everyone has to know everything instead of setting individual priorities in the team (classic example: GUI development and database development), which can reduce the overall performance of the team.

Personnel policy

Since the team is in the foreground, individual developers may not be rewarded according to the scope of their developed functionality. In particular, the fee contract is not a suitable remuneration model when using the XP process model.

See also

  • Crystal , agile process model
  • Scrum , agile process model that harmonizes well with XP

literature

Web links

German

English

Specialist conferences on the topic

Individual evidence

  1. ↑ Tom DeMarco, Timothy Lister: Bärentango , Hanser Fachbuch, March 2003, ISBN 3-446-22333-9 .
  2. ↑ Kent Beck: Extreme Programming Explained. Embrace Change . 1st Edition, Addison-Wesley, 2000, ISBN 0-201-61641-6 .
  3. ↑ Kent Beck, Cynthia Andres: Extreme Programming Explained. Embrace Change . 2nd Edition, Addison-Wesley, December 2004, ISBN 0-321-27865-8 .
  4. ^ The Standish Group: The CHAOS Report (1994). Retrieved January 12, 2020 . (English), June 12, 2006.
  5. ↑ Chrysler Comprehensive Compensation System: Chrysler Goes To Extremes ( Memento from January 13, 2015 in the Internet Archive ) (PDF, English; 188 kB), June 9, 2006.
  6. ↑ Chrysler Comprehensive Compensation System: Extreme Programming Considered Harmful for Reliable Software Development (PDF), February 6, 2002.
  7. ^ Chrysler Comprehensive Compensation: Project to replace existing payroll applications with a single application. (English), October 16, 2013.
  8. ^ Ward Cunningham, Kent Beck et al .: Manifesto for Agile Software Development (English), 2001.
  9. ^ Forrester Research: Corporate IT Leads The Second Wave Of Agile Adoption ( Memento of October 16, 2007 in the Internet Archive ) (English), November 30, 2005.
  10. ↑ C2: Companies Doing Xp , July 23, 2006.
  11. ^ Object Mentor, Inc .: Companies using XP, Customers ( Memento of April 23, 2006 in the Internet Archive ) (English), July 23, 2006.
  12. ↑ Dr. Dobb's: Going to Extremes , January 2, 2002.
  13. ↑ a b Computerworld: Saber takes extreme measures ( Memento of 13 March 2009 at the Internet Archive ) (English), March 29 of 2004.
  14. ↑ Henrik Kniberg: Scrum and XP from the Trenches (PDF, English), June 27, 2007.
This version was added to the list of articles worth reading on July 17, 2006 .