Re: XP Requirement Analysis?

From: Cy Coe (cycoe_at_hotmail.com)
Date: 10/04/04 

Date: 3 Oct 2004 16:31:57 -0700

Rich MacDonald <rich@@clevercaboose.com> wrote in message news:<Xns95769764514D4richclevercaboosecom@24.94.170.86>...
> cycoe@hotmail.com (Cy Coe) wrote in
> news:1bd6d89a.0409301445.706e0247@posting.google.com:
>
> Was that (1), (2) or (3) ?

In truth, none of the above. I argue a variation of (3), that certain
aspects of XP, particularly those involving requirements analysis, are
worse that practises found in other methodologies.

XP, as described in the books, does not treat requirements engineering
as a significant undertaking, and seems to assume that as long as you
have someone in the room who knows about the business and who is
willing to ask for small-grained features and author acceptance tests,
that everything will work out in terms of the solution meeting the
organization's needs. In contrast with this treatment of requirements
analysis (the what and why), XP has a great deal to say about writing
code and small-scale design issues (the how).

Normally, one would take this as a hint that it's up to the Customer
to decide how he's going to come up with the requirements that will be
reflected in the XP workflow as user stories. But not so fast! Any
kind of upfront effort aimed at researching/clarifying business
requirements, even if it doesn't involve the programmers in any way,
is apparently incompatible with XP. XP appears to not only recommend
that trial-and-error coding be the main requirements gathering
technique, but *insists* upon it.

I've spent a good portion of my career helping the organizations I
work for reduce uncertainty and clarify their needs in terms of
software. I've seen enough false starts, blind alleys and poorly
thought-out concepts to convince me that baby-stepping incrementalism
will not yield a good solution unless you do your homework before
starting down the road of implementation.

And no, I'm not talking about "waterfall", "big design up front", or
whatever other bogeymen XP'ers trot out to scare the townsfolk. I'm
prepared to accept that designing and coding can take place in a more
cyclical and concurrent manner than they have in traditional projects.
 But I think that requirements are different. The old waterfall "lock
'em in stone" approach has had its problems, but I think XP's
"do-it-as-you-go" approach errs in the opposite direction. When
developing business software, focusing on the small at the expense of
proper consideration of the big picture (and yes, implementing too
soon pushes you into that mindset) will cause you to miss
opportunities for simplifying the workflow and enhancing the value of
the solution.

You may ask "Well, isn't that the Customer's job?" To which I respond
"Yes, it is! That's why you should let him do it, with the help of
those people who are skilled in this sort of work."

Once you have implemented software out there, you're in maintenance
mode. Significant changes to the architecture may be possible (maybe
even easy) due to the code structuring and refactoring rules that XP
dictates, but a working system resists significant change in a way
that has nothing to do the cost of writing code. It's a
psychological/sociological barrier to change. Having something,
however suboptimal, makes it harder to justify asking for something
different. Like it or not, your best chance at ensuring that the
right thing is built comes before you start construction, even in
software.

Cy

Relevant Pages

  • Re: Configurable workflow
    ... You might be able to satisfy the stakeholders needs for a configurable ... run time and is targeted at business users. ... There are very few products that provide configurable workflow directly ... > implementation team since I believe BizTalk tastes too techical for them, ...
    (microsoft.public.biztalk.general)
  • Re: XML-schema best practice question
    ... workflow definitions, and/or executing a workflow engine can become a ... So BPMN is mere theory. ... I can use it to drive the business process. ... the various specifications as they evolve. ...
    (comp.lang.python)
  • Re: XML-schema best practice question
    ... workflow definitions, and/or executing a workflow engine can become a ... So BPMN is mere theory. ... I can use it to drive the business process. ... the various specifications as they evolve. ...
    (comp.lang.python)
  • Workflow Foundation - useless?
    ... Workflow Foundation. ... business process designer to application users. ... It looks as if they provided a graphical designer for writing ... Because very often business applications need to run 24x7, ...
    (microsoft.public.dotnet.general)