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

RE: [XP] Using XP in outsourced software development

Expand Messages
  • Amir Kolsky
    I always explain that the specifications are really there for the customer s benefit. We as developers need something more - we need customer communication.
    Message 1 of 4 , Aug 2, 2005
      I always explain that the specifications are really there for the customer's
      benefit. We as developers need something more - we need customer

      Almost invariably specifications mix together different perspectives of the
      product to be delivered:
      User oriented, technical specifications, emotions, UI wishes. Developers
      don't need all that information - it is not coherent.

      Worse, technical specs are often specified (as they should be) in the
      vernacular of those writing them. This immediately means that they will
      likely to be understood correcly by those who wrote them or their associates
      - not by someone of needs to implement them.

      So, I'm all for specs, as you don't show them to the developers. Devleopers
      need human interaction.

      Amir Kolsky
      XP& Software

      >-----Original Message-----
      >From: extremeprogramming@yahoogroups.com
      >[mailto:extremeprogramming@yahoogroups.com] On Behalf Of
      >William E Caputo
      >Sent: Tuesday, August 02, 2005 6:44 AM
      >To: extremeprogramming@yahoogroups.com
      >Subject: Re: [XP] Using XP in outsourced software development
      >>How can XP be used when detailed specifications (in terms of UI and
      >>are provided by the client? Where does stories come in?
      >XP can be used in this situation much the same as any other --
      >by following an iterative approach to refine what you know
      >from what you don't know.
      >When there are detailed specifications around, I like to use
      >them as a starting point for finding stories. Generally, I
      >find that they help frame discussions with the customer --
      >sometimes by providing detail, sometimes by showing where its
      >missing. Unfortunately, since they are often written without
      >involving the people who will actually build the software, the
      >detail is often overdone in some areas, and totally underdone
      >in others (yes, I believe specifications are often wasteful
      >and inefficient, but then I prefer XP release planning, so I'm biased).
      >The important thing is that specfications are not a substitute
      >for stories
      >-- or the other way round. Stories are used to structure our
      >communication and expectations around the requirements in a
      >way that is suitable for feeding iterations and building a
      >shared vision of the results, while specifciations are
      >intended to capture one's vision for transmission over time
      >and/or space (i.e. stories are a two-way communication tool,
      >while specification is a one-way tool).
      >>How will the schedule be estimated?
      >This question can easily lead to a misleading discussion. My
      >feeling is that the amount of specficiation shouldn't affect
      >estimation. As we still need a way to compare our estimates to
      >actual work performed and adjust our schedule/scope each
      >iteration, I expect that the team will still break the work
      >(however its described) into stories that are: Testable,
      >Estimatable, Small enough to fit in an iteration, and
      >understandable from the perspective of the customer --
      >regardless of what form that information is in to begin with.
      >The existence of a specficiation doesn't really change that.
      >Now, if someone *else* estimates the work (which is often the
      >case when a spec is around) and has already decided on the
      >schedule, then there isn't much to be done -- regardless of
      >what methodology-recipe you would wantto follow (as one has
      >already been written for you).
      >William E. Caputo
      >ThoughtWorks, Inc.
      >To Post a message, send it to: extremeprogramming@...
      >To Unsubscribe, send a blank message to:
      >ad-free courtesy of objectmentor.com
      >Yahoo! Groups Links
    Your message has been successfully submitted and would be delivered to recipients shortly.