|I l @ ve RuBoard|
Unfortunately, Web development is subtly different from typical XP projects, and therefore these roles need to be modified for it. For example, while one of the fundamentals of XP states that team members shouldn't specialize, specialization is inevitable in Web development. The following sections describe some of the main roles that we have found necessary in Web XP.
Web XP development teams are made up of individuals with various roles, each having its own challenges.
This role has been clearly defined as the person who " writes the user stories and specifies functional tests. Sets priorities, explains stories, views CRC sessions. . . . May or may not be an end user . Has authority to decide questions about the stories."  Web customers range widely in their knowledge of
If Web XP is to work, there needs to be accommodations for customers with varying abilities and experience. What we recommend is a series of training sessions at the beginning of the project for those who are unfamiliar with the Internet and what it can do and on XP and what, as customers, they will be responsible for.
Customers need to learn how to write user stories and how to prioritize them. They start by accepting or rejecting user stories developed by team members and assigning priorities. Then they go on to write their own stories depending on their comfort level. Customers also accept whether stories have been completed. The tester works side by side with the customer to write acceptance criteria for each story.
For customers who are unfamiliar with XP and uncomfortable with writing user stories, the strategist will play a key role. He is the primary customer advisor, training them on writing stories by translating their business requirements into stories that the team can develop. In a way the strategist becomes the customer's XP coach. Another part of the strategist's responsibility is to be the customer's advocate.
There are many different types of developer who work on Web projects, including interface programmers, server-side programmers, graphic designers, and flash developers. They are responsible for showing up for daily standup meetings and iteration planning meetings, suggesting stories to the customer, estimating stories, defining and estimating tasks , and volunteering for and completing tasks. 
The graphic designer is responsible for the look of every page on the site. By following the graphic design process (see Chapter 8), she prepares mockups of the home page and an inside page. She then works with the interface programmer to lay out individual page content and functionality and to design the CSS.
The responsibilities of the server-side programmer are very close to those of the traditional XP programmer. He programs all server-side functionality and works with the interface programmer on any interfaces for application outputs.
Can someone be a server-side programmer and an interface programmer? Yes and no. Many programmers have the skills to do both, and if they don't at first they quickly will. These two roles work together often, and the transfer of skills is natural. Still, if staffing permits , we like to keep them as separate jobs. The worst Web sites are those that blur the lines between the client and server sides. Many programmers put SQL code right on a Web page. These direct calls to the database are the worst for making a site brittle. Server-side programmers should pretend that there is no Web site ”for all they should care, the client is a cell phone or a flying car. Interface programmers should forget all about databases and treat the server as a black box that gives them what they need when they need it. Both worlds have more then enough on their plate to keep them busy and intrigued.
A role defined in XP is the tracker, one of whose responsibilities is to check in with the programmers and mentor their development. Since a Web development production staff includes different types of developers, the tracker must be able to mentor different skill sets. Finding a person to fill this type of position can be difficult, so we have divided this role into two main parts : technical lead for the interface programmers and server-side programmers and creative director for the graphic designers.
Mentors are responsible for all tracker tasks. "A mentor goes around a time or two a week, asks each programmer how she's doing, listens to the answer, takes action if things seem to be going off track. Actions include suggesting a CRC session, setting up a meeting with a customer, asking a coach or another programmer to help." 
We recommend that mentors be involved in production by volunteering for tasks, attending daily standup meetings, and estimating stories. They should also be more involved in the planning of an iteration (see Chapter 7) by suggesting stories to the customer and advising her on recommended priorities.
The XP manager role is very close to that of project manager, with both responsible for keeping iterations on schedule through iteration meetings, daily standup meetings, and customer meetings. Managers check in with the mentors to assess potential problems and notify customers when a story should be dropped from an iteration.
Managers also are responsible for removing any obstacles to development, whether by arranging for purchases, getting an answer from a customer, or improving team morale . Finally, they provide reports on the progress of each iteration and collect timesheets.
When everyone knows what's expected of them and what to expect from others, it's easy to find the way.
Tester (Quality Assurance)
In XP it is assumed that most of the testing will be unit tests, but this isn't so in Web development. Here much of the testing involves user interface elements that can't be automated. For example, should a button read "Next" or "Continue" and should it be aligned to the left or to the center of the page?
The tester is responsible for manually testing the user interface, writing acceptance tests with the customer, running manual or automated acceptance tests, reporting on errors, and allowing/not allowing a release out to the customer preview site. 
|I l @ ve RuBoard|