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.
Re: Xtreme Programming / Agile Development and Documentation
Subject:Re: Xtreme Programming / Agile Development and Documentation From:Edwin Skau <eddy -dot- skau -at- gmail -dot- com> To:techwr-l -at- lists -dot- techwr-l -dot- com Date:Sat, 19 Nov 2005 09:25:14 +0530
Hi
I once worked for a company that liked to call what they did "Xtreme
programming". There were also other projects that followed the
"Xtreme" model for which I provided documentation services as part of
a development outsourcing company. A lot of the time, I was ready for
a voice to come floating over the void saying, "Let there be Light!".
While it can be quite delightful for (those) developers who revel in
the opportunity to jump into coding without the responsibility of
recording more than the rudimentary architecture and data flow, it can
be hell on a writer.
In such projects, you would typically benefit from having a writer
assigned to each individual team involved. This writer would have to
stalk the team and pick up inspiration and tips from all three CSI
programs (also Numbers). A crash course in third-degree interrogation
methods would also come in handy ("We haf vays to make you talk,
programmer!!!).
OK that's from the experience I've had in firms where the term Xtreme
programming has been used as an excuse for highly reactive management
decisions and utter chaos (CMM level -3).
On the other hand, strategic Xtreme programming with a reasonable
writer-to-module/project mapping can be very interesting. In such an
environment you are not perceived as an add-on, but an integral part
of the development team. You get to see how technical concepts are
born, and develop into a product. Due to the nature of information
exchange, conversations are freer, and communication is freer and more
frequent.
It, however, takes a certain kind of writer to fit in and make sense
in such an environment. Certainly not the kind of gig for the
faint-hearted or process-centric.
-edwin
Never hit a man
with glasses;
Hit him
with a baseball bat.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Now Shipping -- WebWorks ePublisher Pro for Word! Easily create online
Help. And online anything else. Redesigned interface with a new
project-based workflow. Try it today! http://www.webworks.com/techwr-l
Doc-To-Help 2005 now has RoboHelp Converter and HTML Source: Author
content and configure Help in MS Word or any HTML editor. No
proprietary editor! *August release. http://www.componentone.com/TECHWRL/DocToHelp2005
---
You are currently subscribed to TECHWR-L as archive -at- infoinfocus -dot- com -dot-