Loading ...
Sorry, an error occurred while loading the content.

Re: [good] [XP] Re: Oracle & Ford in need of XP

Expand Messages
  • Doug Swartz
    ... I don t remember anyone on this thread saying XP doesn t address gathering requirements or steering the project ( end the project being one steering
    Message 1 of 145 , Sep 1, 2004
      Tuesday, August 31, 2004, 10:55:58 AM, Dominic Williams wrote:

      > I would just like to add that I consider the idea that
      > gathering requirements (and deciding whether to pursue)
      > is not addressed by XP's practices to be one of the
      > most common misconceptions.

      > XP says: don't just think about requirements - release
      > running software early and frequently to end users and
      > use the feedback to define further requirements.

      > XP says: keep doing that as long as what you gained
      > from the last release allows you to pay for the next
      > one.

      > So the practice that addresses those issues is frequent
      > releases. The value is feedback. It's all there.

      I don't remember anyone on this thread saying XP doesn't
      address gathering requirements or steering the project ("end
      the project" being one steering command).

      What many of us are talking about is "start the project".
      Classic XP has little to say about the project pre-work which
      is done in every organization I've worked in. Regardless of
      whether the development work is done in-house or contracted
      out; low-bidder wins, choose trusted supplier, or sole source;
      someone (a gold owner) has to decide it is worthwhile to start
      the project.

      Usually the gold owner requires some indication of three
      things: the approximate overall cost of the project,
      approximate time of value delivery, and a decent sense of what
      value will be derived (which is in large part determined by
      what features will be delivered). We know that none of these
      three factors will ever be exact. We also know that an XP
      development approach is one of the best ways to optimize in
      all three dimensions. But, it is appropriate for the decision
      maker to ask all three questions. In fact, I don't really want
      to work for a decision maker who doesn't ask all three

      One of the ways to characterize XP is "How little can we do
      and still create excellent software?". This thread is about
      "How little can we do and still make smart business decisions
      about which projects to do?". While the two questions are
      connected because the ability to steer the project using XP
      techniques can lower the cost of making a poor decision
      up-front, let's not confuse the two different questions.

      To me, an appropriate interpretation of BRUF is: "Understand
      the big requirements up front". It is not appropriate to
      "Spend a big effort to understand the requirements up front".


      Doug Swartz
    • Randy MacDonald
      Previous experience worked for me. ... From: John D. Mitchell To: Sent: Friday, September 10,
      Message 145 of 145 , Sep 9, 2004
        Previous experience worked for me.

        ----- Original Message -----
        From: "John D. Mitchell" <johnm-extreme@...>
        To: <extremeprogramming@yahoogroups.com>
        Sent: Friday, September 10, 2004 12:57 AM
        Subject: [XP] Re: The Value of XP when Requirements are Stable

        > Of course, sustainable very-high-speed typing and previous experience in
        > the various problem domains go a long way, too. :-( :-)
      Your message has been successfully submitted and would be delivered to recipients shortly.