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

Re: summary of the discusion

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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.