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

summary of the disscusion

Expand Messages
  • zdnfa
    Dear all, After a couple of discussions on documentation and knowledge sharing in XP I would like to summerize what I understood, and would like to see your
    Message 1 of 11 , Nov 5, 2009
    • 0 Attachment
      Dear all,

      After a couple of discussions on documentation and knowledge sharing in XP I would like to summerize what I understood, and would like to see your comments on the ideas presented
      Your comments on the ideas I presented were as follows:

      • Size of the project: all the posts suggested that 10 programmers are enough to do any project disregard to the project size (See what curtis cooley in this regard as an example).

      • XP process: all the posts suggested that no modifications should be introduced to XP's lifecycle, no matter the context is. If the current lifecycle is not fit, we can use Crystal (ron's suggestion). The only exception to that is what Kent said (" the process you are processing looks reasonable to me…..it enhances accountability and responsibility") if I understood him correctly. This means that if we use all principles of XP and modify the lifecycle then this is not XP. Jon spoke also of the purity of XP. Use of analysis phase was also rejected. The term pair development is accepted and considered a more explanative than pair programming.

      • Tacit Vs. explicit knowledge: almost everyone in this discussion emphasized the importance of tacit knowledge sharing. Code and test cases are the used forms of explicit knowledge. Fear of miscommunication through documentation, the burden of their creation and maintenance, and usefulness lead to resistance of documents as a knowledge sharing tool. Exception to that are the posts in documentation and designing post, where some encouraged the use of 'light ' models and documents such as ERD and Use Cases.

      Looking forward to see your comments
      Regards
      Zaidoun
    • William Pietri
      ... The one important exception that I can think of is any document request that the XP Customer puts in the normal work queue. The way I teach it to people,
      Message 2 of 11 , Nov 6, 2009
      • 0 Attachment
        zdnfa wrote:
        > Fear of miscommunication through documentation, the burden of their creation and maintenance, and usefulness lead to resistance of documents as a knowledge sharing tool. Exception to that are the posts in documentation and designing post, where some encouraged the use of 'light ' models and documents such as ERD and Use Cases.
        >
        The one important exception that I can think of is any document request
        that the XP Customer puts in the normal work queue. The way I teach it
        to people, anyhow. Sometimes people actually need documentation for a
        real business need.

        For example, one team was suspending work on a project for an indefinite
        period. The business wanted some written documentation of the software
        architecture, development approaches, and other tacit knowledge that is
        hard to reproduce from just the code. Those were treated like normal
        stories -- written on cards, estimated in points, put in an iteration --
        but instead of producing shipping code, they produced documents
        delivered to management.

        William
      • Critique
        Zaidoun, ... I dislike the way this is phrased because, to my mind, it suggests that I spoke of XP as something that was pure , giving an implication that it
        Message 3 of 11 , Nov 6, 2009
        • 0 Attachment
          Zaidoun,

          > Jon spoke also of the purity of XP.

          I dislike the way this is phrased because, to my mind, it suggests
          that I spoke of XP as something that was "pure", giving an implication
          that it is right. (Pure gold, pure (unblemished) victory, etc)

          I was attempting to indicate that the perceived "purity" of a given
          application of a set of ideas will vary from person to person, as it
          depends on personal viewpoint, and that I don't think we should get
          overly hung up on trying to define a boundary demarking what
          "acceptable" limits of variation are before something ceases to belong
          to that set of ideas.

          The label isn't as important as the content. I think we should be
          focused on getting as much benefit as we can out of the various
          practices discussed, rather than worrying about their fine
          categorisation. This is an XP mailing list so it's right that we are
          centered in that area, but we shouldn't be afraid to look a little
          beyond it, to pull in variations and new ideas if they are useful.

          If there were complete agreement and we all shared the same knowledge
          and ideas there would be no need for discussion.

          Jon
        • Phlip
          ... The goal is all programmers feel like their code and team are small. If your project is so large it requires more than 5 programmers, at some point you
          Message 4 of 11 , Nov 6, 2009
          • 0 Attachment
            zdnfa wrote:

            > • Size of the project: all the posts suggested that 10 programmers
            > re enough to do any project disregard to the project size

            The goal is all programmers feel like their code and team are small.

            If your project is so large it requires more than 5 programmers, at some point
            you must split the team, and let one group treat the other as a vendor.

            > • XP process: all the posts suggested that no modifications should
            > be introduced to XP's lifecycle, no matter the context is.

            I'm afraid some here would like to say "my team is sufficiently experienced that
            we can change our rules, but you cannot." (-:

            Ideally, a project should start as close to pure XP as possible, then should
            only add more heavy process details when the team learns they need them.

            For example, when we say "story card", we don't mean a userstory written into a
            computer program with a "card" object. We mean a real, paper, 3x5 index card. A
            team should start by writing these cards and pinning them to a cork board. Only
            after trying that for a while should a team then experiment with an automated
            card system, such as Mingle, to determine if the card system adds any value.

            XP supports a parody of the CMM Levels concept (levels 1 thru 5):

            XP Level 1: Do all the practices according to the book
            XP Level 2: Modify the practices to fit your situation
            XP Level 3: You no longer care what level you are.

            > Jon spoke also of the purity of XP. Use of analysis phase was also rejected.

            The books about "Lean Software Development" explain that. When you analyze,
            without any code yet, you are tempted to make decisions about how to implement
            things. For example, "we will obviously need to install a big, heavy, expensive
            database engine, first, to support all these records".

            You are making those decisions before you have hard data to support them. If you
            instead start writing your most important features, when the time comes to store
            their data, you can first try to put them into a flat file. If you then discover
            you need a database, you can replace the flat file and then pass all your tests.
            "DeprecationRefactor". The tests pin down your important features, making the
            change easy and safe.

            Because you already have live features, you can easily prove what parameters of
            database you need (not just "the biggest one!"), and you can measure the results.

            However, if you prove you don't need a big heavy database engine there, then you
            won. The flat file was the simplest path to a useful system. And if any future
            requirements force you to switch to a database engine, then you also won. You
            successfully delivered the high value features, and got customer feedback on
            them, without making them wait for you to install a database.

            All this depends very strictly on "Just In Time Requirements". You have to do
            them in order of business value, so the most important features see code first,
            and get tuned and refactored for the longest time, as the source code grows.

            And you should deploy to a real production site, or a mockup of one, as early
            and often as possible. This prevents blind spots!

            Your customers, running the new system, will have very good ideas how to improve
            it - ideas based on hard data - and the improvements will mostly be small tweaks
            over your existing system.

            > The term pair development is accepted and considered a more explanative than
            > pair programming.

            And remember to build "pair stations", with dual keyboards. No individual
            programmers should feel like they own any of them.

            The word "development" is important, because nobody should enforce pairing
            unless you are actually developing. Other pair activities, such as pair
            debugging or pair researching, are very irritating!

            > • Tacit Vs. explicit knowledge: almost everyone in this discussion emphasized
            > the importance of tacit knowledge sharing. Code and test cases are the used forms
            > of explicit knowledge. Fear of miscommunication through documentation,

            Tests are closer to the code than documentation. They are less likely to
            mislead, so put most of your energy into them. And use a literate test
            framework, such as Fitnesse or Cucumber.

            > the burden of their creation and maintenance, and usefulness lead to
            > resistance of documents as a knowledge sharing tool. Exception to that
            > are the posts in documentation and designing post, where some
            > encouraged the use of 'light ' models and documents such as ERD and Use Cases.

            Document early and often. But. Don't treat the documentation as the product
            (unless it is). A thousand pages of specifications are not worth one developer
            test case.

            Use the customer tests as use cases. They should be as literate as possible,
            such as this:

            Scenario: See all vendors
            Given I am logged in as a user in the administrator role
            And There are 3 vendors
            When I go to the manage vendors page
            Then I should see the first 3 vendor names

            Ideally, your customers should write those test cases, and hand them to you to pass.

            And if you have an ORM (object relation manager) worthy of the name, such as an
            ActiveRecord pattern implementation, you should be able to configure it easily
            to emit your ERD on command. You could add to your Makefile a command, such as
            'diagram', that reads today's version of the persistent objects, and displays
            them in an instant PNG file, like this:

            http://railroad.rubyforge.org/
            http://railroad.rubyforge.org/diagrams/typo_controllers_full.png

            Part of the meaning of XP, and the reason we like to ask people to obey our
            guidelines, is any hard work required to support these techniques is not wasted
            energy. Quite the contrary - it IS the analysis and planning phase. If your
            project cannot yet test easily, or document itself, then you have a big problem,
            and you should work to solve it as early as possible.

            --
            Phlip
          • Phlip
            ... The Tao that can be understood is less than the Eternal Tao. We might also have some language translation issues, too. (-:
            Message 5 of 11 , Nov 6, 2009
            • 0 Attachment
              Critique wrote:

              > Zaidoun,
              >
              >> Jon spoke also of the purity of XP.
              >
              > I dislike the way this is phrased because, to my mind, it suggests
              > that I spoke of XP as something that was "pure", giving an implication
              > that it is right. (Pure gold, pure (unblemished) victory, etc)

              The Tao that can be understood is less than the Eternal Tao.

              We might also have some language translation issues, too. (-:
            • Steven Gordon
              Zaidoun , The objective is to do what works best in each particular project context. The ultimately responsibility is to deliver value, not to blindly follow
              Message 6 of 11 , Nov 6, 2009
              • 0 Attachment
                Zaidoun ,

                The objective is to do what works best in each particular project context.
                The ultimately responsibility is to deliver value, not to blindly follow XP
                (or any other process).

                If your context requires more permanent documentation than typical XP
                projects, who are we to say that is necessarily wrong (although it might
                be). I am only saying that it being the case in your context does not mean
                that all other XP projects also need more permanent documentation, so we
                resist changing XP itself.

                I like to think of all agile processes as just the starting point for a
                project. Reflection and adaptation to context and feedback means each
                team's process will change a bit over time. This is good, but these
                adaptations do not change the starting points for other teams.

                We like to hear about adaptations that have proved sucessful, but those
                individual adaptations do not change XP itself.

                Steve


                On Thu, Nov 5, 2009 at 11:03 PM, zdnfa <zdnfa@...> wrote:

                >
                >
                >
                > Dear all,
                >
                > After a couple of discussions on documentation and knowledge sharing in XP
                > I would like to summerize what I understood, and would like to see your
                > comments on the ideas presented
                > Your comments on the ideas I presented were as follows:
                >
                > � Size of the project: all the posts suggested that 10 programmers are
                > enough to do any project disregard to the project size (See what curtis
                > cooley in this regard as an example).
                >
                > � XP process: all the posts suggested that no modifications should be
                > introduced to XP's lifecycle, no matter the context is. If the current
                > lifecycle is not fit, we can use Crystal (ron's suggestion). The only
                > exception to that is what Kent said (" the process you are processing looks
                > reasonable to me�..it enhances accountability and responsibility") if I
                > understood him correctly. This means that if we use all principles of XP and
                > modify the lifecycle then this is not XP. Jon spoke also of the purity of
                > XP. Use of analysis phase was also rejected. The term pair development is
                > accepted and considered a more explanative than pair programming.
                >
                > � Tacit Vs. explicit knowledge: almost everyone in this discussion
                > emphasized the importance of tacit knowledge sharing. Code and test cases
                > are the used forms of explicit knowledge. Fear of miscommunication through
                > documentation, the burden of their creation and maintenance, and usefulness
                > lead to resistance of documents as a knowledge sharing tool. Exception to
                > that are the posts in documentation and designing post, where some
                > encouraged the use of 'light ' models and documents such as ERD and Use
                > Cases.
                >
                > Looking forward to see your comments
                > Regards
                > Zaidoun
                >
                >
                >
                >


                [Non-text portions of this message have been removed]
              • Ron Jeffries
                Hello, zdnfa. On Friday, November 6, 2009, at 1:03:47 AM, you ... All the posts DID NOT SUGGEST THAT. Some, perhaps only one, did. ... What was said that XP
                Message 7 of 11 , Nov 6, 2009
                • 0 Attachment
                  Hello, zdnfa. On Friday, November 6, 2009, at 1:03:47 AM, you
                  wrote:

                  > After a couple of discussions on documentation and knowledge
                  > sharing in XP I would like to summerize what I understood, and
                  > would like to see your comments on the ideas presented
                  > Your comments on the ideas I presented were as follows:

                  > • Size of the project: all the posts suggested that 10
                  > programmers are enough to do any project disregard to the project
                  > size (See what curtis cooley in this regard as an example).

                  All the posts DID NOT SUGGEST THAT. Some, perhaps only one, did.

                  > • XP process: all the posts suggested that no modifications
                  > should be introduced to XP's lifecycle, no matter the context is.

                  What was said that XP should not be redefined. Everyone agrees, I
                  think, that an individual team's process is and should be modified
                  to fit their needs.

                  > If the current lifecycle is not fit, we can use Crystal (ron's
                  > suggestion).

                  The advantage to Crystal for your purposes is that Alistair defines
                  a family of processes tailor made for various sizes of problem,
                  team, and risk.

                  > The only exception to that is what Kent said (" the
                  > process you are processing looks reasonable to me…..it enhances
                  > accountability and responsibility") if I understood him
                  > correctly.

                  Yes he did say something like that. I think most people would agree
                  that if YOUR team needs the elements you mention, you should do
                  them. Many of us suspect that your team MAY not need them, but we
                  base this on observing other teams who thought they needed things,
                  not on inspecting your team.

                  > This means that if we use all principles of XP and
                  > modify the lifecycle then this is not XP.

                  I do not understand what it would mean to say that a given process
                  is, or is not, XP, nor why anyone would want to say it. What
                  matters, its seems to me, is whether a given process is effective,
                  and if the team likes the XP ideas, it makes sense to try to apply
                  them.

                  > Jon spoke also of the purity of XP. Use of analysis phase was also
                  > rejected. The term pair development is accepted and considered a
                  > more explanative than pair programming.

                  I'm not sure what you're getting at here. Now that I think of it,
                  I'm not sure what you are getting at at all. I await enlightenment.

                  > • Tacit Vs. explicit knowledge: almost everyone in this
                  > discussion emphasized the importance of tacit knowledge sharing.
                  > Code and test cases are the used forms of explicit knowledge. Fear
                  > of miscommunication through documentation, the burden of their
                  > creation and maintenance, and usefulness lead to resistance of
                  > documents as a knowledge sharing tool. Exception to that are the
                  > posts in documentation and designing post, where some encouraged
                  > the use of 'light ' models and documents such as ERD and Use Cases.

                  I think you may be mischaracterizing people's views here. I am
                  certain that you are over-generalizing, in that there are thousands
                  of members on this list with opinions, and we have not heard from
                  most of them.

                  Regards,

                  Ron Jeffries
                  www.XProgramming.com
                  www.xprogramming.com/blog
                  It is not because things are difficult that we do not dare,
                  it is because we do not dare that they are difficult. --Seneca
                • zaidoun alzoabi
                  ...   cool down Ron!! when I saw no comments on what Cooley said i -mistakenly as appeared- thought that everybody agrees to it. So do you think that some
                  Message 8 of 11 , Nov 6, 2009
                  • 0 Attachment
                    > • Size of the project: all the posts suggested that 10
                    > programmers are enough to do any project disregard to the project
                    > size (See what curtis cooley in this regard as an example).

                    >>All the posts DID NOT SUGGEST THAT. Some, perhaps only one, did.
                     
                    cool down Ron!! when I saw no comments on what Cooley said i -mistakenly as appeared- thought that everybody agrees to it. So do you think that some projects require more than 10 programmers? if we have such projects, do we stick to the same face-to-face principle? would it be enough?
                     
                    > • XP process: all the posts suggested that no modifications
                    > should be introduced to XP's lifecycle, no matter the context is.

                    >>What was said that XP should not be redefined. Everyone agrees, I
                    >>think, that an individual team's process is and should be modified
                    >>to fit their needs.
                     
                    It is not redifining XP, it is a suggestion when using XP in large projects. In those projects, where we need to reach a common understading in highly complex environment.
                     
                    >>I think you may be mischaracterizing people's views here. I am
                    >>certain that you are over-generalizing, in that there are thousands
                    >>of members on this list with opinions, and we have not heard from
                    >>most of them.

                    I did not say everyone in the group, I just said everybody in the discussion, this obviously does not mean everyone in the group, and those who participated in the discussion emphasized tacit knowledge sharing, you can review the posts and you will get to the same conclusion.
                     
                    One more note: I met the project manager of one of the leading software companies in the Middle East, who is providing software to large mobile communication using XP as the software development method and he said: " no matter how we explain to our customers that many documents are not needed, ALL our customers insisted to have these documents and in fact in some cases we found that these documents are useful"
                    Regards,

                    Zaidoun




                    [Non-text portions of this message have been removed]
                  • Adam Sroka
                    ... Not exactly. One of the lessons of Agile is that smaller is better. Small classes and methods are easier to understand and maintain. Small stories are
                    Message 9 of 11 , Nov 6, 2009
                    • 0 Attachment
                      On Thu, Nov 5, 2009 at 10:03 PM, zdnfa <zdnfa@...> wrote:
                      >
                      >
                      >
                      > Dear all,
                      >
                      > After a couple of discussions on documentation and knowledge sharing in XP I would like to summerize what I understood, and would like to see your comments on the ideas presented
                      > Your comments on the ideas I presented were as follows:
                      >
                      > • Size of the project: all the posts suggested that 10 programmers are enough to do any project disregard to the project size (See what curtis cooley in this regard as an example).
                      >

                      Not exactly. One of the lessons of Agile is that smaller is better.
                      Small classes and methods are easier to understand and maintain. Small
                      stories are quicker to implement. Small teams gel quickly and can
                      swarm on stories to get them done. Small, frequent releases enable
                      rapid customer feedback. Etc. This is contrary to the traditional view
                      that if I want to do twice as much I just double my resources.

                      It is not possible to scale an Agile team without fundamentally
                      effecting the way that they work, and I have yet to see this happen
                      for the better. It is possible to scale Agile projects by breaking the
                      work along business or functional lines. I have seen this work, but I
                      am not convinced that it was better.

                      The problem with scaling is that most businesses, particularly large
                      ones, think that their problems are large. The reality is that nearly
                      every supposedly large problem is really just a set of small problems,
                      and each of those small problems benefits from having a small cohesive
                      group focus in on it and get it done. It might be possible for more
                      than one small team to work on each of these small problems, but that
                      mitigates our ability to learn from each small problem and adapt our
                      path towards the larger goal.

                      Agile teams are like Special Forces. You might think that having more
                      Special Forces was better. The reality is that maintaining a small
                      footprint and operating as a small, cohesive team is fundamental to
                      their ability to do their job. If you put a bunch of them together as
                      a big team then they have to operate as a big team which means they
                      can't do the missions that they can do as a small team.

                      > • XP process: all the posts suggested that no modifications should be introduced to XP's lifecycle, no matter the context is. If the current lifecycle is not fit, we can use Crystal (ron's suggestion). The only exception to that is what Kent said (" the process you are processing looks reasonable to me…..it enhances accountability and responsibility") if I understood him correctly. This means that if we use all principles of XP and modify the lifecycle then this is not XP. Jon spoke also of the purity of XP. Use of analysis phase was also rejected. The term pair development is accepted and considered a more explanative than pair programming.
                      >

                      I am not going to speak for anyone else. What I have been trying to
                      say is that there is a reason that some of us don't do things the way
                      you suggest.

                      I am less and less interested in whether you call what you are doing
                      XP or some sort of modification to XP. The point that you seem to be
                      ignoring is that the things you want to add to XP aren't in XP *by
                      design*.

                      Most folks who have done XP have also done formal documentation and
                      analysis phases. I did RUP. I even got formal training in RUP and used
                      some of the tools. It didn't work very well, and I didn't enjoy it. As
                      a recovering RUP user I found XP and discovered that it emphasized
                      many of the things that I knew mattered (Like code that works, and
                      working together to solve business problems) and rejected many of the
                      things that I couldn't get to work (Like analysis phases and detailed
                      specs.)

                      When XP and other "lean methods" were invented they were based on the
                      idea that we could focus on the activities that really mattered to
                      creating quality working software and ignore much of the rest. The
                      things you are suggesting are things that we deliberately removed.
                      Before you put them back in it might be worth your while to understand
                      why we removed them. That is the piece that seems to be missing.

                      > • Tacit Vs. explicit knowledge: almost everyone in this discussion emphasized the importance of tacit knowledge sharing. Code and test cases are the used forms of explicit knowledge. Fear of miscommunication through documentation, the burden of their creation and maintenance, and usefulness lead to resistance of documents as a knowledge sharing tool. Exception to that are the posts in documentation and designing post, where some encouraged the use of 'light ' models and documents such as ERD and Use Cases.
                      >

                      I have been excruciatingly clear on this, and I'm not going to waste
                      another second on it... damn, I just did ;-)
                    • Curtis Cooley
                      ... If I did say any project can be done with 10 people then I disagree with what I said. What I meant is that I do not believe the increase in productivity as
                      Message 10 of 11 , Nov 6, 2009
                      • 0 Attachment
                        On Fri, Nov 6, 2009 at 10:28 AM, zaidoun alzoabi <zdnfa@...> wrote:
                        >
                        >
                        >
                        > > • Size of the project: all the posts suggested that 10
                        > > programmers are enough to do any project disregard to the project
                        > > size (See what curtis cooley in this regard as an example).
                        >
                        > >>All the posts DID NOT SUGGEST THAT. Some, perhaps only one, did.
                        >
                        > cool down Ron!! when I saw no comments on what Cooley said i -mistakenly as appeared- thought that everybody agrees to it. So do you think that some projects require more than 10 programmers? if we have such projects, do we stick to the same face-to-face principle? would it be enough?

                        If I did say any project can be done with 10 people then I disagree
                        with what I said. What I meant is that I do not believe the increase
                        in productivity as you add developers is linear. I believe that as you
                        add developers, you approach a point where adding more will decrease
                        your productivity due to communication overhead. Imagine 1000 people
                        trying to mow a 400 square foot lawn. I may have implied that the
                        number is 10, but I have no idea that the number is 10. I have no idea
                        what the number is. I don't actually have any evidence that the number
                        exists except for thought experiments I've done where I try to image
                        10,000 developers trying to get something done.

                        I guess no one openly disagreed with what I said because everyone has
                        that number in their head. Some think it's 5, others think it's 10.
                        Microsoft thinks they can build an OS with 2500. Whether they can or
                        not is a point of debate. I'll go out on a limb and say everyone on
                        this list has some maximum number of developers he or she thinks is
                        effective.

                        --
                        Curtis Cooley
                        curtis.cooley@...
                        home:http://curtiscooley.com
                        blog:http://ponderingobjectorienteddesign.blogspot.com
                        ===============
                        Leadership is a potent combination of strategy and character. But if
                        you must be without one, be without the strategy.
                        -- H. Norman Schwarzkopf
                      • Adam Sroka
                        ... s/lean/lightweight/
                        Message 11 of 11 , Nov 6, 2009
                        • 0 Attachment
                          On Fri, Nov 6, 2009 at 11:20 AM, Adam Sroka <adam.sroka@...> wrote:
                          >
                          > When XP and other "lean methods" ...

                          s/lean/lightweight/
                        Your message has been successfully submitted and would be delivered to recipients shortly.