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

Re: [XP] summary of the disscusion

Expand Messages
  • 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 1 of 11 , Nov 6, 2009
      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 2 of 11 , Nov 6, 2009
        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 3 of 11 , Nov 6, 2009
          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 4 of 11 , Nov 6, 2009
            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 5 of 11 , Nov 6, 2009
              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 6 of 11 , Nov 6, 2009
                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 7 of 11 , Nov 6, 2009
                  > • 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 8 of 11 , Nov 6, 2009
                    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 9 of 11 , Nov 6, 2009
                      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 10 of 11 , Nov 6, 2009
                        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.