Accessorizing for XP
| The XP books describe tools and accessories that facilitate learning and applying XP practices. Below are some suggestions based on our experiences. Your team will come up with more ideas, particularly as a result of your retrospectives after each iteration. WhiteboardsThe whiteboard is your friend. Not only does it usually contain a lot of helpful information, such as diagrams and pictures left over from planning discussions and lists of tasks and priorities, but you can use it in a variety of ways to facilitate testing-related tasks. Keep a list on a whiteboard of the highest-priority issues discovered, to remind you to show them to the programmers. The programmers can check them off when they fix them, and you can erase them after verifying the fixes. Be sure to track these in an online defect-tracking system as well, so nothing drops into a black hole and so you have the records in case the defect recurs. Some teams list tasks on the whiteboard as well as on the story or task cards. This way, everyone can see who's working on what task and know when it's complete. You might list testing tasks on the board, so team members can check off when they've run a particular set of tests. Questions you think of for a customer or programmer who isn't immediately available can go on a whiteboard, to prompt your own memory or others'. If your team is spread across more than one location, the whiteboard has obvious limitations. In this case, a wiki, where team members can easily update the information on the Web pages (more on the wiki later in this chapter), may be able to perform some of the same functions. Celebrating SuccessesOne team we worked with really liked, and adopted, the suggestion in Extreme Programming Installed to ring a bell when a task was completed. It provided the regular sense of accomplishment and completion that distinguishes XP from other methodologies. Ring the bell when you complete an automated acceptance-test script, when the acceptance tests for a story pass, or when a defect has been successfully fixed. Some teams might find a bell annoying. Just be sure you celebrate successes, such as completed tasks. Finished defining the acceptance tests for this iteration? Reward yourself (and your customers!) with a walk around the block, a quick game of foosball, a coffee break. Pick rewards that are fun for you. The team should celebrate its collective successes too. How about pizza and/or beer after a successful release? We heard about a group where the testers awarded ribbons to team members who "went the extra mile." The ribbons were silly and corny, but the recipients were proud of them, and the testers enjoyed the fun of choosing the winners. It's a lot of fun to recognize a "quality hero" with a ribbon, toy, or plate of cookies. Celebrating each others' accomplishments helps offset the times when team members have to deliver bad news ("We have to drop a story." "We found a giant defect"). TimerStandups are brief (ideally, ten-minute) daily meetings where each team member reports what he's accomplished the previous day, how much time it took, what he's working on today, how much time he needs to complete his current task, and what problems may be in his way. Team members may decide on their pairings for the day. When the team is anxious to get on with their tasks, an overly long standup can impede progress. A kitchen timer is a great help to limit standup meetings. A modification of this practice is to have the person talking hold the timer. This helps him remember to be concise and helps focus the team's attention on him. One team didn't stand up until the timer went off, which is cheating somewhat, but having to stand when time's up helps conclude the meeting quickly. Some teams do fine without a timer. One large, multilocation project Lisa worked on easily concluded its standup in fifteen minutes every day without one. Every team member is responsible for staying on track during standups. It takes practice and focus, but most people prefer short meetings! WikiWhiteboards aren't practical for every documentation need. A project wiki, which is a Web site everyone can easily update on the fly, is a good resource for keeping everybody in sync. (Wiki-wiki is an alliterative substitute for quick, and we use wiki as a shorthand for the official name, WikiWikiWeb. See www.c2.com/cgi/wiki?WikiHistory for a history of wiki.) If your team doesn't have one and you can see beneficial applications of using one, suggest it. Here are some of the pages that might be on the project wiki:
|
EAN: 2147483647
Pages: 238