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

Re: [XP] Re: Distributed XP

Expand Messages
  • Ron Jeffries
    ... Figures would be good. But the small constant larger than one isn t necessarily 1.03, it could be close to two. I would be surprised to see the /real/ cost
    Message 1 of 82 , Apr 2, 2006
      On Sunday, April 2, 2006, at 5:58:34 AM, Philip Doherty wrote:

      >> cost of projects is therefore well approximated by the sum of the
      >> salaries of the people on the project, times the time involved,
      >> times a small constant larger than one.

      > That sounds small to me, I would like to have costs that small, it
      > must depend on the type of work. I wonder if I could find some
      > figures for this.

      Figures would be good. But the small constant larger than one isn't
      necessarily 1.03, it could be close to two. I would be surprised to
      see the /real/ cost of a project more than double the cost of the
      programmers, but could imagine accounting tricks that would make it
      seem that way.

      My main point is that I expect the cost of a project to be roughly
      proportional to the number of people on it.

      >>Well, the fact of a project being fixed price has no influence on
      >> how long it actually takes, or how much it costs us to do the work.

      > Fixed price can lead to projects being cancelled through lack of
      > funds, if companies want to stay in business they would cancel the
      > project long before they have emptied their own pockets. I realise
      > XP is trying to solve this problem but its a reality so theres no
      > point forgetting about it.

      I don't understand this statement regarding fixed price. I think
      that people undertake fixed price projects precisely because they
      want to limit their exposure, and that in general fixed-price
      projects are not cancelled, because they won't empty pockets.

      I'm guessing -- just guessing -- that you might have meant "variable

      However, my point is that the fee for a project doesn't change how
      long it /actually takes/ to do it. Whatever the project's actual
      scope is, the time to program that much stuff is not a function of
      how we're being paid.

      >>Since in a fixed-price contract the customer usually has fixed content in mind
      >> as well, exploring this possibility could be productive.

      > In my experience fixed price does not mean fixed content, the
      > customer has an idea and they want a price so they know what they
      > are paying, normally they havent thought their idea through fully
      > leading to changes.

      I would think that would be a particularly rough way of doing
      business, accepting a fixed fee for an unknown amount of work. Most
      of the fixed-price contracts I see try to nail down requirements
      pretty tightly, and include additional fees for changes. Is that not
      the case in your situation?

      >> That's interesting. I was assuming that you chose to communicate
      >> like this, not that you had to.

      > You're right, I chose to communicate on the same level as I don't
      > like people implying that I don't understand i.e. I'm stupid,
      > strange that isn't it.

      It was evident that we didn't understand each other. I don't
      remember saying that, but even if I had, it wouldn't imply that
      anyone was stupid.

      Not understanding someone or something is not evidence of stupidity.
      Failure to learn is the only evidence of stupidity.

      Remember again that Kelly Easterley quote in my sig list:

      If another does not intend offense, it is wrong for me to seek it;
      if another does indeed intend offense, it is foolish for me to permit it.

      I think that we come here in order to explore and expand our own
      ideas in the light of other people's ideas. There's no shame in not
      understanding what someone else is saying, and there's often
      learning or enlightenment in digging into whatever the hell they are
      getting at. Not because THEY will enlighten us, but because our own
      thoughts will do so.

      > Thanks for this response though, I think others will have gained
      > more from reading your thoughts in your last mail than your
      > previous ones.

      I'm glad you found it useful. I'm sorry it took so long to find
      something that worked for you.

      Ron Jeffries
      Agility might be said to be about encountering
      all the problems so early and so often that the
      effort to fix them is less than the pain of enduring them.
    • Jason Nocks
      ... ... ... The book, Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency strikes me as oddly relevant, particularly the
      Message 82 of 82 , Apr 7, 2006
        On Tuesday 04 April 2006 6:05 am, Keith Braithwaite wrote:
        > --- In extremeprogramming@yahoogroups.com, "Keith Ray" <keith.ray@...>
        > wrote:

        > Lets be careful with these numbers. I find the paper a bit incoherent,
        > seems to jump around a lot between the general, the specfic, personal
        > anecdote and focused experience reoprt, but section 6 seems to be the
        > meat.
        > It states that an (unspecified, no citation) colocated SCRUM team did
        > 959 Function Points in 54 person months, or 17.8 FP/person-month.
        > Whereas the distributed team described in the paper did (via a
        > slightly fishy reverse lookup) 12673 FPs in 827 person months, or 15.3
        > FP/person-month. A 16% difference. How bad is that? Depends on your
        > prefered figure of merit.
        > Interestingly, the paper compares these figures against an industry
        > average FP/person-month for projects _of that size_, whereby the
        > colocated SCRUM team is 42% more productive that the industry average
        > for projects of 1000FPs or so. But the distributed team is around 400%
        > more productive than the industry average for projects in the 10,000's
        > of FPs.
        > Assuming that the colocated team could maintain their 17.8 FP/pm for
        > the whole duration, and all other things being equal, the 4.5 person
        > [sic] co-lo team would have taken slightly less than 160 months to
        > complete the 12000+ FPs. The distributed team took 14.5 months.

        > Something to think about.

        The book, "Slack: Getting Past Burnout, Busywork, and the Myth of Total
        Efficiency" strikes me as oddly relevant, particularly the "Myth of Total
        Efficiency" part. Just my $.02.

        > Keith

        Jason Nocks
      Your message has been successfully submitted and would be delivered to recipients shortly.