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.
OK, I really don't expect anyone on this list to agree with the
aforementioned "research" telling us that comprehensive requirements
and functional specs are overkill; afterall, that's what many of us
"do".
What would be more useful to me would be hearing from writers who have/
are currently working with an Agile methodology, again, in terms of
how this may be affecting your writing tasks/products, function on the
team, successes/failures, etc. Has the switch to agile changed how
you "do" documentation? Thanks.
Terilyn
On Feb 16, 2:09 pm, Peter Neilson <neil -dot- -dot- -dot- -at- windstream -dot- net> wrote:
> Lemme try to think through what might be going on here. We can divide
> software projects up into various binary categories:
>
> 1(a/b). Have (or do not have) a good insight on a product and a good team.
> 2(a/b). Perform (or do not perform) early documentation of plans and
> designs.
> 3(a/b). Produce (or do not produce) a successful product.
>
> 1b rarely leads to 3a, I'm sure, regardless of what is done with 2.
> Including a large number of badly conceived projects in a study will
> indeed show that documentation efforts do not help. "You can't wash
> sh*t," as a fellow TW once said.
>
> So a proper study on the effectiveness of early documentation should
> focus mostly on projects that were started by experienced and/or
> cohesive teams working towards a reasonably well understood goal. But
> how would one select those, the "1a" subgroup, from the entire 1a+1b?
> How could one tell which is which?
>
> The only way that I could imagine is by reading the planning and process
> documents. Those are hard to come by for successful projects, because
> they are generally proprietary. For failed projects they (if any) are
> either going to be pieces of crap that are part of the failure, or
> after-the-fact memoranda that show why someone else was to blame for the
> failure. Once in a while they might be gold that was set aside in a vain
> attempt to use the precious dross.
>
> What have I come up with? Am I right, or am I instead all out of focus,
> or involved in petitio principii, or perhaps merely echoing someone
> else's much more erudite and well constructed research?
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include single source authoring, team authoring,
Web-based technology, and PDF output. http://www.DocToHelp.com/TechwrlList
Now shipping: Help & Manual 4 with RoboHelp(r) import! New editor,
full Unicode support. Create help files, web-based help and PDF in up
to 106 languages with Help & Manual: http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- infoinfocus -dot- com -dot-