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.
Lisa Wright wrote:
> [...]
> This is the whole idea behind XP programming--you design as you go.
> You're flexible. You don't invest a lot in developing things that are
> miles down the road. You deal with the here and now. You plan for short
> iterations of a product based on known requirements. Actually, you're
> not even supposed to deal with ALL the known requirements, though that
> one's a struggle. "Just ignore the 2-ton elephant in the corner. He
> doesn't get involved until *much* later!"
>
> The key part is that you are highly flexible. Hackos is right: people
> often don't know what they want until they begin to see it take shape.
> So instead of running them through the "you didn't stick to our process"
> mill, you have a process where change is a natural, expected,
> encouraged, nay, critical part of the process that enables you to get
> the best product with very high customer satisfaction.
>
> I apply this approach in my own writing, though it's hardly formalized.
> It lets me respond quickly to new features and functions, to the
> tweaking and refining that the developers always do, to last minute
> customer requests. I very much recommend reading up on XP just to get a
> sense of the dynamic involved. There are several books, including
> "Extreme Programming Explained." Despite it's very flexible nature, it
> is a structured process full of planning and checkpoints, so everybody
> can be happy.
So, how does a technical writer integrate with an XP programming
team?
While I was thinking about this, I found this essay on Agile
Documentation:
There was a discussion of agile documentation on the
extremeprogramming Yahoo!Group a few days ago, but it
seemed to focus on the documentation of code and not
on user documentation.
--
e=sc^3 (shiva -at- io -dot- com) Earl Cooley III
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Collect Royalties, Not Rejection Letters! Tell us your rejection story when you
submit your manuscript to iUniverse Nov. 6 -Dec. 15 and get five free copies of
your book. What are you waiting for? http://www.iuniverse.com/media/techwr
---
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.