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

RE: [XP] XP Scaling

Expand Messages
  • Bob Folline
    I think the key hear is to split this into smaller projects along functionality stories. If the entire team is exposed to the entire functionality they will
    Message 1 of 10 , Jan 17, 2001
    • 0 Attachment
      I think the key hear is to split this into smaller projects along
      functionality stories. If the entire team is exposed to the entire
      functionality they will spend most of the time designing for the big
      picture and little of the time doing the actual coding.

      Splitting along functional stories allow different teams to keep
      a smaller focus and keep the work output high. Then you have a team
      who only does the coordination tasks and assures the big picture is taken
      into account only by a small team that does not sweat the details.

      This tear approach allow everyone to keep a smaller focus and keep
      productivity high.

      Bob Folline

      -----Original Message-----
      From: acockburn@... [mailto:acockburn@...]
      Sent: Thursday, January 11, 2001 6:31 PM
      To: extremeprogramming@egroups.com
      Subject: [XP] XP Scaling


      Chris Bruce:
      <<> The question I am wondering is "WHY" can't it scale? XP has some great
      > benefits that would be great to offer in larger scale projects. I am
      really
      > curious on what aspects can't scale and try to figure out if there is any
      > way to adapt them to scale.
      >
      > The project I am working on is implementing XP in a large scale project
      with
      > 80 developers. So I am starting to gather my own opinions of problems AND
      > solutions, but it would be nice to hear from others that have tried this
      > first hand.>>

      The thing is, Chris, I can't even begin to think of how to do anything with
      80 people and call it XP.
      "Put everyone in one room so that they overhear each others' conversations
      and through rotation come to know all of the system"... oops... to me,
      seating the people is step 1, and I can't do step 1 so I can't get to step
      2.

      What I can imagine you doing is 1-month deliveries, frequent integration,
      rotating pair programming, complete and automated unit regression tests,
      several customers on staff, DTSTTWPW.
      Well, I don't actually know if I believe you can do 1-month deliveries
      with 80 people, and am willing to be sceptical you can do the unit testing,
      and I'm unlikely to easily believe that the customers are passing along
      their
      information in a tidy way, that the programmers are implementing simple
      designs, and I am really sceptical about the aggressive refactoring part.

      So in my case, it's so severe that I can't even begin to think of how it
      could operate for that many people.... Show me, and then I'll happily
      believe.


      Alistair Cockburn
      Humans and Technology

      7691 Dell Rd.
      Salt Lake City, UT 84121
      Work Phone: 801.947.9275
      Fax: 775.416.6457
      http://members.aol.com/acockburn
      write to: alistair.cockburn@...



      [Non-text portions of this message have been removed]


      To Post a message, send it to: extremeprogramming@...

      To Unsubscribe, send a blank message to:
      extremeprogramming-unsubscribe@...

      Ad-free courtesy of objectmentor.com


      [Non-text portions of this message have been removed]
    Your message has been successfully submitted and would be delivered to recipients shortly.