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

[XP] Re: How do you eat an elephant? (XP on a large project)

Expand Messages
  • 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 1 of 9 , May 1 4:04 PM
    • 0 Attachment
      > 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 2 of 9 , May 2 1:06 PM
      • 0 Attachment
        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 3 of 9 , May 3 4:30 AM
        • 0 Attachment
          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.