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

RE: [XP] Re: Distributed XP

Expand Messages
  • Philip Doherty
    ... 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
    Message 1 of 82 , Apr 2, 2006
      >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.

      >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.

      >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.

      >Correct that you don't like analogies? Of course you were correct
      about that. Correct that they don't work for you? You proved that,
      which I believe is what you set out to do, in my opinion at the
      expense of either of us gaining much value from the experience.

      Sigh....I wanted to make it clear to others who might be reading the thread that increasing the price for work becuase you are delivering greater value is not the only way XP can benefit your bottom line. Your analogy fitted well in this sense but it did not fit well with reducing costs because in your analogy they were fixed. Thats it. I didnt set out to prove that analogies dont work, I just wished you hadnt used that one.

      >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.

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

      Phil. Over and Out.

      [Non-text portions of this message have been removed]
    • 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.