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/
