Chapter 27. Keep On Truckin : Completing the XP Road Trip


Chapter 27. Keep On Truckin': Completing the XP Road Trip

If your team is just starting out with XP, the first iteration is definitely the hardest. It's like driving in a foreign country. You know how to operate a car and how to read a map, but you can't understand the road signs at first, and everyone else drives much faster than you're used to. The next couple of iterations might not be much easier, but eventually you figure out what the signs mean and get used to the speeds.

The first XP team Lisa worked on completed two or three small projects of two to three iterations each before they started to feel like they knew what the heck they were doing. The retrospective you just completed will give you the starting point for making the next iteration more successful.

Use the short iterations and releases of XP to your advantage. Once your team has tried and gotten good at XP "out of the book," don't be afraid to experiment. Your team can always try something new if an experiment doesn't pan out. Stick with a new idea, tool, technique, or practice for at least three iterations; it may just be that you have to get through a learning curve before you can fairly evaluate the success of a tool or technique. Let the team come to a consensus on how it went and what to try next. Chapter 29 gives an example of how one team experimented with different approaches to test automation.

The second iteration should be pretty much like the first, with a few twists:

  • Now we have regression tests to run, in addition to the new tests we have to write and automate. (Aren't we glad we automated all our acceptance tests?)

  • Maybe we didn't manage to automate all our acceptance tests, so we have some leftover tasks from the last iteration. This is very bad and not XP, but don't be ashamed. You'll get better each iteration.

  • We, or the customer, might find more defects in last iteration's code. How do we handle maintenance?

No magic formula applies, so keep following the principles we've presented in these Part II chapters. Help the customer keep the team focused on the critical areas.

When we did our first release planning session for the XTrack system, our first iteration consisted of stories 1 6 (you can see our stories on www.xptester.org). We created a system to record and track iterations, stories, and tasks by project. The second iteration was stories 7 10: printing the items we tracked, adding problem tracking to our system, providing a history of velocity and test results, and allowing problems to be converted to stories. Because we could build on the technology we developed for the first iteration, both for production code and tests, this iteration could go more smoothly. You aren't starting from scratch to automate your tests. You now have a library of methods or modules that can be reused in new tests.

Automating and executing acceptance tests for a story normally takes the team between 20% and 30% of the time spent on developing that story. If your team spent a lot more time than this, stop and look at your approach. Does your application have too much business logic in the user interface layer? Does it take too long to script automated tests with the tool you're using? Do team members need more training in test automation techniques? Brainstorm ways to reduce the time spent creating and maintaining automated tests.



Testing Extreme Programming
Testing Extreme Programming
ISBN: 0321113551
EAN: 2147483647
Year: 2005
Pages: 238

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net