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

RE: [XP] Re: Distributed XP

Expand Messages
  • Philip Doherty
    ... XP? Can you think of things about XP that might increase costs? Can you think of things that would decrease costs? Question 1: I stated that costs can rise
    Message 1 of 82 , Apr 1, 2006
      >What makes you think that your costs would increase through using
      XP? Can you think of things about XP that might increase costs? Can
      you think of things that would decrease costs?

      Question 1: I stated that costs can rise "for whatever reason" not because of XP. Licensing costs, electricity, rent.
      Question 2: Yes.

      >Are costs well-approximated by salary*time to complete project? What
      will be the impact of XP on salary? On time to complete project?

      Question 1: No.
      Question 2: I dont know the impact of XP on salary I suppose it would go up if everyone gains both the development and testing techniques needed. They would become of "higher economic value".
      Question 3: If the team doesnt grasp XP quickly enough the time to complete would be longer. In XP the project is complete whenever the customer decides. Time to complete could be longer or shorter, unless it is fixed price.

      >Not necessarily. One way to increase value is to charge more. Is it
      the only way?

      It may be your grammar but charging more does not increase value. To answer the question, No.

      >That would be true if they were priced at an /equal/ level.

      Yes I know, thats why I said it.

      > I imagine that any two price numbers are /comparable/. One way to win
      >a bid is to have the lowest price. What other ways are available,
      >with, and without XP?

      The answer to this would take far too long, besides we all know the answers to this.

      >To the extend that cost is an issue, what kind of cost? We were
      originally discussing distributed XP, probably with off-shoring in
      mind. The basic idea with offshoring is probably the lower cost per
      month of programmers. What is the impact of offshoring on the cost
      of doing a specific project? What is the impact on satisfying a
      specific customer?

      1. The impact of offshoring on the cost of a project depends on that project, it could be cheaper it could be more expensive.
      2. Again, it depends on the customer, it may be the only way to satisfy the customer.

      >Reducing the rate in dollars per day of programmers is one way to
      reduce cost. What other ways exist to reduce cost?

      I would suggest that you read some lean literature and try to apply it to software development.

      >I'm happy to have you get whatever ideas you get from what I write.

      Thanks Ron, I think thats the closest I'm going to get to an acknowlegement that I was correct.

      >Yes. It's much more fun to be subtly rude, isn't it?

      No, its frustrating that I have to communicate like this.

      And please don't respond to any of my statements with questions, if you can't respond with an opinion just say so.

      I have thought about aspects of XP for quite a while. Asking the type of questions you do as if its going to give me some insight I dont already have makes me think that you believe you understand it on a higher level than others in this group, what makes you think this? Maybe it has been previous experience.

      If you communicate with your XP customers this way I wonder if they are getting what they value or what you value.



      [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:
        <snip>

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

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

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