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

Re: [XP] Good specs at the end of XP project

Expand Messages
  • sergei.andrz
    ... time ... end ... specifications ... I mean docs required if for example customer after a year pause decides to develop next version of specific
    Message 1 of 17 , Dec 23, 2006
      --- In extremeprogramming@yahoogroups.com, Ilja Preuss <it@...> wrote:
      >
      > sergei.andrz schrieb:
      > > We are using Extreme Programming (XP) very efficiently for a long
      time
      > > in numerous projects but there is one limitation we found. It is
      > > difficult to get detailed project technical specifications at the
      end
      > > of long XP project. Users Stories from customer are too general and
      > > become obsolete quickly due to many change requests. Would somebody
      > > share his/her experience in this area?
      >
      > I'm not sure what kind of "detailed project technical
      specifications"
      > you are asking for. What would you use them for if you had them?
      >
      > Curious, Ilja
      >

      I mean docs required if for example customer after a year pause
      decides to develop next version of specific application made with XP
      methodology or docs for customer which provides further technical
      support for system developed by external XP team.

      Sergei.
    • Rick Mugridge
      I can answer that from my own perspective; I can t tell what others would want unless I can ask them. If I was in the position of taking over a high-quality XP
      Message 2 of 17 , Dec 23, 2006
        I can answer that from my own perspective; I can't tell what others
        would want unless I can ask them.

        If I was in the position of taking over a high-quality XP project
        developed by others, I'd want storytests for the whole system, and unit
        tests for the details of the implementation. To get familiar with an
        area of the application, I'd probably run some experiments by writing my
        own storytests and/or unit tests to see that I understood what it does.
        It would also be handy to have a one or two page overview of the intent
        of the system and the role it plays in the bigger picture. And then some
        access to the original developers, to ask questions around the
        assumptions that had not been spelled out about it all. Teasing out
        those unstated assumptions is often critical.

        If everything was clear and to the point and well organised, I doubt
        that I'd want anything else.

        However, the only time I had this experience was when I added
        multiple-thread testing capability to JUnit for use on a project. I
        didn't need to ask questions, in that case.

        Cheers, Rick

        sergei.andrz wrote:
        >
        > We are using Extreme Programming (XP) very efficiently for a long time
        > in numerous projects but there is one limitation we found. It is
        > difficult to get detailed project technical specifications at the end
        > of long XP project. Users Stories from customer are too general and
        > become obsolete quickly due to many change requests. Would somebody
        > share his/her experience in this area?
        >
        > Thanks,
        > Sergei.
        >
        >


        [Non-text portions of this message have been removed]
      • George Dinwiddie
        ... If you had those detailed project technical specifications written at the beginning of the project, would you trust them when you return to development?
        Message 3 of 17 , Dec 25, 2006
          sergei.andrz wrote:
          > --- In extremeprogramming@yahoogroups.com, Ilja Preuss <it@...> wrote:
          >> sergei.andrz schrieb:
          >>> We are using Extreme Programming (XP) very efficiently for a long
          > time
          >>> in numerous projects but there is one limitation we found. It is
          >>> difficult to get detailed project technical specifications at the
          > end
          >>> of long XP project. Users Stories from customer are too general and
          >>> become obsolete quickly due to many change requests. Would somebody
          >>> share his/her experience in this area?
          >> I'm not sure what kind of "detailed project technical
          > specifications"
          >> you are asking for. What would you use them for if you had them?
          >>
          >> Curious, Ilja
          >>
          >
          > I mean docs required if for example customer after a year pause
          > decides to develop next version of specific application made with XP
          > methodology or docs for customer which provides further technical
          > support for system developed by external XP team.

          If you had those "detailed project technical specifications" written at
          the beginning of the project, would you trust them when you return to
          development?

          I've generally just trusted the code, when I've been in that situation.
          Having detailed test suites would have been a huge bonus.

          - George

          --
          ----------------------------------------------------------------------
          * George Dinwiddie * http://blog.gdinwiddie.com
          Software Development http://www.idiacomputing.com
          Consultant and Coach http://www.agilemaryland.org
          ----------------------------------------------------------------------
        • Scott Ambler
          ... Thought I d share a few ideas about agile approaches to documentation. 1. The documentation should have a clear audience. Who is going to use it? What
          Message 4 of 17 , Dec 26, 2006
            --- In extremeprogramming@yahoogroups.com, "sergei.andrz"
            <sergei.andrz@...> wrote:
            >
            > We are using Extreme Programming (XP) very efficiently for a long time
            > in numerous projects but there is one limitation we found. It is
            > difficult to get detailed project technical specifications at the end
            > of long XP project. Users Stories from customer are too general and
            > become obsolete quickly due to many change requests. Would somebody
            > share his/her experience in this area?
            >
            > Thanks,
            > Sergei.
            >

            Thought I'd share a few ideas about agile approaches to documentation.
            1. The documentation should have a clear audience. Who is going to use
            it? What are they going to use it for? What do they actually need?
            2. The stakeholders should be willing to pay for it. What's the total
            cost of ownership (TC0) for that documenation? Does the benefit exceed
            the cost?
            3. There should be a clear strategy to keep it up to date. Otherwise,
            why create it?
            4. Are there alternatives? Several people have suggested acceptance
            tests, developer tests, ... You want to single source information
            whenever possible.
            5. Get the audience for the docs actively involved with the development
            effort. That way they understand the system and need less docs.


            Some good reading (IMHO):
            1. Agile Documentaton.
            http://www.agilemodeling.com/essays/agileDocumentation.htm

            2. Single sourcing information.
            http://www.agilemodeling.com/essays/singleSourceInformation.htm

            3. Who are Stakeholders?
            http://www.agilemodeling.com/essays/activeStakeholderParticipation.htm#S
            takeholders

            - Scott
          Your message has been successfully submitted and would be delivered to recipients shortly.