Flylib.com

Books Software

 
 
 

Educating the Customer


Educating the Customer

This is an area where you want that ounce of prevention. Educating the customer so he has reasonable expectations is essential. Before you back the XP car out of the garage, talk with the customer about how you'll handle issues. Make him read the defect-handling chapter in Extreme Programming Installed . Better yet, produce your own XP owner's manual that describes your own team's development process and helps the customer get the most value out of the project. Your owner's manual could cover topics such as

  • Planning. Describe story creation; explain that you defer in-depth discussion of each story until it's selected for an iteration or until it needs to be clarified for the purpose of making an estimate.

  • Iteration planning, story selection. Outline the negotiation process involved in selecting the stories for an iteration that are both high priority for the customers and make sense for the programmers (in terms of dependencies between stories, creating an initial framework, and so on).

  • Acceptance tests. List the input expected of the customer as she helps write the tests and the process for running and verifying results before the end of the iteration.

  • Defect fixes. Define the policy on handling defects. You may choose to classify them into those that must be fixed to call the story complete and those that can be deferred to a future iteration. Fixes that will take up significant programmer resources must be written up as stories for the next (or a future) iteration. Whatever policy you decide on, make sure you and the customer agree on it.

  • Realistic expectations. Set realistic expectations for the relatively low level of documentation and status artifacts generated as a byproduct of XP. If the customer feels lost without certain metrics or documents, you may be able to find a creative way to provide them without adding excessive overhead. XP is all about being flexible.

  • Communication tools. Review what's available with the customer. For example, you might have a wiki (see Chapter 30) where he can learn about the status of the project and other general project information. Some teams capture information about iterations, tasks , and stories (as our XTrack system does) that can be used to generate reports of various metrics.


Acceptance Criteria

Remind the customer that she defined acceptance criteria in the acceptance tests. Anything that causes an acceptance criterion not to be met is a defect. This is why you invest time in making sure the acceptance tests are thorough and that the development team has clearly understood the customer's requirements. The customer needs to understand that in spite of the best efforts and best XP practices of the team, some defects will probably be discovered by acceptance tests, and a few may even make it past both the unit and acceptance tests. Explain the options available for handling these defects.

Prepare the customer for issues that look like defects but are outside the scope of the iteration. It's one thing to imagine what a screen will look like and how it will work. When the customer sees the live software, he might wish it worked differently from his original description or might think of things he really wanted that he forgot to mention. Maybe this iteration's story didn't cover the ability for the system to handle a large number of users, and a large numbers of users causes a crash.

This is where your acceptance criteria come in handy. If it wasn't part of the acceptance criteria, it doesn't affect the successful delivery of the story. Fortunately, it can easily be included in the next iteration. The customer won't have to wait more than the length of the iteration, one to three weeks at most. It takes time for the customer to build trust in the XP team. She may be afraid to go on to the next iteration until all defects, even trivial ones, are fixed.

If the customer changes his mind about his standards for quality, those should be included in stories for subsequent iterations, along with new or changed ideas he's had during the iteration.