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

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

Expand Messages
  • Ron Jeffries
    Hello, Roy. On Wednesday, January 27, 2010, at 10:58:16 PM, you ... In my long history I have /never/ seen this done. My guess on why is that it s clear to
    Message 1 of 51 , Jan 28, 2010
    • 0 Attachment
      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?
    • George Dinwiddie
      Hi, Jeff, ... I didn t see anybody suggest that. James talked about needs, now wants. ... Multiple product owners? Are they not acting as one? If they re
      Message 51 of 51 , Feb 1, 2010
      • 0 Attachment
        Hi, Jeff,

        Jeff Anderson wrote:
        > Saying to write "just what the product owner and developers wants"
        > seems a little bit like hand waiving.

        I didn't see anybody suggest that. James talked about needs, now wants.

        > 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.

        Multiple product owners? Are they not acting as one? If they're giving
        separate instructions to the development team, you've got another
        problem--one that documentation won't solve.

        Does the PO (do the POs) need advice on what the product is? If they
        don't know what documentation they need as part of the product, why were
        they made PO?

        > 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.

        Even in large orgs with many stakeholders, the job of the PO is to
        funnel that down into one stream of essential work. If documents are
        /necessary/ to satisfy certain stakeholders, then they're necessary.

        > 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)

        In what way do you use these? I understand tests and the guides (the
        latter which the PO should be specifying, if they're needed). When do
        you need the others? How much work are they to keep up-to-date as
        opposed to redeveloping them as needed?

        - George

        --
        ----------------------------------------------------------------------
        * George Dinwiddie * http://blog.gdinwiddie.com
        Software Development http://www.idiacomputing.com
        Consultant and Coach http://www.agilemaryland.org
        ----------------------------------------------------------------------
      Your message has been successfully submitted and would be delivered to recipients shortly.