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

44755Re: [!! SPAM] Re: [scrumdevelopment] Re: Best approach to "Agile Documentation"

Expand Messages
  • Thomasjeffreyandersontwin@Gmail.com
    Feb 1, 2010
    • 0 Attachment
      Yes I agree, I usually capture the following on projects

      - operations and support > anything my ops and support team tell me they need
      -1-2 pager on the major functions, ie use case briefs, not detail
      - detailed, (and hopefully automated test case) at the business level using something like fitness ( typically in bdd style)
      - domain models, sometimes as CRC cards, sometimes in UML. I try to keep these in sync with the code, or in case of cots development, with the tests.
      - non functional expectations( volume, response time, security, etc)

      - platform choices, ie tools, libraries, version nums, etc...
      - user manual where appropriate
      - developer docs where teams are building code for other teams to use

      I try to use wikis wherever possible for my documents, that way the artifacts can be very focused, repitition is reduced, and a larger team can share the burden of documentation.

      Also many of these docs are optional (exept the tests) and depend in the scale and size of the project. I also try to keep it breif 1-2 pagers are good enough, and have a chance of staying up to date.

      On Feb 1, 2010, at 1:29 AM, Dan Rawsthorne <dan.rawsthorne@...> wrote:


      From an estimation side, I won't disagree. However, from a "doneness"
      perspective, I think there is information to be captured and moved forward.

      Dan Rawsthorne, PhD, CST
      Senior Coach, Danube Technologies
      dan@..., 425-269-8628

      Thomasjeffreyanders ontwin@Gmail. com wrote:
      > My experience has been that guestimation backed up by some mental
      > modeling is going to get you the same accuracy as any amount of
      > historical documentation.
      > If your team is delivering and estimating in short cycles they will
      > get into a rythm andget very good at it.
      > Once the team change and or significant tech changes then old
      > estimates don't help as much.
      > Problem with using past history to do really accurate estimates for
      > future work is typically much of the context is no longer relevant ,
      > you might as well go with your gut, it better yet go with a bunch of
      > peoples guts (planning poker anyone?)
      > Jeff Anderson
      > agileconsulting. blogspot. com <http://agileconsult ing.blogspot. com>
      > On Jan 31, 2010, at 11:06 PM, Roy Morien <roymorien@hotmail. com
      > <mailto:roymorien@hotmail. com>> wrote:
      >> Hi Jordi,
      >> What information do you extract from those task tracking post-it notes?
      >> Especially what information do you extract that will assist you in
      >> estimating the current project, and the User Stories, and the tasks
      >> once they are moved into the Sprint Backlog?
      >> Regards,
      >> Roy Morien
      >> ------------ --------- --------- --------- --------- --------- -
      >> To: scrumdevelopment@ yahoogroups. com
      >> From: jordi.salvat. i.alabart@gmail.com <http://gmail. com>
      >> Date: Thu, 28 Jan 2010 17:12:22 +0000
      >> Subject: [scrumdevelopment] Re: Best approach to "Agile Documentation"
      >> Hi Ron.
      >> We do that pretty often by retrieving the task tracking post-its
      >> where we logged hours spent. It's free, since we want to log hours
      >> anyway for other reasons. And it saves time and mental energy during
      >> planning. Mental energy at planning time is a very scarce resource
      >> for us, as our planning sessions are really exhausting.
      >> Of course it can only be used successfully for very similar product
      >> items, but those come up all the time in most software products
      >> (certainly in our's).
      >> --
      >> Salut,
      >> Jordi.
      >> --- In scrumdevelopment@ yahoogroups. com
      >> <mailto:scrumdevelopment@ yahoogroups. com>, Ron Jeffries
      >> <ronjeffries@ ...> wrote:
      >> >
      >> > Hello, Roy. On Wednesday, January 27, 2010, at 10:58:16 PM, you
      >> > wrote:
      >> >
      >> > > Another interesting qestion, for me at least, is about the use of
      >> > > project histories (written documentation perhaps) for use to guide
      >> > > future estimating. A lot of people talk about recording their
      >> > > project experience so they can estimate better in the future. S
      >> > > what about this 'documentation' ? What is it? Is it useful? How
      >> > > best is it recorded and organised? etc.
      >> >
      >> > In my long history I have /never/ seen this done. My guess on why is
      >> > that it's clear to most people that it isn't useful.
      >> >
      >> > Ron Jeffries
      >> > www.XProgramming. com
      >> > www.xprogramming. com/blog
      >> > My advice is to do it by the book, get good at the practices, then
      >> do as
      >> > you will. Many people want to skip to step three. How do they know?
      >> >
      >> ------------ --------- --------- --------- --------- --------- -
      >> Sell your old one fast! Time for a new car?
      >> <http://clk.atdmt. com/NMN/go/ 157637060/ direct/01/>

    • Show all 51 messages in this topic