In a CMM context, the customer does not have the choice of applying or
not the CMM recquired process. The "CMM documentation" stories are not
submitted to their appreciation. You can consider that their value is
so high, that they are mandatory.
Customers just have to know that, because their are in a CMM context,
the development of their business stories recquires also the
"development" of CMM stories.
However, on the development team side, the CMM stories appear has
other stories, with their cost which is not always high, and those
stories have to be done during the iteration.
That's it the XP way: simple design, pragmatic.. and courage...
;-)
--- In [EMAIL PROTECTED], Dominic Williams
<[EMAIL PROTECTED]> wrote:
> bernard_notarianni wrote:
>
> > Useally, when I talk to people who want to adress
> > those communication issues whithin an XP context, I
> > suggest to consider the communication artifacts
> > (documents?) they recquire to be produced as
> > XP-Stories with associated cost and value. Not more,
> > not less.
> >
> > And that's it.
>
> I'm not sure that's just "it".
>
> 1) Process documentation stories break the XP system in
> several ways: they can't be tested, they can't be
> evaluated like "feature" stories, it's not clear
> whether pairing is beneficial...
>
> 2) Why should we integrate some things, such as
> refactoring, as overhead into every story estimate, but
> defer decision over others, as you suggest, to the
> customer?
>
> 3) CMM and so on usually require the /process/ to be
> documented, which in turn requires the process to be
> measured, observed... It is well known (and is indeed
> the "raison d'�tre" of process documents) that
> observing a process will affect the process.
>
> I don't think it's an innocuous decision. And I think
> that wrapping it in a user story and leaving it to the
> judgment of the Customer is not entirely
> satisfactory. Maybe even lacking in Courage.
>
> It does serve the purpose of pointing out to the
> Customer that this stuff does have a cost, and that we
> could all be adding features instead. But the Customer
> could easily get the same idea about, say, refactoring,
> or all these test fixtures we write, not to mention
> hooking up music or ambient ORB's to the build...
>
> Regards,
>
> Dominic Williams
> http://www.dominicwilliams.net
>
> ----
To Post a message, send it to: [EMAIL PROTECTED]
To Unsubscribe, send a blank message to: [EMAIL PROTECTED]
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:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
