Typical XP Project Roles

I l @ ve RuBoard

Here are some of the main roles that have been suggested in the XP literature.

• The manager schedules the iteration meetings, ensures that the process is being followed, provides reporting, and removes project obstacles.

• The customer writes and prioritizes user stories (think of stories as ideas for features; see Chapter 7) and writes acceptance criteria. She has the authority to make decisions.

• The coach oversees the entire project to ensure that the team is following XP best practices.

• The tracker tracks the teams ' progress, helping them solve problems and warning the manager of any potential problems.

• The programmer estimates stories, breaking them up into tasks and estimating tasks ; volunteers for stories; and writes unit tests.

• The tester helps the customer write acceptance criteria, writes and runs functional tests, and reports test results.

• The doomsayer , or naysayer, is anyone on the team who senses a problem and brings it to the attention of the team. (Let's hope it isn't always the tester.)

By the way, the doomsayer role is symbolic and played by different people at different times. When someone points out a problem, she needs to be heard without feeling like a negative influence. In standup meetings (see Chapter 10), it is common for someone to play doomsayer and lay out a problem the rest of the team would rather not see. Everyone gripes, but when the gripe is prefaced with "I need to be the doomsayer for a minute," everyone stops and listens. doomsayer should be a role of great power.

For more information on all team roles, read Chapter 22 of Extreme Programming Explained . ^[1]

^[1] Beck, Kent. Extreme Programming Explained. Boston: Addison-Wesley, 2000.

I l @ ve RuBoard