Extreme Programming

From Wikipedia, the free encyclopedia

Jump to: navigation, search

Planning and feedback loops in Extreme Programming (XP) with the time frames of the multiple loops.

Software development process
Activities and steps
Requirements · Specification Architecture · Design Implementation · Testing Deployment · Maintenance
Models
Agile · Cleanroom · DSDM Iterative · RAD · RUP · Spiral Waterfall · XP · Scrum · V-Model FDD
Supporting disciplines
Configuration management Documentation Quality assurance (SQA) Project management User experience design
Tools
Compiler · Debugger · Profiler GUI designer Integrated development environment
This box: view • talk

Extreme Programming (XP) is a software engineering methodology (and a form of agile software development)prescribing a set of daily stakeholder practices that embody and encourage particular XP values (below). Proponents believe that exercising these practices—traditional software engineering practices taken to so-called "extreme" levels—leads to a development process that is more responsive to customer needs ("agile") than traditional methods, while creating software of better quality.

Proponents of Extreme Programming and agile methodologies in general regard ongoing changes to requirements as a natural, inescapable and desirable aspect of software development projects; they believe that adaptability to changing requirements at any point during the project life is a more realistic and better approach than attempting to define all requirements at the beginning of a project and then expending effort to control changes to the requirements.

However, XP has been noted for several potential drawbacks, as compared to more document-based methodologies, including problems with unstable requirements, no documented compromises of user conflicts, and lack of an overall design spec or document (see below: Controversial aspects).

Contents [hide] 1 History 1.1 Origins 1.2 Current state 2 Extreme Programming topics 2.1 Goals of XP 2.2 XP activities 2.3 XP values 2.4 XP rules 2.5 Rules of Engagement 2.6 Rules of play 2.7 Principles 3 Practices 4 Application of Extreme Programming 5 Controversial aspects 6 See also 7 References 8 Further reading 9 External links

History

Extreme Programming was created by Kent Beck during his work on the Chrysler Comprehensive Compensation System (C3) payroll project.Beck became the C3 project leader in March 1996 and began to refine the development method used in the project and wrote a book on the method (in October 1999, Extreme Programming Explained was published). Chrysler cancelled the C3 project in February 2000^{[citation needed]}.

Although Extreme Programming itself is relatively new, many of its practices have been around for some time; the methodology, after all, takes "best practices" to extreme levels. For example, the "practice of test-first development, planning and writing tests before each micro-increment" was used as early as NASA's Project Mercury, in the early 1960s (Larman 2003). Refactoring, modularity, bottom-up and incremental design were described by Leo Brodie in his book published in 1984.

Origins

Most software development in the 1990s was shaped by two major influences: internally, object-oriented programming replaced procedural programming as the programming paradigm favored by some in the industry; externally, the rise of the Internet and the dot-com boom emphasized speed-to-market and company-growth as competitive business factors. Rapidly-changing requirements demanded shorter product life-cycles, and were often incompatible with traditional methods of software development.

The Chrysler Comprehensive Compensation System was started in order to determine the best way to use object technologies, using the payroll systems at Chrysler as the object of research, with Smalltalk as the language and GemStone as the data access layer. They brought in Kent Beck, a prominent Smalltalk practitioner, to do performance tuning on the system, but his role expanded as he noted several issues they were having with their development process. He took this opportunity to propose and implement some changes in their practices based on his work with his frequent collaborator, Ward Cunningham.

The first time I was asked to lead a team, I asked them to do a little bit of the things I thought were sensible, like testing and reviews. The second time there was a lot more on the line. I thought, "Damn the torpedoes, at least this will make a good article," [and] asked the team to crank up all the knobs to 10 on the things I thought were essential and leave out everything else. —Kent Beck

Beck invited Ron Jeffries to the project to help develop and refine these methods. Jeffries thereafter acted as a coach to instill the practices as habits in the C3 team.

Information about the principles and practices behind XP was disseminated to the wider world through discussions on the original Wiki, Cunningham's WikiWikiWeb. Various contributors discussed and expanded upon the ideas, and some spin-off methodologies resulted (see agile software development)

Current state

XP created quite a buzz in the late 1990s and early 2000s, seeing adoption in a number of environments radically different from its origins.

The high discipline required by the original practices often went by the wayside, causing some of these practices that were thought too rigid to be deprecated or left undone on individual sites. Agile development practices have not stood still, and XP is still evolving, assimilating more lessons from experiences in the field. In the second edition

Extreme Programming topics

Goals of XP

"Extreme Programming Explained" describes Extreme Programming as being:

• An attempt to reconcile humanity and productivity
• A mechanism for social change
• A path to improvement
• A style of development
• A software development discipline

The main aim of XP is to reduce the cost of change. In traditional system development methods (such as SSADM) 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 (a common feature of software engineering projects) will be high.

XP sets out to reduce 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.

XP activities

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

Coding

Listening

Programmers do not necessarily know anything about the business side of the system under development. The function of the system is determined by the business side. For the programmers to find what the functionality of the system should be, they have to listen to business. Programmers have to listen "in the large": they have to listen to what the customer needs. Also, they have to try to understand the business problem, and to give the customer feedback about his or her problem, to improve the customer's own understanding of his or her problem. Communication between the customer and programmer is further addressed in The Planning Game.

From the point of view of simplicity, one could say that system development doesn't need more than coding, testing and listening. If those activities are performed well, the result should always be a system that works. In practice, this will not work. One can come a long way without designing but at a given time one will get stuck. The system becomes too complex and the dependencies within the system cease to be clear. One can avoid this by creating a design structure that organizes the logic in the system. Good design will avoid lots of dependencies within a system; this means that changing one part of

Feedback

Within Extreme Programming, feedback relates to different dimensions of the system development:

• Feedback from the system: by writing unit tests,^[5] or running periodic integration tests, the programmers have direct feedback from the state of the system after implementing changes.
• Feedback from the customer: The functional tests (aka acceptance 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.

Feedback is closely related to communication and simplicity. Flaws in the system are easily communicated by writing a unit test that proves a certain piece of code will break. The direct feedback from the system tells programmers to recode this part. A customer is able to test the system periodically according to the functional requirements, known as user stories.To quote Kent Beck, "Optimism is an occupational hazard of programming, feedback is the treatment."^{[citation needed]}

the system will not affect other parts of the system

Rules of play

Rules of play that make XP unique are defined below; these rules are based on XP’s values: Communication, Simplicity, Feedback, Courage.

• Continuous testing: Work produced must be continuously validated through testing.
• Clearness and quality of code: All code written for potential use in the software product must clearly express every concept and have clarity, contain no duplication and no superfluous parts and pass all the unit tests.
• Common vocabulary: There is a sketch of the product guide all development with a simple shared story of how the whole system works. So everyone involved could grasp the essence of the project in a term universally understood.
• Everybody has the authority: Everybody has the authority and at least two people have the understanding necessary to do any task

Principles

The principles that form the basis of XP are based on the values just described and are intended to foster decisions in a system development project. The principles are intended to be more concrete than the values and more easily translated to guidance in a practical situation.

http://www.sei.cmu.edu/cmmi/presentations/sepg05.presentations/jarvis-gristock.pd