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.
> Also, if you listen to Scott Ambler at all, you'll notice that he
initially seems to
> be?shrugging off "documentation", then later on in his presentation, as he
is going
> through his slides - and the slides start showing how "documentation" is
still
> important, although perhaps less formal, -?he says, "there, SEE, look,
these graphs
> prove that we are still doing documentation...
You need to be aware of the distinction between end-user training and
documentation (including online help), on the one hand, and technical
documentation (including detailed specifications, mainly) on the other. It
is the latter that Agile practitioners, in general, see as a time-waster.
I've corresponded with Scott Ambler on this issue, and he has emphasized
that requirements for end-user training and documentation should be treated
as "user stories". He also emphasized that when he says "no more
documentation than absolutely necessary", it is the USER who specifies how
much is necessary, and it is extremely important that this requirement be
handled in a disciplined way.
Not all Agile-based development handbooks make the distinction sufficiently
clear, and it is unfortunate that there was no "User Experience" advocate on
the original Agile team.
On the plus side, I work in an Agile development environment, and I have
found that having the user training and documentation "stories" up on the
board for the whole development team to see every day helps get these tasks
the priority and "respect" among code developers they seldom had in the bad
old days of "waterfall" project mismanagement.
ComponentOne Doc-To-Help 2009 is your all-in-one authoring and publishing
solution. Author in Doc-To-Help's XML-based editor, Microsoft Word or
HTML and publish to the Web, Help systems or printed manuals. http://www.doctohelp.com
Help & Manual 5: The complete help authoring tool for individual
authors and teams. Professional power, intuitive interface. Write
once, publish to 8 formats. Multi-user authoring and version control! http://www.helpandmanual.com/
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
