Re: XP Requirement Analysis?
From: Cy Coe (cycoe_at_hotmail.com)
Date: 09/15/04
- Next message: Christopher Barber: "Re: Static vs. Dynamic typing"
- Previous message: JXStern: "Re: XP Requirement Analysis?"
- In reply to: Phlip: "Re: XP Requirement Analysis?"
- Next in thread: Justin Farley: "Re: XP Requirement Analysis?"
- Reply: Justin Farley: "Re: XP Requirement Analysis?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 14 Sep 2004 19:18:36 -0700
"Phlip" <phlip_cpp@yahoo.com> wrote in message news:<FXv1d.335$6s7.185@newssvr16.news.prodigy.com>...
> kurth wrote:
>
> > I often read that in XP you should not create a lot of documentation
>
> Citation?
Are you kidding?
> > - that
> > its all temporary stuff to help one understand the system.
>
> The best way to state the goal is this: Minimize the time between fully
> specifying a feature and deploying it. Small cycles can return business
> value by seeking requirements in order of business value.
Small cycles, at the XP level of granularity and in the absence of
real requirements analysis, are wasteful. The simplistic
widgetization of XP ignores the synergies/dependencies between
features. The much vaunted "prioritized list" of features is thus
arbitrary and has little real meaning, other than as a marketing
device.
Coding functionality to confirm that its required amounts to little
more than trial-and-error. It's fine to say you're doing "the most
important stuff", but in reality, there is a minimum set of
functionality required in any non-trivial application to make it
useful. You may claim with every feature that you have to throw away
or modify (doing your little refactoring dance every time), you're
learning something. But you're really just burning money.
Are you bragging that you can't think without a compiler?
>
> > First off I
> > applaud XP's desire to actually help the developers understand the domain
> > for the system they are building but I think this is the wrong way of
> > "helping them understand" for a couple of reasons: Many domains such as
> > accounting, manufacturing, supply chain, are well understood with a wealth
> > of existing documentation.
>
> Right. It's not the documentation that's the problem - it's the
> requirements, sitting on a shelf. That is exactly like inventory, sitting on
> a shelf, in manufacturing. It can only decay in value over time.
So does implemented functionality. You just bury the decay better.
That's the advantage procrastinators have. People don't get to see
what the results would have been had you been more proactive. They
just see you putting out the fires as they flare up, and assume you
know what you're doing.
A good priming scan of the problem domain and requirements will cause
more of the features you code to add value, without having to be
modified or replaced. You can bury requirements churn in refactoring
and call it "agility" all you want. You're building useless stuff to
(hopefully) get to the useful stuff, and trying to convince people
that this is better than trying to reason through the problem first.
> > Rather then trying to figure things out as you
> > go wouldn't it be best to train up developers on the business domain
> before
> > jumping into a (possibly incomplete poorly defined) scenario and rewriting
> > it over and over until you've captured all the requirements?
>
> That's why the OnsiteCustomer is _onsite_ - so developers can learn what
> they need (including RTFM), parallel with implementing it.
If the Onsite Customer lacks the skills to properly analyze the
problem domain (simply having been a worker in the domain doesn't
deliver those skills) then they, like you, will simply be muddling
their way through.
> > My
> > biggest complaint however is that how do you go to the customer and say
> this
> > wasn't a requirement of the original agreement, you will have to increase
> > the project budget, extend the timeline, etc.. if the requirements have
> not
> > thoroughly been analyzed, documented, and signed?
>
> (Reputedly) per Craig Larman's /Agile and Iterative Development: A Manager's
> Guide/, if you perform "big requirements up front", you invest in a huge
> risk of failure. That's why "more artifacts", in the "spend millions on
> requirements first" range, lead to so many spectacular software failures.
Going to the other extreme is likely to produce less showy, but
equally catastrophic failures. Just because something compiles and
runs and passes the tests doesn't mean its useful or valuable. The
best way to give a project a direction is to do enough upfront
analysis to know what it is you're building and what goals you're
trying to achieve. You don't make stuff like that up as you're going
along, or you deserve what you end up with.
Cy
- Next message: Christopher Barber: "Re: Static vs. Dynamic typing"
- Previous message: JXStern: "Re: XP Requirement Analysis?"
- In reply to: Phlip: "Re: XP Requirement Analysis?"
- Next in thread: Justin Farley: "Re: XP Requirement Analysis?"
- Reply: Justin Farley: "Re: XP Requirement Analysis?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
