I agree wholeheartedly. That is not the issue. The issue goes back to the BA 
interpretation of (and translation of) the software requirements. If there is a 
high level of certainty on the client side about what the finished product 
should be, TWs should start early. If not, and it is essentially a fishing 
expedition with ambiguous outcome, TWs are only useful at the last. 
Unfortunately, the "agile" methodologies strongly sell the sense of control to 
executives, pushing the idea that they can develop on the fly, adding and 
removing "requirements" as the executives see fit. 
http://www.tekwrytrs.com/Specializing in the Design, Development, and 
Production of:Technical Documentation - Online Content - Enterprise Websites> 
From: lhs_emf at pacbell.net> To: tekwrytr at hotmail.com; bhechter at 
objectives.ca; framers at lists.frameusers.com> Subject: RE: radical revamping 
of techpubs> Date: Sun, 28 Oct 2007 19:04:10 -0500> > I belong to several 
message - interest groups and I am used to hearing people give their opinions 
in a bombastic manner. So its no> big deal to see that happening here. But if 
this discussion is to have any real value it will be to share our perspectives 
with> others and learn something about points of view's entirely different than 
our own, which requires some tolerance and mutual respect.> > > My view and 
experience is that it definitely helps to get the TW involved early on, but 
it?s a waste of time for them to sit all the> way through each meeting, and for 
the entire duration of each meeting.> > Marketing requirements documents and 
engineering specification documents, if they are adequately written will help 
the TW formulate> the user documentation at a fairly early stage, but the bulk 
of the documentation effort comes towards the end of the development> cycle. 
And ideally the writer of the user guide if that is they type of documentation 
we are discussing now, should be a> knowledgeable user with some fresh insights 
into the learning curve the novice user will face, and some empathy for that 
new user.> > Ignoring the need for documentation, putting it off until the last 
moment is a formula for poor quality documentation.> > - In my humble opinion.> 
> Have a great work week!> > Leslie> > > -----Original Message-----> From: 
framers-bounces+lhs_emf=pacbell.net at lists.frameusers.com 
[mailto:framers-bounces+lhs_emf=pacbell.net at lists.frameusers.com] On> Behalf 
Of Technical Writer> Sent: Sunday, October 28, 2007 5:47 PM> To: bhechter at 
objectives.ca; framers at lists.frameusers.com> Subject: RE: radical revamping 
of techpubs> > > Well, a difference of opinion is what makes a horse race. 
Iterative software methods do not require iterative documentation methods;> in 
most cases, documentation before the last iteration is considered both wasteful 
and useless. While I have a great deal of respect> for Steve McConnell, 
proposing early draft user guides as a replacement for requirement specs is a 
bit off the road. > > If you develop software, and intend to use early draft 
user guides instead of requirements, you are going to be greeting the folks> at 
Wal-Mart rather than trying to pull back a contract or two from Bangalore. The 
statement is at odds with most developers' (and> most business analysts') 
understanding of "requirements." Putting an occasional "agile" into a sentence 
doesn't make the process any> more reasonable. > > I didn't invent the idea of 
ignoring documentation until the final product is ready (or almost ready) to 
ship. Far more intelligent,> competent, and capable people than me have decided 
that "involving TWs from the early stages of development" is only useful when 
the> end product is carved in stone before the first line of code is written. 
That, for better of worse, is rarely the case.> > Lastly, given that about a 
third of all software projects, agile or otherwise, fail so badly they are 
abandoned, if you ignore> documentation completely, you have a one in three 
chance of coming out ahead when the project flops because you have at least 
saved> the cost of documentation.> http://www.tekwrytrs.com/Specializing in the 
Design, Development, and Production of:Technical Documentation - Online Content 
-> Enterprise Websites> > > Date: Sun, 28 Oct 2007 12:21:17 -0700From: bhechter 
at yahoo.comSubject: re: radical revamping of techpubsTo: tekwrytr at 
hotmail.comCC:> framers at lists.frameusers.comSorry, but I find the thread 
both:a) Off-topicb) Misleading. Iterative sofware methods require iterative> 
documentation methods, but by no means do they eliminate the parallel need for 
early draft user manuals. In fact, Steve McConnell> (Code Complete) proposes 
early draft user guides as an agile replacement for requirements specs.Ben> 
Because the application itself> is built in an iterative process, rather than > 
being carved in stone, reacting to feedback from the client, documentation > 
before> the last minute is pointless. The reason should be obvious; the > 
application being documented in the early stages bears little> resemblance > to 
the application delivered. Ben Hechter Vancouver BC bhechter at yahoo.com> 
_________________________________________________________________> Windows Live 
Hotmail and Microsoft Office Outlook ? together at last.  Get it now.> 
http://office.microsoft.com/en-us/outlook/HA102225181033.aspx?pid=CL100626971033_______________________________________________>
 > > You are currently subscribed to Framers as lhs_emf at pacbell.net.> > Send 
list messages to framers at lists.frameusers.com.> > To unsubscribe send a 
blank email to > framers-unsubscribe at lists.frameusers.com> or visit 
http://lists.frameusers.com/mailman/options/framers/lhs_emf%40pacbell.net> > 
Send administrative questions to listadmin at frameusers.com. Visit> 
http://www.frameusers.com/ for more resources and info.> 
_________________________________________________________________
Boo!?Scare away worms, viruses and so much more! Try Windows Live OneCare!
http://onecare.live.com/standard/en-us/purchase/trial.aspx?s_cid=wl_hotmailnews

Reply via email to