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

RE: [XP] club officers (was "strictly minimal")

Expand Messages
  • Charlie Poole
    Hi Bill, I m saving this one! Charlie Poole cpoole@pooleconsulting.com www.pooleconsulting.com www.charliepoole.org
    Message 1 of 23 , Jan 1, 2004
    • 0 Attachment
      Hi Bill,

      I'm saving this one!

      Charlie Poole
      cpoole@...
      www.pooleconsulting.com
      www.charliepoole.org



      > -----Original Message-----
      > From: William E Caputo [mailto:wecaputo@...]
      > Sent: Thursday, January 01, 2004 11:58 AM
      > To: extremeprogramming@yahoogroups.com
      > Subject: Re: [XP] club officers (was "strictly minimal")
      >
      >
      > Wayne Dawson:
      > >I'm currently reading Extreme Programming Explained, but in the
      > mean time,
      >
      > >which XP practice is the most important one to implement? Ie. which one
      > >should I start using first?
      >
      > Two things I want to note before I answer your question:
      >
      > 1) Many (most?) people start out with XP by themselves, learning it and
      > then trying to apply it.
      >
      > 2) XP is fundamentally a team software methodology. As such, you will not
      > really understand XP until you do it as part of a team of programmers
      > working with a customer (I know I didn't).
      >
      > I introduce these two caveats, not to discourage you, but so that
      > you have
      > the proper expectations of what you can accomplish alone. You can learn a
      > lot of the practices of XP alone, and some of them will be useful to you
      > even if you never work as part of a team -- but you will not really be
      > learning (or practicing) XP.
      >
      > OK, caveats aside, Here's what I feel are the best practices for starting
      > out alone, using Ron's ever-helpful "What is XP?" page for the definition
      > of the practices
      > (found here: http://www.xprogramming.com/xpmag/whatisxp.htm):
      >
      > *Simple Design*
      >
      > For more on this, there are probably hundreds of pages at the c2 wiki,
      > here is a good starting point:
      > http://www.c2.com/cgi/wiki?DoTheSimplestThingThatCouldPossiblyWork)
      >
      > *Test-Driven Development*
      >
      > IMO Kent's book "Test-Driven Development by Example" is the best resource
      > for learning this
      >
      > *Design Improvement*
      >
      > aka Refactoring. Although the definition of TDD includes refactoring, its
      > still valuable to keep it as a separate concept ("TDD" was originally
      > "write tests before writing code", and "design improvement" was
      > "refactor". Since Test, Code, Refactor is the smallest period of work in
      > XP, its natural that these two practices have moved closer together over
      > the last few years). Martin Fowler's book "Refactoring: Improving the
      > Design of Existing Code is practically the canonical source for learning
      > this technique. Please don't confuse Refactoring, with Rewriting. Its an
      > overused buzzword. People here tend to use the term correctly.
      >
      > These three practices are probably enough to get you started. From here,
      > you can really only approximate what XP is like since the other practices
      > all involve interactions with other people (and some like Pairing make no
      > sense when working alone). Probably the most accessible when
      > working alone
      > are the story and planning practices:
      >
      > *Planning Game*
      >
      > Writing and estimating stories even by yourself is often useful,
      > if for no
      > other reason than that the act of doing so is a good way to help you
      > determine the scope of the project you have set yourself. While
      > its also a
      > good way to practice the technique, its *not* a very accurate substitute
      > for having a Customer write the stories, and then having the Programmers
      > estimate them (because the real practice involves two people trying to
      > come to a common understanding). Kent and Martin's book "Planning eXtreme
      > Programming" is a good (if possibly a little dated) place to start. I
      > learned XP planning before that book came out so its the last book I read
      > on the topic. Others may be able to provide other references.
      >
      > *Small Releases*
      >
      > Getting your stuff in front of people who will use it is always the best
      > way to find out what you missed, and to pierce that bubble of
      > self-delusion that we create around our ideas when no one else is
      > involved. Get your stuff "live" as quickly as is practical (when working
      > alone, you could probably release after nearly every work session).
      >
      > *Customer Tests*
      >
      > aka Acceptance Tests, Story Tests, Functional Tests, etc -- are
      > important,
      > but really hard to understand when working alone. The idea is that you
      > should write (and automate) tests that are oriented to your stories and
      > thus demonstrating functionality from the perspective of the Customer
      > (hence the name). They also generally test more end-to-end functionality
      > than TDD tests (nee XP unit tests, or programmer tests). Finally, they
      > (and not the TDD tests!) take on a verification role that you are
      > building
      > the right thing. TDD is a *design* activity; TDD tests play only a
      > secondary role in regression, and nearly nothing in the way of saying we
      > built the right thing (but they do say we built the thing the way we
      > expected to). In short, Customer Tests are really necessary, but you
      > probably won't get them right working alone, so you might want to put off
      > learning this practice until you are comfortable working with the ones
      > listed above. If you do try to write some, I suggest checking out
      > the tool
      > fit (http://fit.c2.com)
      >
      > Hope that helps. That should certainly keep you busy for several months
      > (years?). I still feel like I am learning how to do these six practices,
      > so don't let their apparent simplicity fool you. OTOH, you can get
      > competent/productive with the first three in a couple of weeks, and get
      > working versions of the second three in a similar amount of time,
      > and find
      > yourself with a productive personal process that may be totally
      > satisfactory for you. Regardless, I hope you enjoy the experience.
      >
      > Best,
      > Bill
      >
      > William E. Caputo
      > ThoughtWorks, Inc.
      > http://www.williamcaputo.com
      > --------
      > idia ktesis, koine chresis
      >
      >
      >
      >
      > To Post a message, send it to: extremeprogramming@...
      >
      > To Unsubscribe, send a blank message to:
      > extremeprogramming-unsubscribe@...
      >
      > ad-free courtesy of objectmentor.com
      >
      > Yahoo! Groups Links
      >
      > To visit your group on the web, go to:
      > http://groups.yahoo.com/group/extremeprogramming/
      >
      > To unsubscribe from this group, send an email to:
      > extremeprogramming-unsubscribe@yahoogroups.com
      >
      > Your use of Yahoo! Groups is subject to:
      > http://docs.yahoo.com/info/terms/
      >
      >
    Your message has been successfully submitted and would be delivered to recipients shortly.