TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
The subject of extreme programming has come up again and this
nice summary came in about the same time. Perhaps of interest.
-- Meg
--------------------------------------------------------
Extract from:
A monthly e-newsletter from The Center for
Information-Development Management (CIDM)
JoAnn Hackos, PhD, Center Director
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,
*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 a 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 1--Needs Analysis
Traditional: Static system requirements document
XP: 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
Traditional: Static functional design
Static detailed design
XP: Dynamic functional design
Dynamic detailed design
Note: These documents are continuously refined
during the life of the project.
*Phase 3--Code
Traditional: The code itself
Inline comments
Unit test documents (test plans, test scripts,
test results)
XP: 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
Traditional: Test plans
Test scripts
Test results
XP: 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
Traditional: User manuals
Administration manuals
Training manuals
Install guides
XP: User manuals
Administration manuals
Training manuals
Install guides
*Phase 6--Maintenance
Traditional: Maintenance plan and procedures
Change request forms or system
XP: 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.
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.com/
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Develop HTML-Based Help with Macromedia Dreamweaver 4 ($100 STC Discount)
**WEST COAST LOCATIONS** San Jose (Mar 1-2), San Francisco (Apr 16-17) http://www.weisner.com/training/dreamweaver_help.htm or 800-646-9989.
Sponsored by ForeFront, Inc., maker of ForeHelp Help authoring tools
for print, WinHelp, HTML Help, JavaHelp, and cross-platform InterHelp
See www.forehelp.com for more information and free evaluation downloads
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
