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

Re: [XP] How does pulling WIP in Kanban relate to source control?

Expand Messages
  • D. AndrĂ© Dhondt
    Pieter, I m jumping in late but had to add a couple things I didn t see in my scan of the replies: * If your tester is pulling things from a done queue then
    Message 1 of 50 , Aug 4, 2009
    • 0 Attachment

      I'm jumping in late but had to add a couple things I didn't see in my scan
      of the replies:

      * If your tester is pulling things from a "done queue" then are you
      suffering from "throw-it-over-the-wall-syndrome"?
      I get the sense there is a problem that's bugging you that hasn't yet been
      made explicit.

      * We use iteration boundaries to make sure that A and B are synchronized at
      done done; with green lights on our build server we may choose to make a
      release at any point in the week but most often the release is only at the
      end of the iteration. It's true that if a tester wants to verify B during
      the iteration it is contaminated with potentially unfinished changes for
      feature A, but that doesn't normally bother us because test coverage is high
      and regressions are practically nonexistant. However, as Fowler says in
      Refactoring, it's not the size of steps we're taking that's important--it's
      the fact that we know how to take baby steps when there's a problem that's
      important, because it gives us the ability to isolate the problem quickly.
      I think the same principle applies to WIP--it doesn't matter a lot (if you
      have the capacity) to do multiple items in parallel as long as you know how
      to isolate the problems if they arise.

      * I think this isn't written about much because it's not the root problem...
      with CI, high quality, synch points, and latent features, I think that
      parallel dev is not overly complex on a single trunk.

      On Mon, Jul 27, 2009 at 11:13 PM, Pieter Nagel <pieter@...> wrote:

      > There's one thing in Kanban I can't wrap my head around:
      > Suppose somw spare WIP capacity has opened in, say, the testing stage,
      > and so a piece of work has to be "pulled" from the Done queue of the
      > preceding stage. The tester can choose to pull either A or B.
      > To my mind this implies that, before, the tester was sitting atop a
      > source code checkout that did not contain either A or B. And afterwards,
      > she can have a source code checkout that contains either A without B, or
      > B without A, depending on what she decided to pull.
      > How on earth does this work, practically?
      > How does Kanban and pulling WIP etc. map to the day-to-day realities of
      > source code files, source control, etc. etc.?
      > --
      > Pieter Nagel

      D. André Dhondt
      mobile: 001 33 671 034 984

      Support low-cost conferences -- http://agiletour.org/
      Nominate your mentor --

      [Non-text portions of this message have been removed]
    • Perryn Fowler
      As user of git and Kanban I have a strong preference for hiding incomplete features than using feature branches. - We don t do continuous integration because
      Message 50 of 50 , Aug 28, 2009
      • 0 Attachment
        As user of git and Kanban I have a strong preference for 'hiding'
        incomplete features than using feature branches.

        - We don't do continuous integration because subversion makes merging
        hard. We do it because integrating stuff late is hard and risky no
        matter how nice your merge tool is. Developing features on separate
        branches and then merging them when they are done is not CI. git will
        not save you here.

        - Every time I've seen people do feature branches everyone has just
        got confused trying to avoid a huge big bang integration just before
        " OK, so branch B will regularly merge out from branch A until
        A goes live and then start merging out form Master, and C will merge
        out from both A and B, until .. wait what about bug fixes on
        Master?.... Oh dear B is taking longer than we thought - should we
        hold up C?, or maybe we should start merging out to B from C..err..."

        figuring out to "hide" incomplete stuff isn't trivial, but I prefer it
        to the alternative.

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