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

[XP] XP and Rocket Guidance

Expand Messages
  • Ron Jeffries
    ... It is. I hardly know how or why I do what I do. Sometimes it works. ;- There _is_ this incredibly expensive Ron Jeffries Coaches Retreat, of course ...
    Message 1 of 1 , May 1 7:54 PM
    • 0 Attachment
      Responding to Ken Boyer (04:57 PM 5/1/2001 -0400):
      >From: "Ron Jeffries" <RonJeffries@...>
      >Sent: Friday, April 27, 2001 3:36 PM
      > > Responding to Ken Boyer (10:03 AM 4/27/2001 -0400):
      > > >OK. Now we're getting somewhere. We can boil this down to a few questions:
      > > >1. Where is the boundary of XP? I.e. how much can you modify it before it
      > > >becomes ~XP?
      > >
      > > However ... every time I coach any team, there's something different about
      > > their situation. There are tweaks always, and sometimes important changes.
      > > I do my best to advise them, and don't worry too much about whether
      > they're
      > > doing XP ... the important thing is to do well.
      >
      >I'm trying to get to these tweaks. What are the axes along which the tweaks
      >are made, or is that why people like you are hired? :-)

      It is. I hardly know how or why I do what I do. Sometimes it works. ;->
      There _is_ this incredibly expensive Ron Jeffries Coaches' Retreat, of
      course ...

      What I mostly do is (a) live XP so I know how it works and feels, and (b)
      get in touch with the forces acting on the project, so that I can (c)
      suggest something that adjusts the balance as delicately as possible. Of
      course I'm constitutionally incapable of making the suggestion delicately,
      even if it's a delicate suggestion ...

      > > >What I'm trying to do, probably like many people, is discern the
      > continuum
      > > >that
      > > >ties the Agile processes together, and that goes from them "up" a
      > little to
      > > >processes which could be used for, say, rocket guidance. If we try to work
      > > >through this, we're dispelling the confusing messages from DeMarco and
      > > >Beck, which don't really tell us anything about evolving or enhancing XP.
      > >
      > > Mostly we don't know that much, and [I think] that what we do know is that
      > > one shouldn't just set off to enhance XP without contact with the pure
      > quill.
      >
      >Well, OK, but one might want to add a few carefully selected areas to
      >enhance specific attributes, such as a little more peer review and
      >requirements management and testing formalities.

      Sure, one might. It's just that, I believe, until you have stripped away
      all the BS and done XP as purely as possible, you can't really _get_ how
      little additional peer review, requirements management, and testing
      formality you really need. (Which may be different from how much you may be
      required to do: see below.)

      > > I keep saying this, and the evidence is that I won't stop: I've done a lot
      > > of software over a lot of years. The XP practices, I believe, put you in
      > > touch with your code, your project, and your colleagues, in a way that
      > I've
      > > not reproducibly experienced in the past. It seems to have all the good
      > > aspects of the "garage shop", without the bad ones.
      >
      >OK, I'm not doubting that, at least not anymore. As someone steeped in
      >the realm of life-critical software, I am viewing XP with one of the most
      >critical gazes of anyone. I see little specks which make it, in its out-of-
      >the-box form, somewhat lacking in direct applicability to my realm. We've
      >touched on these things, and I'm trying to formulate an enhancement
      >which may remain nothing but an intellectual exercise for me. Or, I may
      >ask you to review it for publication in a journal...

      I'd do either, or less or more. One day I would like to be brought in to a
      life-critical project situation (at my usual incredibly high daily rate of
      course) to help with such an effort. I think my angle could be very
      valuable, for this reason:

      Some people (maybe you) fear that on an XP project, you don't know enough
      to be safe. The reverse is true: you know more on an XP project than on a
      project with more reviews, management, and formalities. You know these
      things because you are in touch with the real project.

      It's the difference between building software and reading about building
      software. All of us who really build software know things that no one can
      "get" by reading about it. Well, all of us who really do XP know things
      that no one can "get" through the filter of a heavier process.

      I know there's no reason to believe that. That's why I tell people just to
      do it for a while. If it is going weird, you'll know. But it won't go
      weird, and you'll learn something elemental about what team software
      development really can be, really is, really should be.

      Regards,


      >Kenneth W. Boyer Jr. <><
      >ASQ Certified Software Quality Engineer
      >VASCOR, Inc. - Pittsburgh, PA USA
      >


      Ronald E Jeffries
      http://www.XProgramming.com
      http://www.objectmentor.com
    Your message has been successfully submitted and would be delivered to recipients shortly.