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

We have a couple of Developer and tester positions open and are looking for ones that have strong XP experience

Expand Messages
  • Mammone, Colleen
    Hi, I m hoping you guys can steer me in the right direction. I work for LANDesk Software in Salt Lake City Utah, and we have a couple of Software developer
    Message 1 of 1 , Feb 25, 2003
      Hi,
      I'm hoping you guys can steer me in the right direction.
      I work for LANDesk Software in Salt Lake City Utah, and we have a couple
      of Software developer positions we are trying to fill.
      We have gone the conventional recruiting route and seem to be coming up
      a bit short on what we would like in the next candidate(s) we hire.
      Of course we want developers with strong object oriented programming
      skills (preferably C# or C++), but we are also looking for motivated,
      positive, teamplayers. Someone who will come in and immediately
      contribute not only to our efforts to implement the XP principles, but
      also to the quality of the code we are producing.
      We also have a couple of postitions for Testers with very strong test
      automation skills, along with the XP and team oriented skills as well.

      My question to this group is, where is the best place for me to look for
      these people? Monster.com, typical software development recruiters, and
      word of mouth have not produced the caliber of person we are hoping for.

      Any suggestions would be greatly appreciated.
      Thanks

      Colleen Mammone
      LDMS Engineering Project Manager
      (801) 369-2003 Cell




      -----Original Message-----
      From: extremeprogramming@yahoogroups.com
      [mailto:extremeprogramming@yahoogroups.com]
      Sent: Tuesday, February 25, 2003 11:29 AM
      To: extremeprogramming@yahoogroups.com
      Subject: [XP] Digest Number 3151

      To Post a message, send it to: extremeprogramming@...

      To Unsubscribe, send a blank message to:
      extremeprogramming-unsubscribe@...

      ad-free courtesy of objectmentor.com
      ------------------------------------------------------------------------

      There are 25 messages in this issue.

      Topics in this digest:

      1. Re: Velocity & Yesterday's weather
      From: wecaputo@...
      2. Development steering
      From: Ralph Johnson <johnson@...>
      3. Re: XP Stories and UML Use Cases
      From: Piergiuliano Bossi <P.Bossi@...>
      4. Re: Re: How to write stories for bugs?
      From: Ron Jeffries <ronjeffries@...>
      5. Re: Writing User Stories
      From: Nicholas Robinson <nicholasrobinson@...>
      6. New file uploaded to extremeprogramming
      From: extremeprogramming
      7. Re: Writing User Stories
      From: Steve Berczuk <berczuk@...>
      8. Re: Writing User Stories
      From: "Jeff Nielsen" <jeff.nielsen@...>
      9. Re: How to write stories for bugs? (and mice ;-)
      From: "jeffgrigg63132 <jgrigg@...>" <jgrigg@...>
      10. SPAM: New file uploaded to extremeprogramming on 2/25 -- exam
      cert. products
      From: "jeffgrigg63132 <jgrigg@...>" <jgrigg@...>
      11. Re: Writing User Stories
      From: Ron Jeffries <ronjeffries@...>
      12. Re: Re: How to write stories for bugs? (and mice ;-)
      From: Ron Jeffries <ronjeffries@...>
      13. RE: Re: How to write stories for bugs?
      From: "Van Hamersveld, Mark" <mvanhame@...>
      14. RE: Velocity & Yesterday's weather
      From: "Dubbs, Roger" <rdubbs@...>
      15. RE: Re: How to write stories for bugs?
      From: "Tim Moore" <tmoore@...>
      16. RE: Re: How to write stories for bugs?
      From: "Tom Copeland" <tom@...>
      17. RE: Re: How to write stories for bugs?
      From: "Tim Moore" <tmoore@...>
      18. Re: Re: How to write stories for bugs?
      From: "David Putman \(DavidPutman.com\)"
      <davidputman@...>
      19. Re: Re: How to write stories for bugs?
      From: Edmund Schweppe <schweppe@...>
      20. RE: Re: How to write stories for bugs?
      From: "Van Hamersveld, Mark" <mvanhame@...>
      21. Re: Re: How to write stories for bugs?
      From: Brad Appleton <brad@...>
      22. Re: Velocity & Yesterday's weather
      From: "Kiel Hodges <kielhodges@...>"
      <kielhodges@...>
      23. RE: Writing User Stories
      From: "Dan Rawsthorne" <DrDan@...>
      24. Re: How to write stories for bugs?
      From: "Kiel Hodges <kielhodges@...>"
      <kielhodges@...>
      25. RE: Re: How to write stories for bugs?
      From: wecaputo@...


      ________________________________________________________________________
      ________________________________________________________________________

      Message: 1
      Date: Tue, 25 Feb 2003 00:47:09 -0500
      From: wecaputo@...
      Subject: Re: Velocity & Yesterday's weather


      Ryan:
      >The statistical number crunching of previous iterations can provide a
      good
      >base line, but I dont think you can ever beat having the developers sit
      >down, evaluate the tasks, and give an estimate of what can be done in a
      >given iteration...

      As I mentioned in another post in this thread, Yesterday's Weather (YW)
      is
      only one part of XP's adaptive planning approach. Two other important
      factors are estimates being adjusted regularly based on what we learn
      doing
      stories, and good old common sense. YW isn't a rule, its a tool -- one
      of
      many that XP teams use. We get good at doing it via practice and
      refinement, just like all tools. I use a lot of tools to do my job, if
      they
      aren't helping me, I change them, adjust them, or discard them as suits
      my
      needs.

      My suggestion to others is that they use the tools of XP the same way --
      not as blind rules, or rough hammers that will somehow make all of our
      problems go away, but as tools that we might get some good use out of if
      we
      practice with them, and try to learn how people are using them. That's
      one
      reason I listen here: to see what others are learning about the XP
      toolbox
      from repeated use.

      Best,
      Bill





      ________________________________________________________________________
      ________________________________________________________________________

      Message: 2
      Date: Tue, 25 Feb 2003 00:47:19 -0600 (CST)
      From: Ralph Johnson <johnson@...>
      Subject: Development steering

      An earlier message expressed a worry that if development pointed
      out potential problems, they might end up steering the project.

      I had a guy build a shed in my back yard. I had bought a
      "shed kit" and decided to spend a few hundred dollars to
      have someone else put it together, and was glad I did.
      This was about shed 1000 for him. He told me that in the
      winter, heavy snow would make the sides bow out, but he
      could put in a cross-brace to keep it from happening.
      He also said that door had a tendency to swing loose, and
      that he could put a crude latch on it to keep that from
      happening. I was glad to pay a little extra for those
      things, but would have been annoyed if he had just gone
      ahead and done them.

      I like car mechanics who look around and notice things and
      ask me if I want them to work on them. I hate car mechanics
      who fix lots of things and then bill me without any warning.

      The customer must steer, but a good developer will not
      hesitate to point out potential problems and suggest better
      ways of doing things. Communication is vital!

      -Ralph Johnson



      ________________________________________________________________________
      ________________________________________________________________________

      Message: 3
      Date: Mon, 24 Feb 2003 22:47:06 +0100
      From: Piergiuliano Bossi <P.Bossi@...>
      Subject: Re: XP Stories and UML Use Cases

      Yaron,

      attachments are stripped away. You can try to explain yourself a
      little-bit more or
      upload the file somewhere.

      Ciao, Giuliano

      PS: my wife loves Kinder eggs, I personally prefer Nutella much more
      even if there are no surprises at all... :-)

      Rosenbaum Yaron wrote:

      > Ok, let me try to explain myself.
      >
      > Take a look at the excel I attached.
      > It's just a user story, with more details. It's an engineering task,
      and a
      > story, and a sequence diagram.
      > It's almost like a Kinder egg. :-)
      >
      > Yaron Rosenbaum
      > Chief Software Engineer
      > CAP Project
      > Comverse
      >
      > +972-3-7663411
      > yaronr@...
      >
      > -----Original Message-----
      > From: Piergiuliano Bossi [mailto:P.Bossi@...]
      > Sent: Friday, February 21, 2003 12:43 AM
      > To: extremeprogramming@yahoogroups.com
      > Subject: Re: [XP] XP Stories and UML Use Cases
      >
      > Rosenbaum Yaron wrote:
      >
      > > Stories are imprecise, and hard to track over time.
      >
      > I guess that I'm not saying anything really original if I tell you
      that:
      > *) yes, sometimes stories are imprecise, but acceptance tests normally
      are
      > really precise
      > *) it is really easy to track stories over time, we did it down to a
      > precision of 30' actual work and I know several teams that did it
      > successfully too
      >
      > Or did you mean to say that is hard to track their **changes** over
      time?
      >
      > Yes, that is hard, but splitting is a useful tool and tracking a split
      is
      > not difficult. Is this the aspect that you need to track it? If so,
      why?
      >
      > Ciao,
      > Giuliano
      >
      > To Post a message, send it to: extremeprogramming@...
      >
      > To Unsubscribe, send a blank message to:
      > extremeprogramming-unsubscribe@...
      >
      > ad-free courtesy of objectmentor.com
      >
      > Your use of Yahoo! Groups is subject to
      http://docs.yahoo.com/info/terms/
      >
      > [Non-text portions of this message have been removed]
      >
      > To Post a message, send it to: extremeprogramming@...
      >
      > To Unsubscribe, send a blank message to:
      extremeprogramming-unsubscribe@...
      >
      > ad-free courtesy of objectmentor.com
      >
      > Your use of Yahoo! Groups is subject to
      http://docs.yahoo.com/info/terms/




      ________________________________________________________________________
      ________________________________________________________________________

      Message: 4
      Date: Tue, 25 Feb 2003 02:46:59 -0500
      From: Ron Jeffries <ronjeffries@...>
      Subject: Re: Re: How to write stories for bugs?

      On Monday, February 24, 2003, at 10:37:15 PM, Edmund Schweppe wrote:

      > Ron Jeffries wrote:
      >> On Monday, February 24, 2003, at 6:29:46 PM, Edmund Schweppe wrote:
      >> > Regardless of the client's level of knowledge, the memory leak is
      still
      >> > a defect. For a particular application, the Customer may not care -
      or
      >> > may care more about other defects - but it's still a defect.
      >> Yes. And if it is, then there needs to be a customer test that shows
      that
      >> there is no such defect. The customer job isn't done until there are
      tests
      >> for everything important.

      > Is it still a defect if the Customer doesn't think it's important
      enough
      > to have a test and get it fixed? I think so - an unimportant defect,
      but
      > a defect none the less. Of course, other folks' mileage may vary.

      Sure. And still it needs to go through the customer, because (in XP)
      only
      the customer can decide.

      Ron Jeffries
      www.XProgramming.com
      It's easier to act your way into a new way of thinking
      than to think your way into a new way of acting. --Millard Fuller



      ________________________________________________________________________
      ________________________________________________________________________

      Message: 5
      Date: Tue, 25 Feb 2003 08:14:23 +0000 (GMT)
      From: Nicholas Robinson <nicholasrobinson@...>
      Subject: Re: Writing User Stories

      Hi Jeff,

      Thanks for that. When we think of use cases, we sit down and consider
      what the goals of the user
      is. He wants to make a payment, make an order, track an order. Is this
      the same granularity as
      the user story, but in a less formal format? Is a story broken down into
      task cards? I need to
      re-read some of the Kent Beck stuff, but any practical guidance is most
      appreciated.

      Regards

      Nick.
      --- Jeff Nielsen <jeff.nielsen@...> wrote: > From the
      green book (Planning XP):
      >
      > "A user story is a chunk of functionality that is of value to the
      customer."
      >
      > It provides a simple way for developers and customers to partition
      what the
      > system needs to do so that it can be delivered in pieces.
      > A story must be:
      >
      > 1.1. Understandable to customer/developer
      > 2.2. Testable
      > 3. 3.Valuable to the customer
      > 4. Small enough to build a few each iteration
      > -
      >
      > These four criteria have helped me keep people on track who are new to
      > deciding "what is a story".
      >
      > Jeff Nielsen
      > Digital Focus (www.digitalfocus.com)
      >
      > ----- Original Message -----
      > From: <nicholasrobinson@...>
      > To: <extremeprogramming@yahoogroups.com>
      > Sent: Monday, February 24, 2003 10:58 AM
      > Subject: [XP] Writing User Stories
      >
      >
      > > Hi,
      > >
      > > I have two books on XP, and both dont seem to explain fully what a
      > > User Story is. Can someone either explain to me, as if I know only
      > > of Use Cases, or maybe point me to a link? I need to swot up on them
      > > because on Wednesday the XP Workshop I am in is gonig to start
      > > producing the requirements for the two projects we have decided to
      > > build applying XP. Nobody as yet, knows 100% how to write User
      > > Stories or how to plan, so any pointers to any good online resources
      > > would be most welcome.
      > >
      > > Thanks,
      > >
      > > Nick.
      > >
      > >
      > >
      > > To Post a message, send it to: extremeprogramming@...
      > >
      > > To Unsubscribe, send a blank message to:
      > extremeprogramming-unsubscribe@...
      > >
      > > ad-free courtesy of objectmentor.com
      > >
      > > Your use of Yahoo! Groups is subject to
      http://docs.yahoo.com/info/terms/
      > >
      > >
      >
      >
      > To Post a message, send it to: extremeprogramming@...
      >
      > To Unsubscribe, send a blank message to:
      extremeprogramming-unsubscribe@...
      >
      > ad-free courtesy of objectmentor.com
      >
      > Your use of Yahoo! Groups is subject to
      http://docs.yahoo.com/info/terms/
      >
      >

      __________________________________________________
      Do You Yahoo!?
      Everything you'll ever need on one web page
      from News and Sport to Email and Music Charts
      http://uk.my.yahoo.com


      ________________________________________________________________________
      ________________________________________________________________________

      Message: 6
      Date: 25 Feb 2003 09:05:16 -0000
      From: extremeprogramming
      Subject: New file uploaded to extremeprogramming


      Hello,

      This email message is a notification to let you know that
      a file has been uploaded to the Files area of the extremeprogramming
      group.

      File : /000000000_www_passiteasy_com_usd10_all
      _IT_Exam_Certs.txt
      Uploaded by : passiteasy_com4 <passiteasy_com4@...>
      Description : RE: www.passiteasy.com usd$10 all IT Exam Certs

      You can access this file at the URL

      http://groups.yahoo.com/group/extremeprogramming/files/000000000_www_pas
      siteasy_com_usd10_all%20_IT_Exam_Certs.txt

      To learn more about file sharing for your group, please visit

      http://help.yahoo.com/help/us/groups/files

      Regards,

      passiteasy_com4 <passiteasy_com4@...>







      ________________________________________________________________________
      ________________________________________________________________________

      Message: 7
      Date: Tue, 25 Feb 2003 08:39:15 -0500
      From: Steve Berczuk <berczuk@...>
      Subject: Re: Writing User Stories

      Nicholas Robinson wrote:
      > Thanks for that. When we think of use cases, we sit down and consider
      what the goals of the user
      > is. He wants to make a payment, make an order, track an order. Is
      this the same granularity as
      > the user story, but in a less formal format? Is a story broken down
      into task cards? I need to
      > re-read some of the Kent Beck stuff, but any practical guidance is
      most appreciated.

      My thinking about this is that the goal is to communicate with the
      customer about what they want the system to do. I get frustrated when a
      group spends a lot of time arguing about what is/is not a {story, use
      case, scenario, (the word someone else proposed earlier in this
      thread)}. The real question is "do you understand what to build?"
      Stories (in the sense of XP, or in the sense of "once upon a time") are
      good because they are concepts that a customer should be able to
      understand.

      Admittedly, at some point you (the developer) may want to work with the
      customer to refine the story so that you can build it, but the key
      things are that a story:
      - maps to something that you can schedule in an iteration
      - is testable
      - (maybe one or two more things)

      Depending on your customer, you may have more details. I suspect that if

      your customer is someone who is using APIs for a library you are
      writing, your story may be more like a use case. If your customer is a
      baker (to pick an example from a recent post) it will be more narrative.

      This is based on my experience.... YMMV.

      -Steve


      --
      Steve Berczuk | steve@... | http://www.berczuk.com
      SCM Patterns: Effective Teamwork, Practical Integration
      www.scmpatterns.com




      ________________________________________________________________________
      ________________________________________________________________________

      Message: 8
      Date: Tue, 25 Feb 2003 08:26:08 -0500
      From: "Jeff Nielsen" <jeff.nielsen@...>
      Subject: Re: Writing User Stories

      From: "Nicholas Robinson" wrote

      > Thanks for that. When we think of use cases, we sit down and consider
      what the goals of the user
      > is. He wants to make a payment, make an order, track an order. Is
      this
      the same granularity as
      > the user story, but in a less formal format? Is a story broken down
      into
      task cards? I need to
      > re-read some of the Kent Beck stuff, but any practical guidance is
      most
      appreciated.

      The stories are expressed in language that the customer can understand.
      Another word for story is "feature". The stories are used for
      high-level
      planning (i.e., deciding what gets built each iteration, understanding
      how
      long it will take until enough features are implemented to release).

      When it comes time to build each story, the developers get the detailed
      requirements from the customer (preferably in the form of acceptance
      test
      cases), and break it down into technical tasks. The tasks are all of
      the
      things that the developers need to do to implement the story. Tasks are
      used for detail-level planning.

      You *really* need to read the green book, especially if you're going to
      try
      to do XP-style project management.

      Jeff


      > --- Jeff Nielsen <jeff.nielsen@...> wrote: > From the
      green
      book (Planning XP):
      > >
      > > "A user story is a chunk of functionality that is of value to the
      customer."
      > >
      > > It provides a simple way for developers and customers to partition
      what
      the
      > > system needs to do so that it can be delivered in pieces.
      > > A story must be:
      > >
      > > 1.1. Understandable to customer/developer
      > > 2.2. Testable
      > > 3. 3.Valuable to the customer
      > > 4. Small enough to build a few each iteration
      > > -
      > >
      > > These four criteria have helped me keep people on track who are new
      to
      > > deciding "what is a story".
      > >
      > > Jeff Nielsen
      > > Digital Focus (www.digitalfocus.com)
      > >
      > > ----- Original Message -----
      > > From: <nicholasrobinson@...>
      > > To: <extremeprogramming@yahoogroups.com>
      > > Sent: Monday, February 24, 2003 10:58 AM
      > > Subject: [XP] Writing User Stories
      > >
      > >
      > > > Hi,
      > > >
      > > > I have two books on XP, and both dont seem to explain fully what a
      > > > User Story is. Can someone either explain to me, as if I know
      only
      > > > of Use Cases, or maybe point me to a link? I need to swot up on
      them
      > > > because on Wednesday the XP Workshop I am in is gonig to start
      > > > producing the requirements for the two projects we have decided to
      > > > build applying XP. Nobody as yet, knows 100% how to write User
      > > > Stories or how to plan, so any pointers to any good online
      resources
      > > > would be most welcome.
      > > >
      > > > Thanks,
      > > >
      > > > Nick.
      > > >
      > > >
      > > >
      > > > To Post a message, send it to: extremeprogramming@...
      > > >
      > > > To Unsubscribe, send a blank message to:
      > > extremeprogramming-unsubscribe@...
      > > >
      > > > ad-free courtesy of objectmentor.com
      > > >
      > > > Your use of Yahoo! Groups is subject to
      http://docs.yahoo.com/info/terms/
      > > >
      > > >
      > >
      > >
      > > To Post a message, send it to: extremeprogramming@...
      > >
      > > To Unsubscribe, send a blank message to:
      extremeprogramming-unsubscribe@...
      > >
      > > ad-free courtesy of objectmentor.com
      > >
      > > Your use of Yahoo! Groups is subject to
      http://docs.yahoo.com/info/terms/
      > >
      > >
      >
      > __________________________________________________
      > Do You Yahoo!?
      > Everything you'll ever need on one web page
      > from News and Sport to Email and Music Charts
      > http://uk.my.yahoo.com
      >
      > To Post a message, send it to: extremeprogramming@...
      >
      > To Unsubscribe, send a blank message to:
      extremeprogramming-unsubscribe@...
      >
      > ad-free courtesy of objectmentor.com
      >
      > Your use of Yahoo! Groups is subject to
      http://docs.yahoo.com/info/terms/
      >
      >



      ________________________________________________________________________
      ________________________________________________________________________

      Message: 9
      Date: Tue, 25 Feb 2003 13:47:49 -0000
      From: "jeffgrigg63132 <jgrigg@...>" <jgrigg@...>
      Subject: Re: How to write stories for bugs? (and mice ;-)

      > Edmund Schweppe wrote:
      >> If the Customer is sufficiently technically savvy, they'll
      >> know to ask about memory leaks; if not, [...]

      Or they'll quite rationally assume that the programmers are
      technically savvy enough to know that memory leaks are a bad thing,
      and should be avoided.

      >> Regardless of the client's level of knowledge, the memory
      >> leak is still a defect. For a particular application, the
      >> Customer may not care - or may care more about other
      >> defects - but it's still a defect.

      --- Ron Jeffries <ronjeffries@a...> wrote:
      > [...] And I certainly think that memory leaks are a defect and
      > usually an important one.

      A memory leak is a defect. It's a waste of resources and a violation
      of standards. But the priority of fixing it, relative to other
      business needs *IS* open to interpretation.

      I wrote a small C++ program some years ago that leaked memory quite
      profusely. This was intentional: It was a quick and dirty prototype
      used to demonstrate that certain kinds of expression parsing could be
      done. The production code would be written in PL/I, with no memory
      leaks.

      For a long running program, typically a service on a server, memory
      leaks can be a big problem. For a program that runs and exits, the
      most effective way to free memory can be to exit the program,
      terminating the process. I'm serious. It's true.

      The decision as to when The Customer's time and money should be spent
      to improve the efficiency with which the program uses system
      resources is The Customer's. Let's allow the customer to make
      business decisions regarding their investment.





      > Edmund Schweppe wrote:
      >> [1] I remember one project in particular that I worked on,
      >> where the end users were grocery store bakery managers.
      >> During our first design session, one of them pointed to the
      >> mouse and asked me what that white thing was.

      I remember, in the late 1980's, when a top level manager of a major
      international computer company asked about the "rat" on the Sun
      workstation we were using in a demo. He had forgotten that we
      referred to that little rodent as a "mouse." ;->



      ________________________________________________________________________
      ________________________________________________________________________

      Message: 10
      Date: Tue, 25 Feb 2003 13:51:51 -0000
      From: "jeffgrigg63132 <jgrigg@...>" <jgrigg@...>
      Subject: SPAM: New file uploaded to extremeprogramming on 2/25 -- exam
      cert. products

      SPAM:

      > File : /000000000_www_passiteasy_com_usd10_all
      _IT_Exam_Certs.txt
      > Uploaded by : passiteasy_com4 <passiteasy_com4@y...>
      > Description : RE: www.passiteasy.com usd$10 all IT Exam Certs
      >
      > You can access this file at the URL
      >
      http://groups.yahoo.com/group/extremeprogramming/files/000000000_www_p
      assiteasy_com_usd10_all%20_IT_Exam_Certs.txt




      ________________________________________________________________________
      ________________________________________________________________________

      Message: 11
      Date: Tue, 25 Feb 2003 09:04:19 -0500
      From: Ron Jeffries <ronjeffries@...>
      Subject: Re: Writing User Stories

      On Tuesday, February 25, 2003, at 3:14:23 AM, Nicholas Robinson wrote:

      > Thanks for that. When we think of use cases, we sit down and consider
      what the goals of the user
      > is. He wants to make a payment, make an order, track an order. Is
      this the same granularity as
      > the user story, but in a less formal format? Is a story broken down
      into task cards? I need to
      > re-read some of the Kent Beck stuff, but any practical guidance is
      most appreciated.

      Card, Conversation, Confirmation:

      +-Card------------+
      | Make a Payment. |
      +-----------------+

      Conversation:

      Customer: (Showing above story card.) We need to make a payment.
      Programmer: (Grabbing blank cards for notes.) OK, what's that mean?
      C: The user has an account balance.
      P: Yes.
      C: The user has a credit card and wants to use it to pay some of the
      balance.
      P: Can he pay it some other way?
      C: Later on we will accept direct bank transfers.
      P: Maybe we should call this story "Make a Payment with Credit Card",
      but that's up to you.
      C: OK, let's do that. (scribbles on card)
      So anyway, we want to get the customer's credit card number,
      expiration, and the CC code, and transmit a payment to Visa.
      P: What's a CC code?
      C: (takes out credit card) It's this printed number on the card. It
      doesn't show up on paper prints of the card, so it is a bit of a
      security thing to make the user type it in.
      P: Are we going to require the number always?
      C: Probably. There are two ways to transmit a charge to Visa. But
      we're not
      sure if we'll do non-CC or not.
      P: You've mentioned Visa twice. Are we going to just use Visa?
      C: No. Visa, MasterCharge, and a few lesser cards all go through the
      same
      clearing with the same transactions. Later we will do some other
      cards
      like AmEx that use separate clearing. That will be another story.
      P: But the basic kind of operation will be the same, right? We get the
      card info and pass it to the card people and they say go or no?
      C: Right.
      P: You didn't mention an amount. Do we always pay off the total
      balance?
      C: No, we got off on the CC code. The user also enters the balance
      amount
      that he wants to pay.
      P: So we send that proposed transaction to the credit card company,
      and
      they authorize or deny.
      C: Right. Then we display a results page to the user.
      P: OK, I get the idea. We'll need to know how to transmit and receive
      messages to the credit card company.
      C: Yes. Here is their writeup of how to connect to their web service,
      and
      the format of the XML messages. (hands copy to programmer)
      P: We haven't done any web services connections yet, we'll have to
      experiment a little. Couple of days, probably, before we can give
      you a
      good estimate on the whole story. Sounds like the rest is a couple
      of
      standard web forms.
      C: Right.
      P: Do we verify the CC number separately, or as part of the main
      transaction?
      C: Part of the main. Otherwise someone could sit on the web page and
      try
      different CC numbers until he found it.
      P: Gotcha. I think that's enough for us to shape in most of the code
      and
      a mock up page format. Unless you have a sketch of what it should
      look
      like?
      C: I was thinking like this. (Draws something on a card.)
      P: (takes card) OK, we'll start from this. You can tune it after you
      see
      it. I'll assume two days to fiddle the form back and forth during
      the
      iteration. That's about what it took for the order form.
      C: OK, what else?
      P: How are you going to test this?
      C: I'd like two things. First of all, I want to put the system in a
      mode
      where transactions are verified against an internal file that I
      control, listing account number, balance, card, CC, and like that,
      and
      you implement something that sends the XML to a program that uses
      that
      file. That way once we get that going we can set up accounts and
      play
      with them.
      P: We can do that. Once we figure out Web Services we can estimate
      that
      better. Do you want that to be a web service?
      C: I don't care, whatever works best. I'd say do it without Web
      Service
      at first, won't it be faster?
      P: Yes, both to build and to run. We'll probably need at least one
      test
      on your side or ours of actual Web Services working as well. But
      you
      said there were two kinds of tests.
      C: Yes. Visa has a test system that maintains known, fake, standard
      card
      data. You connect to it the same as the real one and can run
      transactions against it. I have to find out more about how it
      works,
      though it is in that writeup I handed you. So we'll specify some
      tests
      using that.
      P: Let's treat those tests as a separate story, since we don't know
      what
      they are now.
      C: Sounds good.
      P: OK, I've got enough now to get started. I'll come ask questions as
      they come up.
      C: Check. I'll start writing some test data down on paper.
      P: Good. When you get a few of those, please come interrupt me. I'll
      want
      to use them to check my understanding even before we build the
      tests.
      For now, I'd estimate that card at 10 days, but we'll know more
      after
      we spike the XML Web Service stuff.
      C: Great. (writes estimate on card)
      (They kiss. Fade out.)

      Card: Says almost nothing, perhaps just the name of the story. It's OK
      to
      write more on there if you want to. If tempted to write a lot, get
      smaller
      cards.

      Conversation: Covers everything someone cares about, interactively. Both
      people lead, both follow. Occurs more than once. When P needs more info,
      he
      can get it. When C thinks of something, he can talk to P about it.

      Confirmation: The tests that C and P talked about, and other tests like
      those that will be refined and filled in.

      Does that help? If not ... ask more.

      Ron Jeffries
      www.XProgramming.com
      Don't be afraid of pair programming:
      You may not be as good as you think you are, but
      You're not as bad as you fear.



      ________________________________________________________________________
      ________________________________________________________________________

      Message: 12
      Date: Tue, 25 Feb 2003 09:09:40 -0500
      From: Ron Jeffries <ronjeffries@...>
      Subject: Re: Re: How to write stories for bugs? (and mice ;-)

      On Tuesday, February 25, 2003, at 8:47:49 AM, jeffgrigg63132
      <jgrigg@...> wrote:



      >> Edmund Schweppe wrote:

      >>> If the Customer is sufficiently technically savvy, they'll

      >>> know to ask about memory leaks; if not, [...]



      > Or they'll quite rationally assume that the programmers are

      > technically savvy enough to know that memory leaks are a bad thing,

      > and should be avoided.



      Well, "when you assume ...". If the customer is technically savvy enough
      to

      know leaks are bad, they IMO would be derelict in not mentioning it. But

      see below ...



      >>> Regardless of the client's level of knowledge, the memory

      >>> leak is still a defect. For a particular application, the

      >>> Customer may not care - or may care more about other

      >>> defects - but it's still a defect.



      > --- Ron Jeffries <ronjeffries@a...> wrote:

      >> [...] And I certainly think that memory leaks are a defect and

      >> usually an important one.



      > A memory leak is a defect. It's a waste of resources and a violation

      > of standards. But the priority of fixing it, relative to other

      > business needs *IS* open to interpretation.



      Yes. And an iterative development is also open to learning. If no one

      thinks of memory leaks, and they turn out to be a problem, no process
      will

      save the team from a bug. The XP team gets the bug report, uses it to

      educate the customers and the programmers, and lets the customers decide

      whether to fix it.



      > I wrote a small C++ program some years ago that leaked memory quite

      > profusely. This was intentional: It was a quick and dirty prototype

      > used to demonstrate that certain kinds of expression parsing could be

      > done. The production code would be written in PL/I, with no memory

      > leaks.



      > For a long running program, typically a service on a server, memory

      > leaks can be a big problem. For a program that runs and exits, the

      > most effective way to free memory can be to exit the program,

      > terminating the process. I'm serious. It's true.



      Totally agree.



      > The decision as to when The Customer's time and money should be spent

      > to improve the efficiency with which the program uses system

      > resources is The Customer's. Let's allow the customer to make

      > business decisions regarding their investment.



      Exactly.



      Ron Jeffries

      www.XProgramming.com

      Talent determines how fast you get good, not how good you get. --
      Richard Gabriel

      ________________________________________________________________________
      ________________________________________________________________________

      Message: 13
      Date: Tue, 25 Feb 2003 07:18:21 -0800
      From: "Van Hamersveld, Mark" <mvanhame@...>
      Subject: RE: Re: How to write stories for bugs?

      wecaputo@... wrote:
      >
      > Ron:
      > > please give an example of a defect in the software which should NOT
      be
      > > detected by customer tests.
      > Edmund:
      > >Memory leak.
      >
      > If it can affect the user its going to be
      > important to them (and they should have an objective measure of its
      > reality)

      Wouldn't something like a memory leak belong to the class of "defects"
      which
      are automatically taken care of by professional programmers? Wouldn't
      this
      be in the same class with producing quality code through refactoring?
      Even
      if the user doesn't "see" it or know to ask about it is it not a defect?
      Sounds like trees falling in the forrest to me.

      Memory leaks are a smell of bad code and should be taken care of during
      normal refactoring and not put to the user to create a story for, or an
      acceptance test for. Certainly the user may have memory usage
      requirements
      such as 24/7 operation (which doesn't necessarily pertain to leaking but
      on
      efficient use of available memory), small footprint, etc. which should
      be
      put into story form with appropriate acceptance tests.

      Mark


      ________________________________________________________________________
      ________________________________________________________________________

      Message: 14
      Date: Tue, 25 Feb 2003 09:19:39 -0600
      From: "Dubbs, Roger" <rdubbs@...>
      Subject: RE: Velocity & Yesterday's weather

      Of course I meant "expect", or "challenge". The opposite behaviour
      would be to just accept the status quo. Somehow I'm quite sure that's
      not what you're advocating. ;-)

      Roger

      > -----Original Message-----
      > From: Ron Jeffries [mailto:ronjeffries@...]
      > Sent: Monday, February 24, 2003 5:16 PM
      > To: extremeprogramming@yahoogroups.com
      > Subject: Re: [XP] Velocity & Yesterday's weather
      >
      >
      > On Monday, February 24, 2003, at 3:11:47 PM, Dubbs, Roger wrote:
      >
      > > Yesterday's Weather is a one-iteration moving average. I
      > see no harm in using more iterations to smooth the
      > > expected result somewhat. In fact, the manager is
      > probably right to demand more tomorrow than he got
      > > yesterday. That's the road to improvement. When you come
      > in below the goal, the manager's (and team's!) job
      > > is to troubleshoot the problem and figure out how to
      > improve the next iteration.
      >
      > > Just my $0.02
      >
      > I'm not sure what part "demanding" has in "improvement".
      >
      > Ron Jeffries
      > www.XProgramming.com
      > Accroche toi a ton reve. --ELO
      >
      >
      > To Post a message, send it to: extremeprogramming@...
      >
      > To Unsubscribe, send a blank message to:
      > extremeprogramming-unsubscribe@...
      >
      > ad-free courtesy of objectmentor.com
      >
      > Your use of Yahoo! Groups is subject to
      > http://docs.yahoo.com/info/terms/
      >
      >
      >


      ________________________________________________________________________
      ________________________________________________________________________

      Message: 15
      Date: Tue, 25 Feb 2003 10:51:51 -0500
      From: "Tim Moore" <tmoore@...>
      Subject: RE: Re: How to write stories for bugs?

      > -----Original Message-----
      > From: Ian Collins [mailto:ian@...]
      > Sent: Monday, February 24, 2003 8:46 PM
      > To: extremeprogramming@yahoogroups.com
      > Subject: Re: [XP] Re: How to write stories for bugs?
      >
      >
      > Edmund Schweppe wrote:
      >
      > >Ron Jeffries wrote
      > >
      > >[ ... ]
      > >
      > >
      > >
      > >>please give an example of a defect in the software which
      > should NOT be
      > >>detected by customer tests.
      > >>
      > >>
      > >
      > >Memory leak.
      > >
      >
      > That's why I always make sure all tests are run with a
      > garbage collector
      > linked in. May not be an option with all languages, but can be a
      > saviour with C/C++.

      Garbage collectors aren't a silver bullet, though. They may solve the
      vast majority of memory management problems in C/C++, but not all of
      them. You can have objects that are still reachable but never actually
      used.

      But, yeah, leak detector programs are readily available...How many
      people here really use them as a matter of course?

      --
      Tim Moore / Blackboard Inc. / Software Engineer
      1899 L Street, NW / 5th Floor / Washington, DC 20036
      Phone 202-463-4860 ext. 258 / Fax 202-463-4863


      ________________________________________________________________________
      ________________________________________________________________________

      Message: 16
      Date: Tue, 25 Feb 2003 10:57:23 -0500
      From: "Tom Copeland" <tom@...>
      Subject: RE: Re: How to write stories for bugs?

      >
      > Garbage collectors aren't a silver bullet, though. They may solve the
      > vast majority of memory management problems in C/C++, but not all of
      > them. You can have objects that are still reachable but
      > never actually
      > used.
      >
      > But, yeah, leak detector programs are readily available...How many
      > people here really use them as a matter of course?
      >

      I don't. Most of the stuff I work on currently is in a category someone
      mentioned earlier - you run it, it does something, and then it exits.

      I've worked on 24x7 systems that could have used leak detection, but
      those systems had far more serious problems than a leak detector could
      identify :-)

      Yours,

      tom



      ________________________________________________________________________
      ________________________________________________________________________

      Message: 17
      Date: Tue, 25 Feb 2003 11:01:58 -0500
      From: "Tim Moore" <tmoore@...>
      Subject: RE: Re: How to write stories for bugs?

      > -----Original Message-----
      > From: Tom Copeland [mailto:tom@...]
      > Sent: Tuesday, February 25, 2003 10:57 AM
      > To: extremeprogramming@yahoogroups.com
      > Subject: RE: [XP] Re: How to write stories for bugs?
      >
      >
      > >
      > > Garbage collectors aren't a silver bullet, though. They
      > may solve the
      > > vast majority of memory management problems in C/C++, but
      > not all of
      > > them. You can have objects that are still reachable but never
      > > actually used.
      > >
      > > But, yeah, leak detector programs are readily available...How many
      > > people here really use them as a matter of course?
      > >
      >
      > I don't. Most of the stuff I work on currently is in a
      > category someone mentioned earlier - you run it, it does
      > something, and then it exits.

      Fair enough.

      > I've worked on 24x7 systems that could have used leak
      > detection, but those systems had far more serious problems
      > than a leak detector could identify :-)

      Yeah, that's about where I am now. :-P

      --
      Tim Moore / Blackboard Inc. / Software Engineer
      1899 L Street, NW / 5th Floor / Washington, DC 20036
      Phone 202-463-4860 ext. 258 / Fax 202-463-4863


      ________________________________________________________________________
      ________________________________________________________________________

      Message: 18
      Date: Tue, 25 Feb 2003 16:31:47 -0000
      From: "David Putman \(DavidPutman.com\)"
      <davidputman@...>
      Subject: Re: Re: How to write stories for bugs?

      > > But, yeah, leak detector programs are readily available...How many
      > > people here really use them as a matter of course?

      > I don't. Most of the stuff I work on currently is in a
      > category someone mentioned earlier - you run it, it does
      > something, and then it exits.

      Problem is, if you're selling into a regulated environment, or any
      environment that tests software before deploying it, they will detect
      your
      memory leaks for you.
      If you're happy for them to do that, fine but it can be an unnecessarily
      painful lesson to learn.
      Let's not make the mistake of thinking that we're the only people who
      know
      about these things.

      Dave P



      ________________________________________________________________________
      ________________________________________________________________________

      Message: 19
      Date: Tue, 25 Feb 2003 11:38:25 -0500
      From: Edmund Schweppe <schweppe@...>
      Subject: Re: Re: How to write stories for bugs?

      Ron Jeffries wrote:
      > On Monday, February 24, 2003, at 10:37:15 PM, Edmund Schweppe wrote:

      [re: memory leaks]

      > > Is it still a defect if the Customer doesn't think it's important
      enough
      > > to have a test and get it fixed? I think so - an unimportant defect,
      but
      > > a defect none the less. Of course, other folks' mileage may vary.
      > Sure. And still it needs to go through the customer, because (in XP)
      only
      > the customer can decide.

      I agree wholly that, once the defect has been recognized and the cost of
      fixing has been estimated, only the XP Customer can decide whether or
      not it's worth fixing. My point (for what it's worth) is that the memory
      leak is a defect in all these cases:
      a) when nobody knows about it;
      b) when its effects are noticed but before it's actually found;
      c) when it's been found but before it's been fixed.

      As several other posters have noted, lots of memory leaks never have
      enough effect to be noticed. Others may be noticed but left unfixed for
      a variety of reasons - in the XP case, specifically including the
      situation where the Customer says not to bother. Stil others get fixed.

      In all cases, the leaks are defects; only in the latter cases do XP
      Customers make any decisions about them, and only in the last case would
      an XP Customer specify a Customer Test that checks for the leak's
      absence. Or so it seems to me.

      --
      Edmund Schweppe -- schweppe@... -- http://schweppe.home.tiac.net
      The opinions expressed herein are at best coincidentally related to
      those of any past, present or future employer.


      ________________________________________________________________________
      ________________________________________________________________________

      Message: 20
      Date: Tue, 25 Feb 2003 08:45:58 -0800
      From: "Van Hamersveld, Mark" <mvanhame@...>
      Subject: RE: Re: How to write stories for bugs?

      It is my understanding from these posts that a story can be completed
      and
      called "done", even if it has defects that the programmers know exist,
      but
      the customer hasn't found. Is that a true statement?

      If so, the programmers are *knowingly* releasing buggy code. What is
      stopping programmers then from racing through stories to get them "done"
      and
      making their personal velocity appear high, when infact, their sloppy
      work
      creates many additional stories that impact the entire project
      negatively?



      ________________________________________________________________________
      ________________________________________________________________________

      Message: 21
      Date: Tue, 25 Feb 2003 10:59:52 -0600
      From: Brad Appleton <brad@...>
      Subject: Re: Re: How to write stories for bugs?

      You guys do realize you're talking about the classic function of change
      control boards (CCBs) - yes? I realize CCB is a term eschewed by many
      agilists as it's all too often associated with big projects and big
      process. But at it's heart, its simply about how one goes about
      explicitly making shared decisions about what requests get implemented
      and when (regardless of whether its a bug/feature or whatnot).

      Thus anything "new" that impacts any of the "four variables" (cost,
      quality, schedule, scope) is a potential project issue/risk and must be
      analyzed, estimated, and prioritized. If the XP way for managing this is
      using StoryCards, then I would surmise that any new issue impacting any
      of those 4 variables in a way that is "customer visible"gets its own
      story.

      If so, it seems that in XP, the "Story" is not merely a unit of testable
      "business value" to be delivered, but also anything that needs to be
      estimated and prioritized.

      --
      Brad Appleton <brad@...> www.bradapp.net
      Software CM Patterns (www.scmpatterns.com)
      Effective Teamwork, Practical Integration
      "And miles to go before I sleep." -- Robert Frost


      ________________________________________________________________________
      ________________________________________________________________________

      Message: 22
      Date: Tue, 25 Feb 2003 17:03:52 -0000
      From: "Kiel Hodges <kielhodges@...>"
      <kielhodges@...>
      Subject: Re: Velocity & Yesterday's weather

      --- In extremeprogramming@yahoogroups.com, "Ryan Ripley"
      <ripley@i...> wrote:

      > Isnt change constant though? I think its dangerous to rely
      soley on
      > *Yesterday's Weather*. In otherwords, can we truely/honestly
      ever make the
      > assumption that "team and enviroment are staying relatively
      constant"?

      Dangerous? It shouldn't be. You're just making plans. Things
      never go exactly as planned. Don't set things up so that
      someone's life or the health of the company depends on your
      predicted velocity being exactly right (no matter how you make
      your prediction.)

      In general, we cannot make the assumption that things stay
      completely constant. Nor can we assume that the next iteration's
      velocity will be the exactly the same as the average of all
      previous velocities. We're only getting a rough prediction. I
      prefer using the straightforward rough prediction of yesterday's
      weather instead of calculating averages to get a prediction
      essentially as rough.

      > I'm wondering what the rule says about developer X having a new
      child at
      > home, or developer Y having a serious conflict with developer Z
      over some
      > crazy, yet common, corporate issue. While yes these issues
      typically have
      > nothing to do with *software development*, I think that they do
      *seriously*
      > impact project velocities.

      If the rule says I should ignore these factors, then I would
      invoke the "They're Just Rules" rule. In practice, my teams
      predicted future velocity through discussions. We used
      Yesterday's Weather as a starting point (because it's simpler)
      and raised whatever issues we thought might impact the velocity.
      For example, after a couple of iterations that targetted and hit
      120 points, we all felt that we hit the numbers through luck and
      a pace that was not sustainble. After a brief discussion, we
      agreed to 100 points as our velocity for the next iteration.

      I think using averages or running averages might just discourage
      these kinds of discussions. I believe these discussions are much
      more valuable in predicting velocity. They also improve the
      overall effort in other ways. For example, it might come out that
      the team squeaked by because those acceptance tests that were
      available only late in the iteration passed the very first time.
      Now the team has an opportunity to improve the process.

      Kiel Hodges
      SelfSo Software




      ________________________________________________________________________
      ________________________________________________________________________

      Message: 23
      Date: Tue, 25 Feb 2003 09:13:16 -0800
      From: "Dan Rawsthorne" <DrDan@...>
      Subject: RE: Writing User Stories

      Use Cases and User Stories have different goals:
      * the Use Case is for communicating to users - telling them what
      they'll be getting from the system. They are based on the Goal being
      produced. Because they exist to support the User's understanding, their
      format and size must be based on the needs of the User validating them.
      * User Stories are a bite-sized bit of functionality that can be
      delivered in a relatively short time. Because they are used to control
      development, their format and size is based on the needs of the
      Developer and Customer - they must be able to be sized, prioritized, and
      developed

      The Customer Team has the unenviable job of converting Use Cases (if
      your project uses them) to the User Stories needed to drive development.
      I use a technique called the Ever-Unfolding Story for this, and the
      ratio seems to be about 10-50 User Stories per Use Case.

      Let me take a simplistic view in order to explain further. A Use Case
      consists of *all* scenarios an Actor might use to accomplish the same
      goal. A typical use case may have dozens of scenarios, including all the
      alternative and failure ones. Each of these scenarios is a candidate for
      a User Story - each provides a chunk of functionality that is of benefit
      to the Actor, and they are often small enough to be estimatable...
      additional decomposition and recomposition is necessary to get them to
      final size, but you get the idea...

      Dan ;-)

      Dan Rawsthorne, PhD, Sr. Consultant
      www.netobjectives.com
      DrDan@...
      office: 425-531-0814

      Net Objectives' vision is effective software development without
      suffering. Our mission is to assist software development teams in
      accomplishing this through a combination of training and mentoring.


      > -----Original Message-----
      > From: Nicholas Robinson [mailto:nicholasrobinson@...]
      > Sent: Tuesday, February 25, 2003 12:14 AM
      > To: extremeprogramming@yahoogroups.com
      > Subject: Re: [XP] Writing User Stories
      >
      > Hi Jeff,
      >
      > Thanks for that. When we think of use cases, we sit down and consider
      > what the goals of the user
      > is. He wants to make a payment, make an order, track an order. Is
      this
      > the same granularity as
      > the user story, but in a less formal format? Is a story broken down
      into
      > task cards? I need to
      > re-read some of the Kent Beck stuff, but any practical guidance is
      most
      > appreciated.
      >
      > Regards
      >
      > Nick.
      > --- Jeff Nielsen <jeff.nielsen@...> wrote: > From the
      green
      > book (Planning XP):
      > >
      > > "A user story is a chunk of functionality that is of value to the
      > customer."
      > >
      > > It provides a simple way for developers and customers to partition
      what
      > the
      > > system needs to do so that it can be delivered in pieces.
      > > A story must be:
      > >
      > > 1.1. Understandable to customer/developer
      > > 2.2. Testable
      > > 3. 3.Valuable to the customer
      > > 4. Small enough to build a few each iteration
      > > -
      > >
      > > These four criteria have helped me keep people on track who are new
      to
      > > deciding "what is a story".
      > >
      > > Jeff Nielsen
      > > Digital Focus (www.digitalfocus.com)
      > >
      > > ----- Original Message -----
      > > From: <nicholasrobinson@...>
      > > To: <extremeprogramming@yahoogroups.com>
      > > Sent: Monday, February 24, 2003 10:58 AM
      > > Subject: [XP] Writing User Stories
      > >
      > >
      > > > Hi,
      > > >
      > > > I have two books on XP, and both dont seem to explain fully what a
      > > > User Story is. Can someone either explain to me, as if I know
      only
      > > > of Use Cases, or maybe point me to a link? I need to swot up on
      them
      > > > because on Wednesday the XP Workshop I am in is gonig to start
      > > > producing the requirements for the two projects we have decided to
      > > > build applying XP. Nobody as yet, knows 100% how to write User
      > > > Stories or how to plan, so any pointers to any good online
      resources
      > > > would be most welcome.
      > > >
      > > > Thanks,
      > > >
      > > > Nick.
      > > >
      > > >
      > > >
      > > > To Post a message, send it to: extremeprogramming@...
      > > >
      > > > To Unsubscribe, send a blank message to:
      > > extremeprogramming-unsubscribe@...
      > > >
      > > > ad-free courtesy of objectmentor.com
      > > >
      > > > Your use of Yahoo! Groups is subject to
      > http://docs.yahoo.com/info/terms/
      > > >
      > > >
      > >
      > >
      > > To Post a message, send it to: extremeprogramming@...
      > >
      > > To Unsubscribe, send a blank message to: extremeprogramming-
      > unsubscribe@...
      > >
      > > ad-free courtesy of objectmentor.com
      > >
      > > Your use of Yahoo! Groups is subject to
      > http://docs.yahoo.com/info/terms/
      > >
      > >
      >
      > __________________________________________________
      > Do You Yahoo!?
      > Everything you'll ever need on one web page
      > from News and Sport to Email and Music Charts
      > http://uk.my.yahoo.com
      >
      > To Post a message, send it to: extremeprogramming@...
      >
      > To Unsubscribe, send a blank message to: extremeprogramming-
      > unsubscribe@...
      >
      > ad-free courtesy of objectmentor.com
      >
      > Your use of Yahoo! Groups is subject to
      http://docs.yahoo.com/info/terms/
      >




      ________________________________________________________________________
      ________________________________________________________________________

      Message: 24
      Date: Tue, 25 Feb 2003 17:13:34 -0000
      From: "Kiel Hodges <kielhodges@...>"
      <kielhodges@...>
      Subject: Re: How to write stories for bugs?

      --- In extremeprogramming@yahoogroups.com, "Van Hamersveld, Mark"
      <mvanhame@a...> wrote:
      > It is my understanding from these posts that a story can be
      completed and
      > called "done", even if it has defects that the programmers know
      exist, but
      > the customer hasn't found. Is that a true statement?

      Not in my opinion. If a developer "finishes" a story and has all
      of the acceptance tests working, then realizes that there could
      be memory leaks or other defects, she should either just fix them
      (if they are very small) or discuss them with the customer.

      > If so, the programmers are *knowingly* releasing buggy code.
      What is
      > stopping programmers then from racing through stories to get
      them "done" and
      > making their personal velocity appear high, when infact, their
      sloppy work
      > creates many additional stories that impact the entire project
      negatively?

      Honesty? Integrity? The ability to look ahead? Pair partners?
      After it happens the first time, the coach and every honest team
      member with integrity? After the second time, the absence of the
      offender from the team?

      Kiel Hodges
      SelfSoSoftware



      ________________________________________________________________________
      ________________________________________________________________________

      Message: 25
      Date: Tue, 25 Feb 2003 12:26:38 -0600
      From: wecaputo@...
      Subject: RE: Re: How to write stories for bugs?


      Mark:
      >Wouldn't something like a memory leak belong to the class of "defects"
      which
      >are automatically taken care of by professional programmers?

      Preventing memory leaks, yes. If say we are using C++, writing classes
      that
      clean up after themselves properly and intelligent use of smart pointers
      are good design decisions. OTOH, as others have pointed out, this could
      be
      overdesign for a short running utility. (VB references can "leak" too,
      same
      deal)

      Discovered memory leaks are a different animal. This thread is (was?)
      about
      stories for bugs. A defect by definition is a code "feature" that has
      made
      it out of the programmer's control and into the customer's. So the
      customer
      needs a test -- either proactively to prevent the defect getting into
      production, or reactively after a user notices the problem.

      >Wouldn't this
      >be in the same class with producing quality code through refactoring?
      Even
      >if the user doesn't "see" it or know to ask about it is it not a
      defect?
      >Sounds like trees falling in the forrest to me.

      No, I don't think anyone is recommending a "let's see what we can sneak
      past the customer" strategy. I personally put honesty and integrity
      ahead
      of the XP values, and I wouldn't tolerate such deception on a team I
      worked
      on. I think we are talking about leaks that the programmer's just miss.
      Even with full honesty and professionalism, mistakes are made. Switch it
      around, you are the customer, are you going to leave it to the
      programmer's
      infallibility to find and fix bugs, or are you going to want tests?

      >Memory leaks are a smell of bad code and should be taken care of during
      >normal refactoring and not put to the user to create a story for, or an
      >acceptance test for.

      Again, s*** happens. We can wait until it does, or try to catch it
      before
      it does in multiple nets. (I am a multiple net kinda guy)

      >Certainly the user may have memory usage requirements
      >such as 24/7 operation (which doesn't necessarily pertain to leaking
      but
      on
      >efficient use of available memory), small footprint, etc. which should
      be
      >put into story form with appropriate acceptance tests.

      I think (once again) we are in violent agreement. ;-)

      Best,
      Bill

      William E. Caputo
      ThoughtWorks, Inc.
      --------
      It is impossible to design a system so perfect that no one needs to be
      good. -- T.S. Eliot






      ________________________________________________________________________
      ________________________________________________________________________



      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.