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: Writing the User Docs first? From:Beth Agnew <beth -dot- agnew -at- senecac -dot- on -dot- ca> To:'Techwr-l' <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Tue, 04 Dec 2007 11:13:49 -0500
To me, that was always the best thing about XP (Agile) -- the emphasis
on user stories. Sounds like your dev team has simply decided that
you'll write them instead of doing it themselves and handing them over
to you. That's not a bad thing. Anything that brings TWs and Devs closer
has got to be good, right? I've done the same thing -- used use cases
(UML) and user stories (XP) to get an early complete draft of the
documentation as a framework for further work. As the product got
fleshed out, so did the docs. It was a very beneficial partnership. The
docs then function almost as well-written specifications, meaning many
user problems are identified and solved at the paper stage instead of
the code or QA stage. You're not barking mad -- you're working in an
environment that most TWs pray for. Enjoy!
--Beth
Gordon McLean wrote:
> Note: I work in a Dev team that uses the XP (Agile) development methodology.
>
> Given that, in XP, there is a focus on little to no documentation during the
> design/build of the software, I've been pondering how the Publications team
> can fill that gap, namely by writing as complete a draft as early as
> possible and getting buy-in from the Dev team that they'll use the user docs
> whilst developing the software.
>
> Sound odd? Yeah it might.
>
> We sit in on early design discussions and at that point we can start to
> capture the whys and whats, fleshing out the main concepts and viewing each
> story (the large chunk of work the Dev team work on) from the point of view
> of the user. Once those stories are futher broken down into smaller chunks
> of work, we too will have a better idea of what is involved and can update
> the documentation accordingly.
>
> It will mean working closely with development, but we do that already, and
> hopefully this will provide the (currently missing) big picture information
> and view.
>
> Am I barking mad? Anyone working in XP (or any other Agile environment) care
> to chip in? Are our processes broken?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include support for Windows Vista & 2007
Microsoft Office, team authoring, plus more. http://www.DocToHelp.com/TechwrlList
True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
