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

Re: [XP] Documentation

Expand Messages
  • Eric Rizzo
    ... [snip] ... Any references to help us locate this study? Eric -- Eric Nicholas Rizzo eric.rizzo@trcinc.com The Technical Resource Connection, Inc.
    Message 1 of 19 , Sep 1, 2000
    • 0 Attachment
      Jim Highsmith wrote:
      >
      [snip]
      > A recent study (I've talked to the person who did the study) indicates that
      > a typical requirements document is 15% complete and 7% correct, furthermore
      > "its not cost effective to make these numbers higher."

      Any references to help us locate this study?

      Eric
      --
      Eric Nicholas Rizzo
      eric.rizzo@...
      The Technical Resource Connection, Inc. Perot Systems
      http://www.trcinc.com
      ---------------------------------------------------------------
      "A man talking sense to himself is no more insane than
      a man talking nonsense not to himself...or just as insane."
      -Rosencrantz and Guildenstern Are Dead
    • Jim Highsmith
      Eric, Ron I don t think the study is available on the web. I need to check with the author before distributing his name widely. Jim
      Message 2 of 19 , Sep 1, 2000
      • 0 Attachment
        Eric, Ron

        I don't think the study is available on the web. I need to check with
        the author before distributing his name widely.

        Jim
      • Michael Larionov
        Hi, This whole discussion on documentation brings me to another question. From your experience is it helpful to keep up-to-date CRC cards as a simpler form of
        Message 3 of 19 , Sep 5, 2000
        • 0 Attachment
          Hi,

          This whole discussion on documentation brings me to another question.
          From your experience is it helpful to keep up-to-date CRC cards
          as a simpler form of documentation?

          Of course provided:
          1. They are really up-to-date
          2. The project is almost-XP ( for the full XP you obviously don't need
          documentation)

          Thanks!

          Michael.
        • Ron Jeffries
          ... Not IMO. CRC cards work because of the touching and moving and writing. Once the session is over, they re dead. The only time I keep them is when it has
          Message 4 of 19 , Sep 5, 2000
          • 0 Attachment
            At 10:28 AM 9/5/2000 -0400, Michael Larionov wrote:
            >This whole discussion on documentation brings me to another question.
            > >From your experience is it helpful to keep up-to-date CRC cards
            >as a simpler form of documentation?

            Not IMO. CRC cards work because of the touching and moving and writing.
            Once the session is over, they're dead.

            The only time I keep them is when it has been one of those Macho CRC
            sessions where you don't write on the cards. Then you can use them over and
            over.

            Ron Jeffries
            www.XProgramming.com
            www.objectmentor.com
          • yahoogroups@jhrothjr.com
            ... From: raveendraiah To: extremeprogramming@yahoogroups.com
            Message 5 of 19 , Oct 2, 2003
            • 0 Attachment
              ----- Original Message -----
              From: "raveendraiah" <RAVEENDRA.at.HOTMAIL.COM@...>
              To: "extremeprogramming@yahoogroups.com"
              <extremeprogramming.at.yahoogroups.com@...>
              Sent: Thursday, October 02, 2003 8:40 AM
              Subject: [XP] Documentation


              > Hi:
              >
              > I am posting this to understand whole documentation involved in XP:
              >
              > In effort to reduce documentation XP, does produce piece-by-piece
              > documentation. But not enough documentation like CMM (Analysis,
              > Design, Test, TDD, Unit testing). If you take some start-ups, they do
              > work on the documentation, and review it before even they start the
              > project from all the members of the firm.
              >
              > Does lack documentation will effect the future of the project, what
              > if the project is transferred to overseas (Romania, India, China) ,
              > and all the members of the project is moved to different project.
              >
              > Let's assume working "Mission Impossible Part3", in four different
              > phases with 4 different directors, who will do their part on their
              > own. How will we get best movie out of the directors who will work on
              > the part by looking at previous parts by looking at the movie
              > (reading the code) rather than documentation/story?
              >
              > My question is how much documentation is generated during the total
              > XP process?

              Since it is not in the best interests of programmers in the US to have
              their jobs shipped overseas, and consequently be put out of work,
              I should probably tell you to go do your own research.

              However, the answer is that XP strives to make the code,
              in conjunction with the programmer tests and the customer
              tests, self documenting in the following sense:

              It should be as easy, if not easier, for a competent programming
              team to pick up the program and be able to make changes
              by inspecting only the code, unit tests and customer tests as it
              would be for the same team to become comfortable with
              a typically less well designed and expressive program
              accompanied by the typically incomplete, out of date
              and sometimes incorrect ancilliary documentation that
              most people think is necessary.

              This is, of course, an ideal, and it is frequently necessary
              to have some amount of ancilliary documenation. However,
              that is not a matter of policy, and no such documentation
              is mandated.

              You are also poorly informed about CMM. It does not
              mandate any particular phase structure or documentation.
              What it does require is that you have a documented process, you
              follow that process as documented, and that the process
              address each of the required points for the certification
              level involved.

              John Roth




              >
              > Thanks
              >
              >
              >
              > To Post a message, send it to: extremeprogramming@...
              >
              > To Unsubscribe, send a blank message to:
              extremeprogramming-unsubscribe@...
              >
              > ad-free courtesy of objectmentor.com
              >
              > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
              >
              >
            • raveendraiah
              ... they do ... the ... what ... China) , ... work on ... total ... have ... Sorry, I was just making a point, what if project is moved from one place to
              Message 6 of 19 , Oct 2, 2003
              • 0 Attachment
                --- In extremeprogramming@yahoogroups.com, yahoogroups@j... wrote:
                >
                > ----- Original Message -----
                > From: "raveendraiah" <RAVEENDRA.at.HOTMAIL.COM@y...>
                > To: "extremeprogramming@yahoogroups.com"
                > <extremeprogramming.at.yahoogroups.com@y...>
                > Sent: Thursday, October 02, 2003 8:40 AM
                > Subject: [XP] Documentation
                >
                >
                > > Hi:
                > >
                > > I am posting this to understand whole documentation involved in
                XP:
                > >
                > > In effort to reduce documentation XP, does produce piece-by-piece
                > > documentation. But not enough documentation like CMM (Analysis,
                > > Design, Test, TDD, Unit testing). If you take some start-ups,
                they do
                > > work on the documentation, and review it before even they start
                the
                > > project from all the members of the firm.
                > >
                > > Does lack documentation will effect the future of the project,
                what
                > > if the project is transferred to overseas (Romania, India,
                China) ,
                > > and all the members of the project is moved to different project.
                > >
                > > Let's assume working "Mission Impossible Part3", in four different
                > > phases with 4 different directors, who will do their part on their
                > > own. How will we get best movie out of the directors who will
                work on
                > > the part by looking at previous parts by looking at the movie
                > > (reading the code) rather than documentation/story?
                > >
                > > My question is how much documentation is generated during the
                total
                > > XP process?
                >
                > Since it is not in the best interests of programmers in the US to
                have
                > their jobs shipped overseas, and consequently be put out of work,
                > I should probably tell you to go do your own research.

                Sorry, I was just making a point, what if project is moved from one
                place to other.

                > However, the answer is that XP strives to make the code,
                > in conjunction with the programmer tests and the customer
                > tests, self documenting in the following sense:

                >
                > It should be as easy, if not easier, for a competent programming
                > team to pick up the program and be able to make changes
                > by inspecting only the code, unit tests and customer tests as it
                > would be for the same team to become comfortable with
                > a typically less well designed and expressive program
                > accompanied by the typically incomplete, out of date
                > and sometimes incorrect ancilliary documentation that
                > most people think is necessary.


                >
                > This is, of course, an ideal, and it is frequently necessary
                > to have some amount of ancilliary documenation. However,
                > that is not a matter of policy, and no such documentation
                > is mandated.

                >
                > You are also poorly informed about CMM. It does not
                > mandate any particular phase structure or documentation.
                > What it does require is that you have a documented process, you
                > follow that process as documented, and that the process
                > address each of the required points for the certification
                > level involved.

                "You may ask how we later know what the design is, since the cards
                are gone. Our answer is that the design is represented in the
                code." Ron Jeffries,

                I do understand, we will have phased development, testing with
                shorter cycles with less costs/overheads involved.


                Thanks John for clearing mind in the documentation. Is it right
                approach to mix two or three models, while working on the project.

                x, y, z from XP & a, b,c from SEI CMM for certification and some
                other process for betterment of the project, without effecting the
                project/process. I am sure some of the firms have mixed couple process
                >
                > John Roth
                >
                >
                >
                >
                > >
                > > Thanks
                > >
                > >
                > >
                > > To Post a message, send it to: extremeprogramming@e...
                > >
                > > To Unsubscribe, send a blank message to:
                > extremeprogramming-unsubscribe@e...
                > >
                > > ad-free courtesy of objectmentor.com
                > >
                > > Your use of Yahoo! Groups is subject to
                http://docs.yahoo.com/info/terms/
                > >
                > >
              • yahoogroups@jhrothjr.com
                ... From: raveendraiah To: extremeprogramming@yahoogroups.com
                Message 7 of 19 , Oct 2, 2003
                • 0 Attachment
                  ----- Original Message -----
                  From: "raveendraiah" <RAVEENDRA.at.HOTMAIL.COM@...>
                  To: "extremeprogramming@yahoogroups.com"
                  <extremeprogramming.at.yahoogroups.com@...>
                  Sent: Thursday, October 02, 2003 10:20 AM
                  Subject: Re: [XP] Documentation


                  > --- In extremeprogramming@yahoogroups.com, yahoogroups@j... wrote:
                  > >
                  >
                  > "You may ask how we later know what the design is, since the cards
                  > are gone. Our answer is that the design is represented in the
                  > code." Ron Jeffries,
                  >
                  > I do understand, we will have phased development, testing with
                  > shorter cycles with less costs/overheads involved.
                  >
                  >
                  > Thanks John for clearing mind in the documentation. Is it right
                  > approach to mix two or three models, while working on the project.
                  >
                  > x, y, z from XP & a, b,c from SEI CMM for certification and some
                  > other process for betterment of the project, without effecting the
                  > project/process. I am sure some of the firms have mixed couple process

                  Let me reiterate. CMM does not mandate any particular
                  process, so it is not possible to "mix" a non-existant CMM
                  process with another.

                  All that the CMM and CMMi require is that you

                  1. Have a documented process.
                  2. Demonstrably follow the process as documented
                  3. That the process, as documented, addresses each of the points
                  at the appropriate CMM or CMMi level.

                  It's also not necessary to "mix" another process with
                  XP to meet CMM certification. It may be necessary
                  to agument a minimal XP with other practices to meet
                  some of the points, but I'd be very wary of taking
                  things from other processes and simply bolting them
                  onto the XP framework.

                  The core of XP is a Lean pull type development
                  process with minimal handoffs. (This is not, by the
                  way, described in any of the literature this way)
                  Most other methodologies are designed for a
                  push type of process, so individual practices
                  simply don't transfer without rethinking them
                  from the ground up.

                  John Roth

                  > >
                  > > John Roth
                  > >
                  > >
                  > >
                  > >
                  > > >
                  > > > Thanks
                  > > >
                  > > >
                  > > >
                  > > > To Post a message, send it to: extremeprogramming@e...
                  > > >
                  > > > To Unsubscribe, send a blank message to:
                  > > extremeprogramming-unsubscribe@e...
                  > > >
                  > > > ad-free courtesy of objectmentor.com
                  > > >
                  > > > Your use of Yahoo! Groups is subject to
                  > http://docs.yahoo.com/info/terms/
                  > > >
                  > > >
                  >
                  >
                  > To Post a message, send it to: extremeprogramming@...
                  >
                  > To Unsubscribe, send a blank message to:
                  extremeprogramming-unsubscribe@...
                  >
                  > ad-free courtesy of objectmentor.com
                  >
                  > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                  >
                  >
                • raveendraiah
                  ... process ... What I am thinking is , 1. RUP for planning (and also for project tracking) some documentation to start with. This is what PMs like most. 2. XP
                  Message 8 of 19 , Oct 2, 2003
                  • 0 Attachment
                    --- In extremeprogramming@yahoogroups.com, yahoogroups@j... wrote:
                    >
                    > ----- Original Message -----
                    > From: "raveendraiah" <RAVEENDRA.at.HOTMAIL.COM@y...>
                    > To: "extremeprogramming@yahoogroups.com"
                    > <extremeprogramming.at.yahoogroups.com@y...>
                    > Sent: Thursday, October 02, 2003 10:20 AM
                    > Subject: Re: [XP] Documentation
                    >
                    >
                    > > --- In extremeprogramming@yahoogroups.com, yahoogroups@j... wrote:
                    > > >
                    > >
                    > > "You may ask how we later know what the design is, since the cards
                    > > are gone. Our answer is that the design is represented in the
                    > > code." Ron Jeffries,
                    > >
                    > > I do understand, we will have phased development, testing with
                    > > shorter cycles with less costs/overheads involved.
                    > >
                    > >
                    > > Thanks John for clearing mind in the documentation. Is it right
                    > > approach to mix two or three models, while working on the project.
                    > >
                    > > x, y, z from XP & a, b,c from SEI CMM for certification and some
                    > > other process for betterment of the project, without effecting the
                    > > project/process. I am sure some of the firms have mixed couple
                    process
                    >
                    > Let me reiterate. CMM does not mandate any particular
                    > process, so it is not possible to "mix" a non-existant CMM
                    > process with another.
                    >
                    > All that the CMM and CMMi require is that you
                    >
                    > 1. Have a documented process.
                    > 2. Demonstrably follow the process as documented
                    > 3. That the process, as documented, addresses each of the points
                    > at the appropriate CMM or CMMi level.
                    >
                    > It's also not necessary to "mix" another process with
                    > XP to meet CMM certification. It may be necessary
                    > to agument a minimal XP with other practices to meet
                    > some of the points, but I'd be very wary of taking
                    > things from other processes and simply bolting them
                    > onto the XP framework.

                    What I am thinking is ,
                    1. RUP for planning (and also for project tracking) some
                    documentation to start with. This is what PMs like most.
                    2. XP for the process.
                    3. Do not know yet (still researching)

                    This is really great place for getting the picture about the XP
                    process
                    >
                    > The core of XP is a Lean pull type development
                    > process with minimal handoffs. (This is not, by the
                    > way, described in any of the literature this way)
                    > Most other methodologies are designed for a
                    > push type of process, so individual practices
                    > simply don't transfer without rethinking them
                    > from the ground up.
                    What are other Lean pull type/push type processes, where can I find
                    them?

                    I like XP, because investment/cost is less due to the incremental
                    nature, and results will be known week by week.

                    Also as I understand the "nightly builds", "One Team
                    concept", "Customer On site", "Pair Programming", "Refractoring" and
                    etc are great loveable features.

                    I also watched the "Ken Beck's" "Program Like a Graden".

                    Thanks John
                  • Steven Gordon
                    What does RUP add? Is it there just to placate PMs, or does it actually increase value for the customer in some way? If RUP does serve a real purpose, then
                    Message 9 of 19 , Oct 2, 2003
                    • 0 Attachment
                      What does RUP add? Is it there just to placate PMs, or does it actually increase value for the customer in some way? If RUP does serve a real purpose, then what does XP add?

                      Scrum is a way that some organizations have successfully interfaced XP development with management.

                      -----Original Message-----
                      From: raveendraiah [mailto:RAVEENDRA@...]
                      Sent: Thursday, October 02, 2003 12:38 PM
                      To: extremeprogramming@yahoogroups.com
                      Subject: Re: [XP] Documentation






                      --- In extremeprogramming@yahoogroups.com, yahoogroups@j... wrote:
                      >
                      > ----- Original Message -----
                      > From: "raveendraiah" <RAVEENDRA.at.HOTMAIL.COM@y...>
                      > To: "extremeprogramming@yahoogroups.com"
                      > <extremeprogramming.at.yahoogroups.com@y...>
                      > Sent: Thursday, October 02, 2003 10:20 AM
                      > Subject: Re: [XP] Documentation
                      >
                      >
                      > > --- In extremeprogramming@yahoogroups.com, yahoogroups@j... wrote:
                      > > >
                      > >
                      > > "You may ask how we later know what the design is, since the cards
                      > > are gone. Our answer is that the design is represented in the
                      > > code." Ron Jeffries,
                      > >
                      > > I do understand, we will have phased development, testing with
                      > > shorter cycles with less costs/overheads involved.
                      > >
                      > >
                      > > Thanks John for clearing mind in the documentation. Is it right
                      > > approach to mix two or three models, while working on the project.
                      > >
                      > > x, y, z from XP & a, b,c from SEI CMM for certification and some
                      > > other process for betterment of the project, without effecting the
                      > > project/process. I am sure some of the firms have mixed couple
                      process
                      >
                      > Let me reiterate. CMM does not mandate any particular
                      > process, so it is not possible to "mix" a non-existant CMM
                      > process with another.
                      >
                      > All that the CMM and CMMi require is that you
                      >
                      > 1. Have a documented process.
                      > 2. Demonstrably follow the process as documented
                      > 3. That the process, as documented, addresses each of the points
                      > at the appropriate CMM or CMMi level.
                      >
                      > It's also not necessary to "mix" another process with
                      > XP to meet CMM certification. It may be necessary
                      > to agument a minimal XP with other practices to meet
                      > some of the points, but I'd be very wary of taking
                      > things from other processes and simply bolting them
                      > onto the XP framework.

                      What I am thinking is ,
                      1. RUP for planning (and also for project tracking) some
                      documentation to start with. This is what PMs like most.
                      2. XP for the process.
                      3. Do not know yet (still researching)

                      This is really great place for getting the picture about the XP
                      process
                      >
                      > The core of XP is a Lean pull type development
                      > process with minimal handoffs. (This is not, by the
                      > way, described in any of the literature this way)
                      > Most other methodologies are designed for a
                      > push type of process, so individual practices
                      > simply don't transfer without rethinking them
                      > from the ground up.
                      What are other Lean pull type/push type processes, where can I find
                      them?

                      I like XP, because investment/cost is less due to the incremental
                      nature, and results will be known week by week.

                      Also as I understand the "nightly builds", "One Team
                      concept", "Customer On site", "Pair Programming", "Refractoring" and
                      etc are great loveable features.

                      I also watched the "Ken Beck's" "Program Like a Graden".

                      Thanks John



                      To Post a message, send it to: extremeprogramming@...

                      To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...

                      ad-free courtesy of objectmentor.com

                      Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                    • Keith Ray
                      is that on the web? do you have a link to that? ... -- C. Keith Ray
                      Message 10 of 19 , Oct 2, 2003
                      • 0 Attachment
                        is that on the web? do you have a link to that?

                        On Thursday, October 2, 2003, at 12:37 PM, raveendraiah wrote:

                        > I also watched the "Ken Beck's" "Program Like a Graden".
                        >
                        --
                        C. Keith Ray
                        <http://homepage.mac.com/keithray/blog/index.html>
                        <http://homepage.mac.com/keithray/xpminifaq.html>
                        <http://homepage.mac.com/keithray/resume2.html>
                      • yahoogroups@jhrothjr.com
                        ... From: raveendraiah To: extremeprogramming@yahoogroups.com
                        Message 11 of 19 , Oct 2, 2003
                        • 0 Attachment
                          ----- Original Message -----
                          From: "raveendraiah" <RAVEENDRA.at.HOTMAIL.COM@...>
                          To: "extremeprogramming@yahoogroups.com"
                          <extremeprogramming.at.yahoogroups.com@...>
                          Sent: Thursday, October 02, 2003 3:37 PM
                          Subject: Re: [XP] Documentation



                          > >
                          > > The core of XP is a Lean pull type development
                          > > process with minimal handoffs. (This is not, by the
                          > > way, described in any of the literature this way)
                          > > Most other methodologies are designed for a
                          > > push type of process, so individual practices
                          > > simply don't transfer without rethinking them
                          > > from the ground up.

                          > What are other Lean pull type/push type processes, where can I find
                          > them?

                          Read "Lean Software Development" by Mary and Tom Poppendieck.
                          It explains Lean thinking as applied to software development in
                          great detail.

                          > Thanks John

                          John Roth
                        • raveendraiah
                          It s in extremeprogramming e-groups Files folder
                          Message 12 of 19 , Oct 2, 2003
                          • 0 Attachment
                            It's in extremeprogramming e-groups Files folder
                            --- In extremeprogramming@yahoogroups.com, Keith Ray <keithray@m...>
                            wrote:
                            > is that on the web? do you have a link to that?
                            >
                            > On Thursday, October 2, 2003, at 12:37 PM, raveendraiah wrote:
                            >
                            > > I also watched the "Ken Beck's" "Program Like a Graden".
                            > >
                            > --
                            > C. Keith Ray
                            > <http://homepage.mac.com/keithray/blog/index.html>
                            > <http://homepage.mac.com/keithray/xpminifaq.html>
                            > <http://homepage.mac.com/keithray/resume2.html>
                          • Ron Jeffries
                            ... What I am thinking is that XP /is/ an instance of RUP. It doesn t make much sense to talk about adding them together. And the best place to get the picture
                            Message 13 of 19 , Oct 2, 2003
                            • 0 Attachment
                              On Thursday, October 2, 2003, at 3:37:49 PM, raveendraiah wrote:

                              > What I am thinking is ,
                              > 1. RUP for planning (and also for project tracking) some
                              > documentation to start with. This is what PMs like most.
                              > 2. XP for the process.
                              > 3. Do not know yet (still researching)

                              > This is really great place for getting the picture about the XP
                              > process

                              What I am thinking is that XP /is/ an instance of RUP. It doesn't make much
                              sense to talk about adding them together.

                              And the best place to get the picture about XP is to do it. I would not
                              advise figuring out how to do better than XP before using it.

                              Ron Jeffries
                              www.XProgramming.com
                              He who will not apply new remedies must expect old evils. -- Francis Bacon
                            • Chris Hanson
                              ... This doesn t make much sense. Phased development typically means waterfall, which typically means high-risk top-down documentation-heavy Big Design Up
                              Message 14 of 19 , Oct 2, 2003
                              • 0 Attachment
                                On Thursday, October 2, 2003, at 09:20 AM, raveendraiah wrote:
                                > I do understand, we will have phased development, testing with
                                > shorter cycles with less costs/overheads involved.

                                This doesn't make much sense. "Phased development" typically means
                                "waterfall," which typically means high-risk top-down
                                documentation-heavy Big Design Up Front (BDUF) garbage.

                                Shorter cycles can help manage risk, but not as much as using a
                                non-BDUF agile process like XP. I think you need to take a step back
                                and understand a little bit more about (a) how XP is actually done and
                                (b) why XP is the way it is before deciding on what process to use.
                                You may still choose a process other than XP, but at least you'll do so
                                with your eyes open.

                                > x, y, z from XP & a, b,c from SEI CMM for certification and some
                                > other process for betterment of the project, without effecting the
                                > project/process. I am sure some of the firms have mixed couple process

                                As others have said, SEI CMM isn't a process. It's a method for
                                evaluating whether an organization conforms to what it says its process
                                is, plus some areas the organization's process is supposed to address.

                                It's also nonsensical to think you can just mix and match different
                                software process components without affecting the project or the
                                process. (Literally nonsensical in the latter case, as you're talking
                                about changing the process not affecting the process!) Changes *will*
                                affect things. That's why you should be careful about how and why you
                                make them.

                                If you're going to do XP, you should really try to do XP as much by the
                                book as possible. Once you've done it by the book for a while, you can
                                start tweaking and adjusting it where it's suboptimal for your
                                particular circumstances. You'll probably discover you don't need
                                parts from "some other process for betterment of the project" since the
                                project is going very well as-is.

                                And, just in my opinion, having a high CMM assessment as a goal is
                                bogus. An organization's CMM level is almost meaningless in terms of
                                whether a project will actually be successful, in terms of coming in on
                                time, on budget, and addressing the most important business needs at
                                the time of its delivery (rather than conception). It's the people
                                involved and how they apply their development process that will
                                ultimately determine a project's success.

                                Which is more important, a marketing bullet point (CMM level) or a
                                track record of successful projects and highly satisfied clients?
                                (Hint: You can bill a higher rate with the latter; with the former,
                                you're essentially treating software development as a commodity which
                                will result in very low and homogenized bill rates.)

                                -- Chris

                                --
                                Chris Hanson, bDistributed.com, Inc. | Email: cmh@...
                                Custom Mac OS X Development | Phone: +1-847-372-3955
                                http://bdistributed.com/ | Fax: +1-847-589-3738
                                http://bdistributed.com/Articles/ | Personal Email: cmh@...
                              • Nancy Van Schooenderwoert
                                ... You should check out Mary Poppendieck s book Lean Software Development if you have not already. There is a lot of background on the whole lean
                                Message 15 of 19 , Oct 2, 2003
                                • 0 Attachment
                                  On Thu, 2003-10-02 at 15:37, raveendraiah wrote:

                                  > What are other Lean pull type/push type processes, where can I find
                                  > them?
                                  >
                                  You should check out Mary Poppendieck's book "Lean Software
                                  Development" if you have not already. There is a lot of background on
                                  the whole "lean" approach.

                                  By the way - on this pull/push idea, I happened to see a good passage
                                  in Warren Bennis' book "Managing People is Like Herding Cats". The quote
                                  is:
                                  "Management is getting people to do what needs to be done. Leadership is
                                  getting people to want to do what needs to be done. Managers push.
                                  Leaders pull." - p. 189

                                  - njv
                                  << talk to me about Embedded XP >>
                                • WATKINS, Robert
                                  ... XP (and Agile in general) says don t do anything that doesn t add value. ... The rule of thumb is that the customers say what they want delivered. If they
                                  Message 16 of 19 , Oct 2, 2003
                                  • 0 Attachment
                                    raveendraiah wrote:
                                    > I am posting this to understand whole documentation involved in XP:

                                    XP (and Agile in general) says don't do anything that doesn't add value.

                                    > In effort to reduce documentation XP, does produce piece-by-piece
                                    > documentation. But not enough documentation like CMM (Analysis,
                                    > Design, Test, TDD, Unit testing). If you take some start-ups, they do
                                    > work on the documentation, and review it before even they start the
                                    > project from all the members of the firm.

                                    The rule of thumb is that the customers say what they want delivered. If
                                    they ask for documentation, they get it. If the developers feel that
                                    something makes them go faster, then they can do that, as well.

                                    Most traditional methodologies make you document things before you know that
                                    is what you really want. The classic case is to document a design for a
                                    system before you have proven, through testing, that the design is
                                    sufficient. The result is that you need to go back and rework a
                                    fully-fledged design document when you make a change to your design (often
                                    with associated review cycles). A good example would be an author needing to
                                    have their book typeset, printed and bound every time they submitted a new
                                    draft to an editor...

                                    You can get feedback on designs without needing to produce fully-fledged
                                    design documentation. An example would be to grab the people who would do
                                    the review for a white-board session, where the design concepts are sketched
                                    on the board for review and comment. Want a record of it? Video it. If you
                                    must have something written to circulate, then a) you're not doing XP (which
                                    relies on much richer communication channels), and b) you can get away with
                                    a fairly informal outline.

                                    Once the design is stable-ish and proven, you can document it then if you
                                    need to. This removes the need to rework the documentation.

                                    > Does lack documentation will effect the future of the project, what
                                    > if the project is transferred to overseas (Romania, India, China) ,
                                    > and all the members of the project is moved to different project.

                                    If the customer wants to ship the project overseas, they should allow time
                                    in the schedule for a house-cleaning and hand-over period. During this time,
                                    the documentation can be produced. Or, better yet, the old development team
                                    and the new development team can get together and transfer the knowledge
                                    directly from head-to-head.

                                    > Let's assume working "Mission Impossible Part3", in four different
                                    > phases with 4 different directors, who will do their part on their
                                    > own. How will we get best movie out of the directors who will work on
                                    > the part by looking at previous parts by looking at the movie
                                    > (reading the code) rather than documentation/story?

                                    Firstly, on a team of 10 developers, there would be 10 different directors.
                                    :) It's all design.

                                    Secondly, if you have successful handover, then each team will be on the
                                    same page.

                                    Documentation is an information transfer mechanism only. It is also a poor
                                    one, as the reader of the document can not ask the author any questions to
                                    help them complete their understanding. As a result, documentation
                                    invariably fits into two categories: too detailed and too much to wade
                                    through, or not detailed enough and useless (a third category, which
                                    documents can also be in at the same time, is flat out wrong)

                                    There are other ways of transferring information. Depending on context, they
                                    can easily be more effective. Alistair Cockburn's "Agile Software
                                    Development" has some good reading on this.

                                    > My question is how much documentation is generated during the total
                                    > XP process?

                                    As much as the customer asks for, and as much as the developers feel helps
                                    them proceed at speed.

                                    --
                                    "Software is too expensive to build cheaply"
                                    Robert Watkins Application System Specialist
                                    robertdw@... robert.watkins@...


                                    -----------------------------------------------------------------------------------

                                    The contents of this message are the views of the Author and do not necessarily reflect the views of SUNCORP METWAY LTD ABN 66 010 831 722.

                                    The content of this e-mail, including attachments is a confidential communication between the Suncorp Metway Group and the intended addressee. Any unauthorised use of the contents is expressly prohibited. If you have received this e-mail in error please contact the sender immediately and then delete the message and any attachment(s).

                                    http://www.suncorp.com.au
                                  • raveendraiah
                                    ... actually increase value for the customer in some way? If RUP does serve a real purpose, then what does XP add? Steve : Thanks for the offline message. I
                                    Message 17 of 19 , Oct 4, 2003
                                    • 0 Attachment
                                      --- In extremeprogramming@yahoogroups.com, Steven Gordon
                                      <sagordon@a...> wrote:
                                      > What does RUP add? Is it there just to placate PMs, or does it
                                      actually increase value for the customer in some way? If RUP does
                                      serve a real purpose, then what does XP add?
                                      Steve :

                                      Thanks for the offline message. I did reply to your e-mail.

                                      When I meant RUP, this actually to create the template project chart,
                                      for project planning.

                                      I still need to understand XP kind of "planning", getting lot of
                                      info, by reading different articles. But I am still digesting before
                                      asking further questions.

                                      As suggested by group, i would like work on the xp process, then i
                                      can learn.

                                      I did forwarded the XP process to some of my friends, they are happy
                                      now about this process. They are currently demonstrating this process
                                      to their management and team members.

                                      Basically I am investigation for my career advancement and next
                                      project building. As I always believe in learning before
                                      implementing.

                                      Really got bounced by the Xp vs CMM article i found in the files
                                      folder.

                                      >
                                      > Scrum is a way that some organizations have successfully interfaced
                                      XP development with management.

                                      What is meant by SCRUM?
                                      > -----Original Message-----
                                      > From: raveendraiah [mailto:RAVEENDRA@H...]
                                      > Sent: Thursday, October 02, 2003 12:38 PM
                                      > To: extremeprogramming@yahoogroups.com
                                      > Subject: Re: [XP] Documentation
                                      >
                                      >
                                      >
                                      >
                                      >
                                      >
                                      > --- In extremeprogramming@yahoogroups.com, yahoogroups@j... wrote:
                                      > >
                                      > > ----- Original Message -----
                                      > > From: "raveendraiah" <RAVEENDRA.at.HOTMAIL.COM@y...>
                                      > > To: "extremeprogramming@yahoogroups.com"
                                      > > <extremeprogramming.at.yahoogroups.com@y...>
                                      > > Sent: Thursday, October 02, 2003 10:20 AM
                                      > > Subject: Re: [XP] Documentation
                                      > >
                                      > >
                                      > > > --- In extremeprogramming@yahoogroups.com, yahoogroups@j...
                                      wrote:
                                      > > > >
                                      > > >
                                      > > > "You may ask how we later know what the design is, since the
                                      cards
                                      > > > are gone. Our answer is that the design is represented in the
                                      > > > code." Ron Jeffries,
                                      > > >
                                      > > > I do understand, we will have phased development, testing with
                                      > > > shorter cycles with less costs/overheads involved.
                                      > > >
                                      > > >
                                      > > > Thanks John for clearing mind in the documentation. Is it right
                                      > > > approach to mix two or three models, while working on the
                                      project.
                                      > > >
                                      > > > x, y, z from XP & a, b,c from SEI CMM for certification and
                                      some
                                      > > > other process for betterment of the project, without effecting
                                      the
                                      > > > project/process. I am sure some of the firms have mixed couple
                                      > process
                                      > >
                                      > > Let me reiterate. CMM does not mandate any particular
                                      > > process, so it is not possible to "mix" a non-existant CMM
                                      > > process with another.
                                      > >
                                      > > All that the CMM and CMMi require is that you
                                      > >
                                      > > 1. Have a documented process.
                                      > > 2. Demonstrably follow the process as documented
                                      > > 3. That the process, as documented, addresses each of the points
                                      > > at the appropriate CMM or CMMi level.
                                      > >
                                      > > It's also not necessary to "mix" another process with
                                      > > XP to meet CMM certification. It may be necessary
                                      > > to agument a minimal XP with other practices to meet
                                      > > some of the points, but I'd be very wary of taking
                                      > > things from other processes and simply bolting them
                                      > > onto the XP framework.
                                      >
                                      > What I am thinking is ,
                                      > 1. RUP for planning (and also for project tracking) some
                                      > documentation to start with. This is what PMs like most.
                                      > 2. XP for the process.
                                      > 3. Do not know yet (still researching)
                                      >
                                      > This is really great place for getting the picture about the XP
                                      > process
                                      > >
                                      > > The core of XP is a Lean pull type development
                                      > > process with minimal handoffs. (This is not, by the
                                      > > way, described in any of the literature this way)
                                      > > Most other methodologies are designed for a
                                      > > push type of process, so individual practices
                                      > > simply don't transfer without rethinking them
                                      > > from the ground up.
                                      > What are other Lean pull type/push type processes, where can I find
                                      > them?
                                      >
                                      > I like XP, because investment/cost is less due to the incremental
                                      > nature, and results will be known week by week.
                                      >
                                      > Also as I understand the "nightly builds", "One Team
                                      > concept", "Customer On site", "Pair Programming", "Refractoring"
                                      and
                                      > etc are great loveable features.
                                      >
                                      > I also watched the "Ken Beck's" "Program Like a Graden".
                                      >
                                      > Thanks John
                                      >
                                    • Arrowood, Paul (ELS-STL)
                                      I think I listed to one of Bob Payne s podcasts yesterday that suggested the best technical conversation lies WITHIN in the code, and you augment that with
                                      Message 18 of 19 , Sep 7, 2006
                                      • 0 Attachment
                                        I think I listed to one of Bob Payne's podcasts yesterday that suggested the
                                        "best" technical conversation lies WITHIN in the code, and you augment that
                                        with System Overview document(s) for those not IN the code. Hopefully I
                                        got that right, but I'm curious what everyone else says.



                                        _____

                                        From: extremeprogramming@yahoogroups.com
                                        [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Greg Akins
                                        Sent: Thursday, September 07, 2006 9:25 AM
                                        To: extremeprogramming@yahoogroups.com
                                        Subject: [XP] Documentation



                                        I'd like to open a discussion on documentation.

                                        I believe that automated testing, continuous integration and pair
                                        programming mitigates the need for documentation...

                                        However, I also believe that a system, especially one that's been
                                        evolving over years, needs a framework of documentation to help guide
                                        developers.

                                        Also, I'm on a team that hasn't completely embraced automated testing,
                                        continuous integration and pair programming and perhaps there should
                                        be more consistent creation of documentation while the team moves
                                        toward more "XP" practices.

                                        I think that good documentation includes high-level descriptions of
                                        the system and metaphors used by the team. While ideally, the lower
                                        level documentation is not as necessary, it can be created initially
                                        and replaced (leaving the higher level artifacts intact) as the team
                                        adopts more practices.

                                        Thoughts, or experiences?

                                        --
                                        ==============
                                        Greg Akins
                                        http://www.pghcodin <http://www.pghcodingdojo.org> gdojo.org





                                        [Non-text portions of this message have been removed]
                                      • Arrowood, Paul (ELS-STL)
                                        Um...I meant to say listened instead of listed....and forget to credit Scott Ambler as the interviewee... _____ From: extremeprogramming@yahoogroups.com
                                        Message 19 of 19 , Sep 7, 2006
                                        • 0 Attachment
                                          Um...I meant to say "listened" instead of listed....and forget to credit
                                          Scott Ambler as the interviewee...



                                          _____

                                          From: extremeprogramming@yahoogroups.com
                                          [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Arrowood, Paul
                                          (ELS-STL)
                                          Sent: Thursday, September 07, 2006 10:15 AM
                                          To: extremeprogramming@yahoogroups.com
                                          Subject: RE: [XP] Documentation



                                          I think I listed to one of Bob Payne's podcasts yesterday that suggested the
                                          "best" technical conversation lies WITHIN in the code, and you augment that
                                          with System Overview document(s) for those not IN the code. Hopefully I
                                          got that right, but I'm curious what everyone else says.

                                          _____

                                          From: extremeprogramming@ <mailto:extremeprogramming%40yahoogroups.com>
                                          yahoogroups.com
                                          [mailto:extremeprogramming@ <mailto:extremeprogramming%40yahoogroups.com>
                                          yahoogroups.com] On Behalf Of Greg Akins
                                          Sent: Thursday, September 07, 2006 9:25 AM
                                          To: extremeprogramming@ <mailto:extremeprogramming%40yahoogroups.com>
                                          yahoogroups.com
                                          Subject: [XP] Documentation

                                          I'd like to open a discussion on documentation.

                                          I believe that automated testing, continuous integration and pair
                                          programming mitigates the need for documentation...

                                          However, I also believe that a system, especially one that's been
                                          evolving over years, needs a framework of documentation to help guide
                                          developers.

                                          Also, I'm on a team that hasn't completely embraced automated testing,
                                          continuous integration and pair programming and perhaps there should
                                          be more consistent creation of documentation while the team moves
                                          toward more "XP" practices.

                                          I think that good documentation includes high-level descriptions of
                                          the system and metaphors used by the team. While ideally, the lower
                                          level documentation is not as necessary, it can be created initially
                                          and replaced (leaving the higher level artifacts intact) as the team
                                          adopts more practices.

                                          Thoughts, or experiences?

                                          --
                                          ==============
                                          Greg Akins
                                          http://www.pghcodin <http://www.pghcodin> <http://www.pghcodin
                                          <http://www.pghcodingdojo.org> gdojo.org> gdojo.org

                                          [Non-text portions of this message have been removed]





                                          [Non-text portions of this message have been removed]
                                        Your message has been successfully submitted and would be delivered to recipients shortly.