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

Re: [XP] Experiment on size of unit of work - how low can you go?

Expand Messages
  • Charlie Poole
    ... might imagine. Even centralized VCSs used to let you do that - although with much more work - by use of what some call promotion. ... Yes, I definitely
    Message 1 of 10 , Jan 10, 2013
      On Thu, Jan 10, 2013 at 1:29 PM, John Carter <john.carter@...> wrote:

      > **
      > On Fri, Jan 11, 2013 at 5:49 AM, Charlie Poole charliepoole@...>
      > wrote:
      > > As you go smaller and smaller, don't you reach the point where it's no
      > > longer a story? That is, no longer viewed as having value by the
      > > customer?
      > >snip<
      > >
      > > But we can't just go ahead and make that judgement
      > > ourselves - it's a key insight of XP that the Customer is the definer of
      > > value and I wouldn't want to forget that.
      > It's one of the many blessings of distributed version control systems...
      > you suddenly realize there is no real coupling between committing a
      > changeset and publishing your work to the rest of the team as "fit for
      > consumption".
      > Indeed, although that notion isn't as strongly coupled to DVCSs as one
      might imagine. Even centralized VCSs used to let you do that - although
      with much more work - by use of what some call "promotion."

      > So as soon as you realize that... you start committing all the time.
      > Every single time the write test / test fail / write code / test pass cycle
      > goes green.
      > Commit.
      Yes, I definitely do that locally. Makes it much easier to go back than
      pushing ctrl-Z 500 times.

      > The point about version control systems is they make you brave about
      > changing things. (Because you always know _exactly_ what you changed, and
      > you can always revert it if it was A Bad Idea.)
      > Before distributed version control, I used to advocate just deleting your
      Braveness in deleting code is an important value for agile programmers.
      Version control gives you a better way to keep track of how far back you
      need to erase.

      > Having got that insight... you suddenly start wondering what else you can
      > decouple.
      > Yup, as soon as I "push", I have declared my changes as "fit for
      > consumption by the rest of the team".
      > Pre-XP, I worked on a project where the first level of commit meant the
      code was good for me, the next level meant it was good for the team and
      the third that it could be used by testing. When we introduced XP, the
      third level became "for the customer." I've never heard anyone else
      enunciate this distinction before! (BTW, we did this using Visual
      probably the worst VCS ever written!)

      > But I haven't declared it fit for consumption by my customer.
      > So what if I shift my "done done" point forward and decoupled that from
      > "showing it to the customer".
      > ie. The point where it is all Tested, documented, review(ed or
      > reviewable...preferably pair programmed, or if I can't do that... the diff
      > in a web base
      > collaboration tool http://www.reviewboard.org/), integrated, smoke tested,
      > pushed to central repository.
      > Sort of makes sense really... 90% of what I do to get anything to the "done
      > done" point is not really understandable by a customer. It's only when I
      > tie a whole bunch of stuff together with a vast bunch of existing stuff
      > that the customer goes "Oh cool, I needed that!".
      > I want the customer feedback ASAP... but I need (and can get) the feedback
      > from the build system, smoke test suite, other developers even faster.
      > If every changeset I push is so small "there is obviously nothing wrong
      > with it" I will be in a better state than if the answer is "there is
      > nothing obviously wrong with it".
      > The aim of the experiment is to find out whether it is feasible to decouple
      > "done done" from "get customer feedback", and what are the costs and
      > benefits.
      > I agree with you... anything that would decreasing the feedback from a
      > customer would be A Bad Thing.
      > Yes, that could be a potential cost of this approach. But not necessarily,
      I think.

      > How ever, sprint overruns happen sometimes... Priorities change. Shit
      > happens both internally and externally. Wouldn't I be in a better state if
      > I could point to a pile of "this stuff is done and dusted and I can go on
      > to other things if you really want and come back to it later, and this
      > other stuff isn't done at all." than sitting with a mouthful of teeth
      > mumbling... "Well, it's not done done yet".
      > The view of Scrum I'm starting to take is this.... "A Story is a Unit of
      > Bidding (amongst competing customer interests and values) for the Team's
      > attention."
      > I don't want to over-generalize, but in my own experience, Scrum teams
      (that I've worked on) were a bit more removed from the customer than
      XP teams. It wasn't as easy to push the notion of customer value lower,
      by spltting stories, so more attention was paid to (what we used to call)
      tasks. Others may have had different experience, of course.

      There is a further level beyond "ready for the customer" and that's
      "ready for release." Just because the customer has learned to see value
      in some piece of work that's accomplished does not necessarily mean
      that the work can be released yet - some minimum level of incremental
      value may be needed first or some other stories may need to be completed
      before we reach a "minimal releasable feature."



      > --
      > John Carter Phone : (64)(3) 358 6639
      > Tait Electronics Fax : (64)(3) 359 4632
      > PO Box 1645 Christchurch Email : john.carter@...
      > New Zealand
      > --
      > ------------------------------
      > This email, including any attachments, is only for the intended recipient.
      > It is subject to copyright, is confidential and may be the subject of
      > legal
      > or other privilege, none of which is waived or lost by reason of this
      > transmission.
      > If you are not an intended recipient, you may not use, disseminate,
      > distribute or reproduce such email, any attachments, or any part thereof.
      > If you have received a message in error, please notify the sender
      > immediately and erase all copies of the message and any attachments.
      > Unfortunately, we cannot warrant that the email has not been altered or
      > corrupted during transmission nor can we guarantee that any email or any
      > attachments are free from computer viruses or other conditions which may
      > damage or interfere with recipient data, hardware or software. The
      > recipient relies upon its own procedures and assumes all risk of use and
      > of
      > opening any attachments.
      > ------------------------------
      > [Non-text portions of this message have been removed]

      [Non-text portions of this message have been removed]
    Your message has been successfully submitted and would be delivered to recipients shortly.