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

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

Expand Messages
  • Ken Boucher
    ... What I tried to say is that in many organizations, the customer does BRUF in order to obtain funding. I belive in order to make the decision to pursue
    Message 1 of 145 , Sep 1, 2004
    • 0 Attachment
      > > How do either of these statements apply to the
      > > "deciding whether to pursue" phase? To the best of my
      > > knowledge, a group can't release running software
      > > early (never mind keep releasing software) until they
      > > have already decided to pay for developers.
      >
      > I think you suggested that the customer needs to gather
      > more requirements than what would be necessary just to
      > get the developers started, in order to obtain funding
      > for the complete project.

      What I tried to say is that in many organizations, the customer does
      BRUF in order to obtain funding. I belive in order to make the
      decision to pursue coding accurately the customer needs to know more
      than what the developers need to know because they need to make some
      estimates on scope and ROI.

      I also tried to say that even if a customer does too much BRUF, I
      don't see where that prevents XP from making the project a success.
      Others seem to disagree and don't think XP teams should work on such
      projects.

      > This additional requirements gathering has a cost. What
      > if the money were spent on paying for the first
      > iteration instead? That may be enough to get funding
      > for the second iteration, and so on. It may never be
      > necessary to obtain funding for the complete project.

      If the money is spent on the first iteration then at the end of the
      first iteration, what do you expect the customer to know, other than
      the contents of the first and second iteration? Do you expect them to
      know how many iterations there will be until the project actually has
      a ROI? The developers don't need to know that. The gold owner usually
      does.

      Earlier this week, a statement was made that XP teams prefer starting
      over rather than working with legacy code. I don't know if that
      statement was true, but I know I didn't see anyone challege it. If it
      is true, than any project involving replacing a legacy app isn't
      likely to have a ROI until that legacy app can be sunset. At what
      point does the customer know when that app can be sunset if they
      don't know more than the next iteration ahead?

      > As a customer, I therefore feel my money would be
      > better spent on paying for two or three iterations
      > rather than on gathering requirements before issuing a
      > bid.

      And that is a choice you get to make when YOU are the gold owner.

      > As a supplier, I would not risk bidding fixed-price
      > fixed-scope, because I have never seen this work to
      > either parties best interests. I would offer an
      > incrementally funded, scope-controlled approach.

      I hear you saying you choose not to work on those projects. The
      question is, fo you think XP can succeed on those projects or do you
      think XP will fail to deliver a final product when applied to such
      projects.
    • Randy MacDonald
      Previous experience worked for me. ... From: John D. Mitchell To: Sent: Friday, September 10,
      Message 145 of 145 , Sep 9, 2004
      • 0 Attachment
        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.