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.
Subject:Re: I'm now blogging about Agile & TW From:Marguerite Krupp <mkrupp128 -at- yahoo -dot- com> To:TECHWR-L Writing <techwr-l -at- lists -dot- techwr-l -dot- com>, Robert Lauriston <robert -at- lauriston -dot- com> Date:Wed, 2 Dec 2009 10:20:49 -0800 (PST)
For the intellectually curious, or those just willing to keep an open mind about how we do our jobs (or, for that matter, who want to keep themselves marketable), consider reading the following resources:
www.agilemanifesto.org (The "project documentation" referred to means specs.)
Obviously, there are issues as well as advantages in applying a software development methodology to documentation. Agile methodologies (there are several) have been around for 10 years that I know of. They don't work well for all projects or for all people, but they're out there, and wise tech writers will at least familiarize themselves with the concepts. I'm not an advocate; I'm a learner. There are tech writing jobs out there using Agile methodologies. If you choose not to use the tools, that's OK, but know what you're accepting or rejecting.
If you think of the Agile doc modules as building blocks, not as a "disorganized mess," you'll see how you can use them to create documentation. Key Agile tenets, BTW,
include extensive planning, generation of user stories (who will use this stuff how), and a high degree of granularity of material. But go look for yourself and then decide whether it works for you. Julie has given us a good start.
Marguerite
--- On Wed, 12/2/09, Robert Lauriston <robert -at- lauriston -dot- com> wrote:
From: Robert Lauriston <robert -at- lauriston -dot- com>
Subject: Re: I'm now blogging about Agile & TW
To: "TECHWR-L Writing" <techwr-l -at- lists -dot- techwr-l -dot- com>
Date: Wednesday, December 2, 2009, 12:49 PM
My first question when dealing with that stuff was, how do you avoid
tying the tech writer up in hours of brain-numbing discussion of
coding details that are irrelevant to documentation?
My second was, you call that disorganized mess Agile?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Are you looking for one documentation tool that does it all? Author,
build, test, and publish your Help files with just one easy-to-use tool.
Try the latest Doc-To-Help 2009 v3 risk-free for 30-days at: http://www.doctohelp.com/
Help & Manual 5: The all-in-one help authoring tool. True single- sourcing --
generate 8 different formats and as many different versions as you need
from just one project. Fast and intuitive. http://www.helpandmanual.com/
---
You are currently subscribed to TECHWR-L as mkrupp128 -at- yahoo -dot- com -dot-
Are you looking for one documentation tool that does it all? Author,
build, test, and publish your Help files with just one easy-to-use tool.
Try the latest Doc-To-Help 2009 v3 risk-free for 30-days at: http://www.doctohelp.com/
Help & Manual 5: The all-in-one help authoring tool. True single- sourcing --
generate 8 different formats and as many different versions as you need
from just one project. Fast and intuitive. http://www.helpandmanual.com/
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
