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

44775Re: [scrumdevelopment] Best approach to "Agile Documentation"

Expand Messages
  • Jeff Anderson
    Feb 1, 2010
    • 0 Attachment
      Saying to write "just what the product owner and developers wants"
      seems a little bit like hand waiving.

      I'm rarely in a situation where we have just one product owner, and
      even when we do the product owner needs advice on what to document.

      If you are in a sensitive field, you or your product owner may have
      risk officers or security experts to consult, if you have a separate
      support group someone better consult them on what they need to keep
      this running.Its not just about developers and product owners. Sure
      don't document to follow a process, but that doesn't mean you can't
      offer some advice on some docs that help in certain situations.

      I tend to use (in the following order)
      -tests (automated and manual)
      -support and operation guides
      -func hirerarchy (like epics and stories)
      -platform and arch outline
      -domain driven design style models (ie concise and compact)

      I like scott amblers agile documentation, a colleague of mine gives an
      overview at...

      http://agileconsulting.blogspot.com/2009/12/agile-documentation.html

      Regards
      Jeff Anderson

      On 1/26/10, James Schiel <schiel@...> wrote:
      > Ron, I was thinking about a different way to say this, but I think you've
      > really captured it.
      >
      > However, let's provide a few examples that Joshua might need to be aware
      > of----
      >
      > 1) What documentation does the Product Owner need? The list MIGHT include:
      > - documents and records required to pass an audit (code review records,
      > approval records, etc.)
      > - documents required to train and/or inform (user documentation, training
      > materials, release guide, etc.)
      >
      > 2) What documentation do the Developers need? The list MIGHT include:
      > - design specifications
      > - functional descriptions
      > - test plans
      > - test documentation
      > - database schemas
      >
      > It's also important to note that a lot of documentation (particularly
      > documentation driven by "templates") is only partially necessary. Find out
      > what is actually needed by the PO and the developers before you assume. If
      > you're not sure, don't write it -- better to find out you needed it and go
      > back to write it than to just keep writing something over and over because
      > you always have and you're not sure if you use it.
      >
      > As I said, I think you've captured the real essence of the question, Ron. I
      > hope you don't mind my refactoring it a little.
      >
      > Jim
      >
      >
      > On Jan 26, 2010, at 7:46 PM, Ron Jeffries wrote:
      >
      >> Hello, Joshua. On Tuesday, January 26, 2010, at 1:33:35 PM, you
      >> wrote:
      >>
      >> > I'm curious what you've found to be the best approach to Agile
      >> > Documentation.
      >>
      >> Write what the Product Owner wants, what the developers need, and
      >> nothing else.
      >>
      >> Ron Jeffries
      >> www.XProgramming.com
      >> www.xprogramming.com/blog
      >> Master your instrument, master the music,
      >> and then forget all that *!xy!@ and just play. -- Charlie Parker
      >>
      >>
      >
      >

      --
      Sent from my mobile device

      Jeff Anderson

      http://agileconsulting.blogspot.com/
    • Show all 51 messages in this topic