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

Re: [XP] How to accomodate Agile Process and an Alpha-Beta based Process ?

Expand Messages
  • Laurent Bossavit
    Hi Thierry, ... Who are they that you are referring to above ? The customers ? ... Here too, which they are you referring to ? Are you talking about the
    Message 1 of 7 , Oct 1, 2007
    • 0 Attachment
      Hi Thierry,

      > - all iterations will be delivered before Alpha (they expect it)

      Who are "they" that you are referring to above ? The customers ?

      > - bugs will be detected by QA at the end of iteration I and fixed
      > at the beginning of iteration I+1. If the answer is yes, they find
      > challenging to keep the pace of iterations while fixing bugs...

      Here too, which "they" are you referring to ? Are you talking about
      the developers ?

      Here is an argument you may want to explore in discussion with the
      people who "push back" when you suggest agile approaches, depending
      on how technical they are. It seems that the earlier you detect a
      bug, the less it costs to fix that bug.

      So, the usual approach, where we let all the bugs accumulate until
      the "feature complete" Alpha version, tends to be very, very costly.
      Did you find that the testing phases in your project plans never
      seemed enough to find all the bugs, and seemed to always take longer
      than planned ?

      Agile processes in general and Extreme Programming in particular
      suggests doing differently. Find the bugs early, by testing early. If
      you detect a bugs just a minute after you wrote it, it will be very
      cheap to fix. (That's what you get by using Test-Driven Development.)
      If you detect a bug less than two weeks after you wrote it, it will
      still be relatively cheap to fix. (So "ship" a version to the QA
      people, or even better to someone who can use it like the end users
      will use it, every iteration.)

      The more you wait, the more each bug infects the rest of your
      product. The best time to fix a bug is right when you detect it, and
      the best time to detect is is just after you write it... Or even
      better, just before.

      I'd like to stress that this is an idea to explore in discussion.
      Simply ask people "Have you thought of bugs that way before ? If not,
      do you think it makes sense to think of bugs that way ?" Encourage
      people to think of this as a hypothesis that could be confirmed or
      disconfirmed by experiment. Ask people what kind of experiment they
      might try to find the truth of the matter.

      You can worry about "convincing" them later. Explore first.

      Laurent Bossavit
      laurent@...
    • William Pietri
      ... Hi, Thierry. You ve got some interesting answers. I can give you another one, although it s not one I personally recommend. Consider this notion: all plans
      Message 2 of 7 , Oct 1, 2007
      • 0 Attachment
        thierry_cattel wrote:
        > Has someone convincing arguments or approach to accomodate both views
        > so that they dont seem antagonistic ? or so that agile is accepted
        > inside a classical one ?
        >

        Hi, Thierry. You've got some interesting answers. I can give you another
        one, although it's not one I personally recommend.

        Consider this notion: all plans are lies.

        In some sense, this is obviously true. If we're doing anything
        interesting, we can't really know the future. Suppose I say that I will
        deliver these 153 features at 10:32 am on July 11, 2009. I can't really
        know that. However, that's the sort of answer that people want to hear,
        and so that's the sort of answer they often get.

        A lot of times, the people doing the lying aren't consciously doing it.
        They might build a complex plan with lots of Gantt charts and UML
        diagrams to completely obscure the fact that they are passing guesses
        off as fact. They generally do this not out of malice, but because
        people keep demanding the appearance of certainty. So they fool
        themselves as well as everybody else.

        One solution is to make a plan, just like people want. In color, even.
        Then you mainly ignore that and start out doing your agile thing.

        When your alpha date comes around, you release what you have. Sure, you
        might have to do some song-and-dance routine about how things changed
        and you had to cut some low-priority features. Which people are used to,
        because that's what waterfall projects do. But you made your date, and
        you can take that chance to get more input on what you should build
        between "alpha" and "final release".


        That's probably the easiest way to mate an agile development process
        with waterfall-driven expectations. I've seen people do it and it works.
        But personally, I prefer the more honest approach.


        Hoping that helps,

        William




        --
        William Pietri - william@... - +1-415-643-1024
        Agile consulting, coaching, and development: http://www.scissor.com/
        Use your geek-fu to fight poverty: http://www.mifos.org/
      • Phlip
        ... Game development, for one, can turn that sideways. Games are super-complex programs that must be manually tested, both to inspect new art ( assets ) and to
        Message 3 of 7 , Oct 1, 2007
        • 0 Attachment
          > - Alpha Milestone : product feature complete with plenty of bugs...
          > - Beta Milestone : Alpha + no major bugs
          > - Release Candidate : Beta + only minor bugs
          > - Gold Master : RC + ready to ship

          Game development, for one, can turn that sideways. Games are
          super-complex programs that must be manually tested, both to inspect
          new art ("assets") and to continuously ensure a game is fun.

          In a game, you deploy daily to create an alpha, and testing starts
          here. When a given version of the game (or a level within a game)
          passes its alpha testing it is "blessed". This version now moves to
          "beta", for user-community testing. If it passes that it's "blessed"
          again, becoming a releasable.

          So these are orthogonal to milestones. An Agile project is always
          releasable. The blessing system is a pipeline leading away from the
          development arena.

          But I agree with other posters that the original poster has many more
          impediments to agility than just their release system!

          --
          Phlip
          http://www.oreilly.com/catalog/9780596510657/
          ^ assert_xpath
        Your message has been successfully submitted and would be delivered to recipients shortly.