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

Re: [XP] Re: Distributed XP

Expand Messages
  • Keith Ray
    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?
    Message 1 of 82 , Apr 1, 2006
    • 0 Attachment
      "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?"

      I've heard of companies in the SF Bay Area that found that out-sourced
      development didn't REALLY lower costs because there was a lot more
      testing and rework to do, and the testing at least had to be done
      locally to verify what the remote developers did.

      They also found that they had to do a LOT more work in specifying and
      documenting requirements to feed to the remote developers -- that cost
      money and time as well, tying up expensive executives and/or product
      managers / analysts.

      Local employees who could have done the work themselves instead had to
      double-check the work done remotely, taking up just about as much work
      time ... so no net reduction in costs.

      C. Keith Ray
    • 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
      • 0 Attachment
        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.