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

The "others" customers and their requested artifacts

Expand Messages
  • bernard_notarianni
    I use to include management, CMMI auditors and other transversals actors such as architects as customers of the project. I also use to track their request
    Message 1 of 68 , Feb 26, 2005
      I use to include management, CMMI auditors and other transversals
      actors such as "architects" as customers of the project. I also use to
      track their request with "stories" describing was they want the team
      to produce: documentation, CMMI information, schedule, estimate or
      whatever fancy, crazy or not, artifacts.

      Hence, the project has to produce running tested code and also the
      "others" requested artifacts.

      Two issued are then raised:

      1) The big issue on those "stories", of course, is their testability:
      how can we know we have finished the doc? That it is ok and will not
      be rejected by the auditor?

      2) During the planning game, who can evaluate globally the value of
      the production of a CMMI doc against the real customer requested
      feature? In an ideal world, the team should have only one "customer"
      deciding when we should produce code, and when we could produce CMMI
      doc, but in real life, those requests are generally coming from
      opposite channelsÂ… Who should decide and compare value of those
      stories? The team?


      Any comment is welcome.


      --- In extremeprogramming@yahoogroups.com, "Kent Beck" <kentb@e...> wrote:
      > John,
      >
      > I would like to second your point and point out that it is connected to
      > Brad's idea/experience of surfacing all team activities as stories. The
      > stakeholders are not only those whose lives are affected by the software
      > under development, but also those whose lives are affected by the
      > development itself (e.g. managers, process people, auditors). I like the
      > tone of this discussion because it is expanding my vision of
      "customer" to
      > include more people.
      >
      > Kent Beck
      > Three Rivers Institute
      >
      > > -----Original Message-----
      > > From: yahoogroups@j... [mailto:yahoogroups@j...]
      > > Sent: Tuesday, February 22, 2005 1:53 PM
      > > To: extremeprogramming@yahoogroups.com
      > > Subject: Re: Is the curve of cost of defect removal
      > > exponential? Why? WAS: Re: [XP] The percent of people who
      > > just don't get it.
      > >
      > >
      > > I suppose it's time to point out that Onsite Customer is one
      > > of the places where XP is a bit naive. The "customer" is a
      > > role that one person might be unable to fill. She has to do
      > > several things, including set priorities and provide an oracle
      > > about what the system really has to do.
      > >
      > > I find Alistair Cockburn's formulation of a stakeholder
      > > to be a good guideline here. To paraphrase Effective
      > > Use Cases, a stakeholder is anyone whose interests
      > > the system advances _or_ has to protect. If you're
      > > missing the Customer's customer, you're missing a
      > > vital stakeholder, even when that stakeholder isn't
      > > directly funding the project .
      > >
      > > To get the right system, you need the voice of _all_
      > > stakeholders, either onsite or with a decent proxy
      > > onsite. Otherwise you're either going to be off target,
      > > incur unneeded communication costs, or both.
    • Ron Jeffries
      ... Both removing things and giving up things, in the sense you offer here, are important in the quest for simplicity, in my opinion. Ron Jeffries
      Message 68 of 68 , Mar 17, 2005
        On Thursday, March 17, 2005, at 6:34:00 AM, Brad Appleton wrote:

        > Kent Back wrote:
        >> Why do you think simplicity means mostly giving up things

        > Ron Jeffries wrote:
        >> Do you think simplicity means adding things?

        > It occurs to me that "giving up things" may not be the opposite of
        > "adding things". To me, the opposite of "adding things" is "removing
        > things" or "taking things away". Whereas "giving up things" means
        > "letting go" of personal attachment to something (an idea, belief, or
        > personal conviction).

        > "Giving up" something can mean letting go of an old way and mind-set of
        > doing/using a thing, without necessarily removing the thing.

        Both removing things and giving up things, in the sense you offer
        here, are important in the quest for simplicity, in my opinion.

        Ron Jeffries
        www.XProgramming.com
        Do only what is necessary. Keep only what you need.
      Your message has been successfully submitted and would be delivered to recipients shortly.