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.
These are 175 individual, named software applications. They have been
developed over a number of years, using VB6, PowerBuilder, ASP,
Silverlight, and numerous other technologies. We have begun a
disciplined review of all of the applications to determine where
functional overlap occurs, or where functional need has ended, so that
we can reduce that number. At last count--from at least a year ago--we
have over 500 different configuration items (data sources, services,
shared dll's, etc.) associated with these 175 applications.
--Darrell
-----Original Message-----
From: techwr-l-bounces+dzuerche=tva -dot- gov -at- lists -dot- techwr-l -dot- com
[mailto:techwr-l-bounces+dzuerche=tva -dot- gov -at- lists -dot- techwr-l -dot- com] On Behalf
Of magk -at- mindspring -dot- com
Sent: Monday, April 12, 2010 10:34 AM
To: techwr-l -at- lists -dot- techwr-l -dot- com
Subject: Re: Agile Tech writing
How do you define an application in the reference to "175 applications?"
Are these software products, individual features and enhancements, or
bug fixes?
Just wondering.
Thanks,
Gina King
>Message: 5
>Date: Fri, 9 Apr 2010 10:24:14 -0400
>From: "Zuercher, Darrell" <dzuerche -at- tva -dot- gov>
>Subject: RE: Agile tech writing
>To: "Blount, Patricia A" <Patricia -dot- Blount -at- ca -dot- com>,
> <techwr-l -at- lists -dot- techwr-l -dot- com>
>Message-ID:
>
<C30CEAB331E621438DDCE4662F9C856F05118F4F -at- TVACOCXVS2 -dot- main -dot- tva -dot- gov>
>Content-Type: text/plain; charset="us-ascii"
>
>Patty,
>
>I am a lone writer on an agile (Scrum) development team. We have been
>agile for about two years. There are a few things that can help you
>succeed in this environment, based on my experience. Your mileage may
>vary.
>
>1. Make sure that your documentation is included in your Product
Backlog
>Item estimates. Your Product Owner may not even consider an item "done"
>unless it is also documented.
>
>2. Each of the other tasks you perform (UI review, error message text
>editing, instruction changes, etc.) are also included in the estimates,
>and are itemized in the Sprint's deliverables.
>
>3. Attend the daily Scrum meetings, or whatever status-reporting
>conversations the team has, so that your tasks are visible to the rest
>of the team. This includes any obstacles that are related to
team-member
>availability.
>
>We typically have several simultaneous projects (We currently create
and
>support over around 175 different applications.) underway, so I am also
>documenting multiple applications simultaneously. I have had the most
>success when I am a vocal member of an application's team, submitting
>suggestions to make application easier to use or more intuitive. I am
>quick to offer suggestions for UI element placement, menu design,
screen
>usage, etc. when the team is discussing implementation options. I have
>also acted as Scrum Master on several teams, including one which won a
>departmental award for best team last year (600-person department).
>
>Many view agile development as not requiring documentation. The truth
>is, the documentation is required but is much more dynamic. From
design,
>through requirements, to the end user, there is documentation. Smaller
>deliverables, less formal, but essential. I like the phrase, "barely
>sufficient documentation". Write just enough so that the audience can
>accomplish its work. As someone (I can't remember the source at the
>moment) once said, "Make it as simple as possible, but not simpler.
>
>Concerning your delivery schedule, one option might be to delay
delivery
>of the software by one Sprint, in order to complete the documentation.
>Feature 1 is developed in Sprint 1. Feature 2 is developed in Sprint 2,
>while Feature 1 is documented, and then released. Feature 3 is
developed
>in Sprint 3, while Feature 2 is documented, and then released. Just a
>thought.
>
>I hope this helps.
>
>--Darrell
>
Use Doc-To-Help's XML-based editor, Microsoft Word, or HTML and
produce desktop, Web, or print deliverables. Just write (or import)
and Doc-To-Help does the rest. Free trial: http://www.doctohelp.com
Explore CAREER options and paths related to Technical Writing,
learn to create SOFTWARE REQUIREMENTS documents, and
get tips on FUNCTIONAL SPECIFICATION best practices. Free at: http://www.ModernAnalyst.com
---
You are currently subscribed to TECHWR-L as dzuerche -at- tva -dot- gov -dot-
Use Doc-To-Help's XML-based editor, Microsoft Word, or HTML and
produce desktop, Web, or print deliverables. Just write (or import)
and Doc-To-Help does the rest. Free trial: http://www.doctohelp.com
Explore CAREER options and paths related to Technical Writing,
learn to create SOFTWARE REQUIREMENTS documents, and
get tips on FUNCTIONAL SPECIFICATION best practices. Free at: http://www.ModernAnalyst.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
