What is eXtreme Programming (XP)?
Here are some things various authors have
said about eXtreme Programming:
-
eXtreme Programming is a lightweight, efficient,
low-risk, flexible, predictable, scientific and
fun way to to develop software.
(from Kent Beck, one of the "fathers of XP",
quoted in DH Steinberg and DW Palmer, Extreme
Software Engineering)
-
eXtreme Programming is a development methodology
that strives for simplicity by removing formal
structure and focusing on best practices.
(from Cay Horstmann, Big Java, p. 619,
and my personal favorite)
-
eXtreme Programming is a discipline of software
development based on values of simplicity,
communication, feedback, and courage. It works
by bringing the whole team together in the
presence of simple practices, with enough
feedback to enable the team to see where they
are and to tune the practices to their unique
situation.
(from Ron Jeffries, one of the "fathers of XP",
quoted in DH Steinberg and DW Palmer, Extreme
Software Engineering)
-
eXtreme Programming is a process model and
methodology that is gaining popularity for
small projects that involve uncertain,
changing requirements and other sources of
high risk. Proponents of XP believe in a
disciplined, but lightweight process.
(from T. C. Lethbridge and R. Laganiere,
Object-Oriented Software Engineering, p. 407)
A Brief History of XP
Not much has yet been written about the "history"
of XP, since it is hardly old enough yet to even
have a "history". However,
the "fathers of eXtreme Programming" are often
considered to be Ward Cunningham (the inventor),
Kent Beck (the articulator), and Ron Jeffries
(the realizer). Beck and Jeffries worked together
at Chrysler Corporation on the first large-scale
project to use XP, and since Beck's "Extreme Programming
Explained" was published by Addison-Wesley in 2000
there has been an increasing number of books, papers,
conferences and web sites devoted to the topic.
Overview of XP
eXtreme Programming
may be characterized, at least partly, as follows:
-
Shared Core Values
-
Simplicity: Do the simplest thing that could
possibly work.
-
Communication: Focus on oral, not documents,
reports and plans.
-
Feedback: Nagging questions answered by constant,
concrete feedback.
-
Courage: Have the confidence to work quickly and
redevelop as soon and as often as necessary.
-
Five Main Operational Principles (based on the core values)
-
Assume Simplicity: Treat each problem as if it can
be solved simply.
-
Rapid Feedback: Use short feedback loops to learn
quickly if to-date product meets customer needs.
-
Incremental Change: Solve problems with a series
of small changes (applies to planning, development
and design).
-
Embrace Change: Preserve options while solving pressing
problems.
-
Quality Work: What's to say? Emphasize test-first
programming.
-
Here are the original "12 XP Practices" as described by
Beck. If you look at the very latest writings you may find
these have changed a bit and perhaps even increased in number,
but the original 12 still convey the essence of XP. (See an
update in Extreme Software Engineering, by Steinberg and
Palmer, for example.)
-
The Planning Game: quickly derive a high-level plan
for the next release or iteration
-
Small Releases: cycles that consist of frequent
releases, each delivering "business value"
-
Metaphor: develop a common vision, terms and language
used by all to describe the project
-
Simple Design: code does the simplest thing that would work
-
Testing: use automated tests; develop tests first and
implement them in the "test harness"
-
Refactoring: improve the design of existing code
without changing the system's observable behavior
-
Pair Programming: two developers it at the same workstation
and share development tasks
-
Collective Ownership: anyone can improve, or change, any
part of the code at any time
-
Continuous Integration: components of the system are
"built" or "integrated" many times each day
-
40-Hour Work Week: regular work hours ensure quality
-
On-Site Customer: customer representative is on-site
and forms part of the team
-
Coding Standards: a group of conventions that everyone
agrees to develop under
-
Activities (What do you actually do in XP?)
-
Listening: to customers and other developers
(remember: there's less documentation)
-
Testing (and more testing): integral, not an
afterthought; write tests before coding; not
limited to accuracy or defect measurement, but
also tests for performance and conformance
-
Coding: pair programming, refactoring,and code review
-
Designing: should evolve and grow throughout the
project; not static, but dynamic and team-based
(software always in a state of being designed)
List of All Topics