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

Re: [XP] How do you eat an elephant?

Expand Messages
  • Phlip
    ... 4. How will you make sure that each part of each user story is needed? The answer is to colocate a Customer, and give them the authority to remove every
    Message 1 of 9 , May 1, 2004
      Orhan Kalayci wrote:

      > There is a "big" project (initial estimation: about
      > 40 weeks long
      > with around 20 programmers)
      >
      > Requirements are already documented largely in
      > paper.
      > The schedule is very tide.
      >
      > The system is so large that people cannot believe in
      > that we cannot
      > begin coding before designing all the system. (We
      > cannot afford big
      > refactorings during the project, to minimize this,
      > all the system
      > should be designed at the beginning.)
      >
      > If you think in terms of XP pratices only, it seems
      > a very valid
      > claim saying it is less risky to begin the
      > programming after
      > designing all the system.
      >
      > The question is:
      > 1. Do you think whether XP practices (namely,
      > simple design) can be
      > applied to this project?
      >
      > 2. Do you believe in that Object Oriented Design
      > (OOD) gives XP
      > pratices the power that although the whole system is
      > not designed at
      > the beginning thanks to OOD it is possible to begin
      > small (without
      > designing the whole system but at the same time no
      > anourmous
      > refactoring will be required during the project?
      >
      > 3. How about performing XP without OOD - do you
      > think it is still
      > economic (preferable) compared to waterfall.

      4. How will you make sure that each part of each user
      story is needed?

      The answer is to colocate a Customer, and give them
      the authority to remove every small detail in each
      user story that they figure is not needed. "Scope
      Control".

      This tightens the schedule if it's allowed to ripple
      up. But you don't know if the design concept you are
      planning might support features that deserve to be
      nixed.

      And refactoring is not re-work. It's another way to go
      faster.

      So put them together, and your crew is asking for ways
      to blunt the effect of scope control.

      Eat a baby elephant.

      =====
      Phlip
      http://www.xpsd.org/cgi-bin/wiki?TestFirstUserInterfaces




      __________________________________
      Do you Yahoo!?
      Win a $20,000 Career Makeover at Yahoo! HotJobs
      http://hotjobs.sweepstakes.yahoo.com/careermakeover
    • Jeff Grigg
      ... Yes. Further, there is the very strong possibility that the leadership of the project will be so overwhelmed with the urgency of making fantastic progress
      Message 2 of 9 , May 1, 2004
        > Jeff sayz:
        >> Your remarks up this point all tell me that the project
        >> is doomed. XP can help.

        --- "Laurent Bossavit" <laurent@b...> wrote:
        > I don't understand how you can "help" a project which is
        > doomed. It seems to me that a project which starts out
        > under a veil of self-delusion will inevitably lead to a
        > crisis, no matter how many well-meaning attempts are made
        > to infuse it with some sense of direction.

        Yes. Further, there is the very strong possibility that the
        leadership of the project will be so overwhelmed with the urgency of
        making fantastic progress against the largely unreachable goals that
        they will be completely unable to make significant progress: The
        old, "I don't have time to sharpen my axe; don't you see how many
        trees I have to cut?!?!?!?"


        I'm thinking that on a doomed project, an iterative approach will at
        least produce some usable product. And with the right politics,
        they'll be able to call that a complete success. ;->
      • CORUM, M E [AG/1000]
        First, let me say that there have been many excellent answers on this thread. I d like to add some information. The term big is relative. To me, the 40
        Message 3 of 9 , May 2, 2004
          First, let me say that there have been many excellent answers on this
          thread. I'd like to add some information. The term "big" is relative.
          To me, the 40 weeks doesn't necessarily make the project "big", maybe
          medium. The 20 programmers is also a medium number. For others, both
          of those numbers would be considered tiny if they are used to projects
          with 200 programmers and 3 to 5 years.

          It sounds like you have a concern about Emergent Design verus Big Design
          Up Front. It sounds like you or your colleagues believe more in the
          latter or perhaps have the most experience with the latter. I recently
          made a presentation at a local user group on the subject of Emergent
          Design (or Emergent Architecture). I gave some numbers from the early
          iterations of several projects. If you look at the iterations as projects
          themselves, they would be considered small but several of them are part of
          larger projects that continued for several years. In one case, a COCOMO II
          estimate for the first iteration of a larger projects said that this
          iteration would require 14.5 months to complete with 7 people ramping up to
          12 people at the peak. The project was completed (using XP) in 4.5 months
          (not 14.5 but 4.5) with 6 people.

          In the past, when I had used COCOMO II to compare projects after the fact, it
          had always nailed the timeline down to the week but had over-estimated the
          number of programmers needed by roughly 20%. Based on that, we should have
          used from 5 to 10 people for 14.5 months. The combination of all the XP
          practices that we did contributed to shortening the timeline dramatically and
          to at least holding down the number of people necessary to complete the
          iteration. Emergent Architecture/Design was a big part of that as this
          customer was creating his business process as he was specifying the needs for
          the software. Therefore, there was a large amount of change over time. Some
          requirements went back and forth between options more than three times during
          this period. I really wish I had kept track of the "agility metric" at that
          time but I didn't. I will in the future.

          In one of the early projects I presented on, there were a large number of
          major architectural changes required during the course of the project. One
          example of that is that a complex security scheme was needed. We knew that
          we needed something at the beginning but the customer wanted us to wait until
          they got all the requirements together for security (which included inputs
          from Legal). We got the security requirements 2 months after the project had
          gone into production for the subset of people that had high security and could
          see/do anything. At the beginning, I told the customer it could take a month
          just to code (and re-work) the software to handle the security if we waited
          so long to do it (and another month of testing). This was because the customer
          didn't want to pay for speculatively putting in the hooks for a security framework
          at the beginning because the possibility existed that the security might not be
          needed. The customer couldn't really control when they would get the final
          requirements so we moved on. Based on that estimate, it should have taken well
          over two months (perhaps almost three) to go from receiving the security requirements
          to production delivery. When the requirements came through, we got the job done in
          5 days with a team of 2 people. We used an additional 3 days to fully automate
          acceptance testing. We were being extra careful due to the legal implications.
          The final delivery to production was just under a month from when we received the
          requirements. I consider this to be a very good result and largely due to the
          XP practices.

          That incident, along with many others like it, made me a believer in the concept of
          Emergent Architecture. You won't know for sure until you try it. There is some
          risk involved. This is true whenever you try something new and different.

          One last thing. I think that OO and design skills are very important. XP gave me
          a much deeper understanding of OO and design concepts. The fact that XP has you
          designing in small increments every day means that you are practicing design all the
          time. You get rapid feedback about whether your design is good or bad and you are
          able to fix bad things quickly and get the feedback that it is better.

          Mike Corum

          -----Original Message-----
          >Message: 8
          > Date: Sat, 01 May 2004 12:24:46 -0000
          > From: "Orhan Kalayci" <orhan.kalayci@...>
          >Subject: How do you eat an elephant?
          >
          >Dear all,
          >
          >There is a "big" project (initial estimation: about 40 weeks long
          >with around 20 programmers)
          >
          >Requirements are already documented largely in paper.
          >The schedule is very tide.
          >
          >The system is so large that people cannot believe in that we cannot
          >begin coding before designing all the system. (We cannot afford big
          >refactorings during the project, to minimize this, all the system
          >should be designed at the beginning.)
          >
          >If you think in terms of XP pratices only, it seems a very valid
          >claim saying it is less risky to begin the programming after
          >designing all the system.
          >
          vThe question is:
          >1. Do you think whether XP practices (namely, simple design) can be
          >applied to this project?
          >
          >2. Do you believe in that Object Oriented Design (OOD) gives XP
          >pratices the power that although the whole system is not designed at
          >the beginning thanks to OOD it is possible to begin small (without
          >designing the whole system but at the same time no anourmous
          >refactoring will be required during the project?
          >
          >3. How about performing XP without OOD - do you think it is still
          >economic (preferable) compared to waterfall.
          >
          >Thank you in advance,
          >Orhan Kalayci
        • Ilja Preuss
          ... Why? Didn t you just delay critical feedback? ... What language will you be using? A procedural? Declarative? Functional? Cheers, Ilja
          Message 4 of 9 , May 3, 2004
            Orhan Kalayci wrote:

            > If you think in terms of XP pratices only, it seems a very valid
            > claim saying it is less risky to begin the programming after
            > designing all the system.

            Why? Didn't you just delay critical feedback?

            > 3. How about performing XP without OOD - do you think it is still
            > economic (preferable) compared to waterfall.

            What language will you be using? A procedural? Declarative? Functional?

            Cheers, Ilja
          Your message has been successfully submitted and would be delivered to recipients shortly.