Formerly ExtremeProgrammingChallengeNine
You are working for a customer who won't pay you unless you follow a particular process for writing requirements, something much heavier than the PlanningGame The requirements process states that all changes to the requirements be accompanied by an audit trail.
How would you modify XP if you had to use a different, heavier requirements process? Does it still make sense? Would it still be extreme?
Sometimes the requirements are well-known and changing them is a big deal. The requirements for a compiler are often set by standard committees, and everything that committee does is accompanied by an audit trail. If XP cannot handle this then it cannot handle XpChallengeCompilers.
On the other hand, often companies make unreasonable demands. If requirements are changing rapidly then it is important for a software project to respond quickly to changes and this kind of customer is bad news.
It seems to me that XP could work on a project where traceability is crucial. All user stories are Word documents. All test cases have pointers to the user stories that they are based on, and user stories have pointers to the test cases that implement them. If you look at any method, you can follow the call chain back to test cases, and then to user stories, so you have perfect traceability. If the Word documents are kept in a revision control system along with all the code, then you should have a complete audit trail of changes to them. Would the customer find this satisfactory?
If I were going to try to put traceability into XP (which I might not), I'd put the user stories into the Smalltalk browser (rather than Word), so Senders and Receivers and config mgmt is all built in, and links can be built from tests to stories, etc. --AlistairCockburn
Having been on a team writing an optimizing compiler at MasPar, the requirements are nowhere near fixed. How many optimizations will you support in the debugger? How many new optimizations get put in the next release? How about performance tuning- how much?
My answer to this challenge is to go back to the customer and find out what the traceability is supposed to achieve, then build the simplest process that satisfies them. A numbering scheme for StoryCard's? Initials for every change to a StoryCard? Scan them into a LotusNotes database? There's lots of play in how much is enough. Listening carefully might be enough to give you a process that still felt like the PlanningGame, but satisfied the auditors. --KentBeck