Feedback
It's interesting to note that, of the four core values of XP, feedback is the only one defined in terms of a machine. One interpretation of this is that success on a software project is three parts people and one part technology which is not too far off, in our experience. Even the feedback on an XP project involves people. Kent Beck states in Extreme Programming Explained, "Concrete feedback about the current state of the system is absolutely priceless." Feedback is what testing is all about. In another departure from traditional software development, XP teams want to know the results of testing. They get feedback every day from the unit tests, and as acceptance tests are completed, they'll grow to depend on the feedback from those tests as well. Customers tend to understand acceptance tests much better than they do unit tests, since they participate in writing them. You may even display the functional and acceptance test results along with unit testing results on a daily basis. You'll get a lot of satisfaction posting these for everyone to see, especially if the graphs continue in positive trends each day. Who gives you feedback? How do you know the acceptance tests are adequate? Both the customer and the programmers can give you valuable input on test definitions. The short iterations help too. If the acceptance tests pass but the customer is dissatisfied with how the software works at the end of the first iteration, you know your team's communication with the customer about the tests was faulty. Make sure you, the programmers, and the customer work together to write tests that truly show the customer that the stories are completed in the way required. If many acceptance tests are still failing at the end of the iteration, this, too, is a sign that your development team doesn't really understand what the customer wants and what the tests are checking. See what you can do to facilitate better communication between programmers and the customer. One of the most valuable skills you can learn is how to ask for feedback. Ask the programmers and customer if they're satisfied with way the team is automating and running acceptance tests. Do they feel the acceptance test results are giving value? Are the acceptance test definitions easy enough to use? Are there enough tests for areas of high technical risk? In the day-to-day race to finish an iteration, we don't always stop to think what could and should be changed. The retrospective meeting and iteration planning are both good times to get the team to think about these issues and suggest alternatives. |
EAN: 2147483647
Pages: 238