|
|
Projects
|
|
"Welcome changing requirements, even late in development.
Agile processes harness change for the customer's competitive advantage."
|
|
Extreme Programming
An introduction...
eXtreme Programming (XP) is a method in or approach to software engineering, formulated by
Kent Beck,
Ward Cunningham,
and Ron Jeffries.
Kent Beck wrote the first book on the topic, Extreme Programming Explained: Embrace Change, first published in 1999.
It is the most popular of several agile software development methodologies.
His recent second edition is a restatement of Extreme Programming in light of the last five years of additional experience.
XP is a lightweight discipline of software development based on principles of simplicity, communication, feedback, and courage.
XP is designed for use with small teams who need to develop software quickly in an environment of rapidly-changing requirements.
The 12 Rules and Practices of Extreme Programming
Planning Process - Sometimes called the planning game, the XP planning process allows the customer to define the business value of desired features, and uses cost estimates provided by the programmers, to choose what needs to be done and what needs to be deferred.
The effect of XP's planning process is that it is easy to steer the project to success.
Small Releases - XP teams put a simple system into production early, and update it frequently on a very short cycle.
Metaphor - XP teams use a common "system of names" and a common system description that guides development and communication.
Simple Design - A program built with XP should be the simplest program that meets the current requirements.
There is not much building "for the future". Instead, the focus is on providing business value.
Of course it is necessary to ensure that you have a good design, and in XP this is brought about through "refactoring", discussed below.
Testing - XP teams focus on validation of the software at all times.
Programmers develop software by writing tests first, then software that fulfills the requirements reflected in the tests.
Customers provide acceptance tests that enable them to be certain that the features they need are provided.
Refactoring - XP teams improve the design of the system throughout the entire development.
This is done by keeping the software clean: without duplication, with high communication, simple, yet complete.
Pair Programming - XP programmers write all production code in pairs, two programmers working together at one machine.
Pair programming has been shown by many experiments to produce better software at similar or lower cost than programmers working alone.
Collective Code Ownership - All the code belongs to all the programmers.
An off-shoot of pair programming all team members have a better understanding of the entire code base, as opposed to
individual programmers coding modules in isolated cubicles that later needs to be integrated with the code of other programmers.
This lets the team go at full speed, because when something needs changing, it can be changed without delay.
Continuous Integration - XP teams integrate and build the software system multiple times per day.
This keeps all the programmers on the same page, and enables very rapid progress.
Perhaps surprisingly, integrating more frequently tends to eliminate integration problems that plague teams who integrate less often.
40-hour work week - Tired programmers make more mistakes.
XP teams do not work excessive overtime, keeping themselves fresh, healthy, and effective.
On-Site Customer - Tired programmers make more mistakes.
XP teams do not work excessive overtime, keeping themselves fresh, healthy, and effective.
Coding Standard - An XP project is steered by a dedicated individual who is empowered to determine requirements, set priorities,
and answer questions as the programmers have them.
The effect of being there is that communication improves, with less hard-copy documentation
- often one of the most expensive parts of a software project.
There is much to read on XProgramming.com
-
XP Magazine
includes various articles discussing aspects of XP, from practical, philosophical, and whimsical viewpoints.
-
XPublications
points to magazine and other external publications relating to XP that
are available on the web.
-
XPractices
must be read with caution. It describes the practices used by the C3
project, XP's first project. The team was very enthusiastic about XP,
and the author of the writeup (your host) didn't always do the best
job of describing what C3 did and why they did it. If some part of the
writeup seems too extreme, check other resources before concluding
that we're all crazy. It's just me.
-
Extreme Programming Installed, on the home page, points today to a late
draft of the book. When it is published and we get a clean copy, we
will begin converting it to pages on the site. For best results, of
course, you should buy several copies of the book.
Please check these links, and the other links on the site. There is a great deal of material here.
We hope you will find it interesting and tantalizing, and that you'll want to learn more about XP.
|
