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

How does pulling WIP in Kanban relate to source control?

Expand Messages
  • Pieter Nagel
    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
    Message 1 of 50 , Jul 27, 2009
    View Source
    • 0 Attachment
      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
    • 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
      View Source
      • 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
        release:
        " 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.

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