|
CIDM Associate
The first time I heard the words "extreme programming," I cringed. The
words conjure visions of barefooted programmers coding systems in the
ultimate vacuum 24 hours a day 7 days a week, ordering pizza for every
meal, with zero planning and zero communication with each other and
customers. I could not have been more wrong.
According to the book Extreme Programming Explained by Kent Beck,
extreme programming (XP) is "a lightweight, efficient, low-risk, flexible,
predictable, scientific, and fun way to develop software."
Principles
Extreme programming is a system development life cycle (SDLC)
methodology that takes common sense principles and practices to the
extreme. For example,
| Principle/Practice |
Description |
| Pair Programming |
Coding is done in pairs of programmers so that code reviews are ongoing. |
| Continuous Testing |
Everyone--programmers (unit tests) and customers (functional tests)--tests all the time.
There is no choice of whether you will test or not. If testing is not done, the project is not
extreme. |
| Refactoring |
Everyone is responsible for design on a daily basis. |
| Simplicity |
Supporting current functionality only (vs. designing for the future) keeps the design simple.
The person responsible for a single task is also responsible for estimating the time it will take to
accomplish that task. |
| Metaphor |
Everyone works to define and refine the architecture all the time. |
| Continuous Integration |
Everyone integrates and tests several times a day. |
| Incremental Planning (The Planning Game) |
Iterations are really, really short--seconds and minutes and hours, not weeks and months
and years. |
Values
The five values of XP are communication, simplicity, feedback, courage,
and respect.
XP uses many practices that cannot be done without communicating, such as
the use of development guidelines, pair programming, unit testing, and task
estimation.
XP takes the approach that simple is better. Traditional development looks to
the future to anticipate the needs of the user, taking a chance that tomorrow the
user will actually need that functionality. XP asks the question "What is the
simplest thing that could possibly work today?" The simpler your system, the
less you have to communicate and the greater the chance of developing a system
your customers will actually use.
Feedback is the next XP value. One of the flaws in a traditional development
environment is the occupational hazard of optimism. This results in incomplete
or no testing. In an XP environment, programmers write unit tests for all the
logic in the system that could possibly break. Unit tests give them
minute-by-minute feedback on the state of their system. No one leaves the testing
environment until 100% of the tests run without problems. Therefore, when the
next pair of programmers tests their code, they know they are starting with a
clean slate.
The value of courage is dependent on the first three, otherwise courage is
"just plain hacking." The team must have courage to recognize when there is a flaw
in the architecture or in the code itself. They must be psychologically capable of
throwing code out when they know it is not going very well. In
Extreme Programming Explained, Beck advises "If the end of the day is coming
and the code is a little out of control, toss it."
The last value is respect. If members of the team do not care about each other and
what they are doing, XP is doomed.
Resources
In addition to programmers and the project manager, an XP project also employs
a coach. The coach's job is to notice when people are not communicating and to
help keep the lines of communication open.
Another non-traditional member of the development team is the customer. The
customer actually has workspace in the same area as the developers. That customer
continues to do his or her job but has the primary responsibility of supporting the
XP project team as subject matter expert.
The ideal XP environment is an open area with cubicles around the periphery.
Everyone sits in the open area to work and keeps their personal items in a cubicle,
where they can also make personal phone calls. The open area concept facilitates
communication.
Deliverables
The information below shows the differences between the deliverables of a
traditional SDLC and the extreme programming SDLC.
| Phase |
Document Deliverables in a Traditional SDLC Environment |
Document Deliverables in an XP Environment |
Phase 1
Needs Analysis |
Static system requirements document |
Software development guidelines (must be in place for the XP effort to be successful)
Dynamic business requirements
Dynamic system requirements
Note: These documents are continuously refined during the life of the project.
|
Phase 2
Design |
Static functional design
Static detailed design |
Dynamic functional design
Dynamic detailed design
Note: These documents are continuously refined during the life of the project. |
Phase 3
Code |
The code itself
Inline comments
Unit test documents (test plans, test scripts, test results) |
The code itself
Inline comments
"To-do" cards to record ideas for variations
Unit test cases (stories)
"To-do" cards for variations resulting from unit test cases
Note: Development is driven by tests. |
Phase 4
System Test |
Test plans
Test scripts
Test results |
Note: In an XP environment, system testing occurs at the same time as unit testing.
System test cases (stories)
"To-do" cards for variations resulting from system test cases |
Phase 5
Implementation |
User manuals
Administration manuals
Training manuals
Install guides |
User manuals
Administration manuals
Training manuals
Install guides |
Phase 6
Maintenance |
Maintenance plan and procedures
Change request forms or system |
Maintenance plan and procedures
Change request forms or system |
The Role of the Technical Communicator
Because of the speed at which an XP environment moves, the technical communicator
will not be the one developing all the systems documentation. The job of the technical
communicator in this environment is to facilitate the documentation process by helping
develop the development guidelines and creating templates to ensure easy communication.
There needs to be a "context in which good designs are created, bad designs are fixed, and
the current design is learned by everyone who needs to learn it."
Additional Resources
Order the book Extreme Programming Explained by Kent Beck. It will help you
determine what you need for this environment.
Also, here are some helpful Web sites:
http://www.extremeprogramming.org
http://www.xprogramming.com
http://ootips.org/xp.html
|
