This post originated from an RSS feed registered with .NET Buzz
by Darrell Norton.
Original Post: Extreme Programming Explained: 2nd ed - Part 3
Feed Title: Darrell Norton's Blog
Feed URL: /error.htm?aspxerrorpath=/blogs/darrell.norton/Rss.aspx
Feed Description: Agile Software Development: Scrum, XP, et al with .NET
In part 2 we looked at the primary and corollary practices of Extreme Programming. The idea of the "whole team" was mentioned several times, so now let's look at what exactly it encompasses.
Originally XP concentrated on programmers and managers, and this worked out well. But as XP is applied to larger projects and projects with a need for specialized skills, such as interaction designers, the idea of the team broadened.
The role of a tester is different. Instead of focusing on unit-level testing, testers move to integration, systems, and acceptance testing, automating as much as possible. The tester works with the customer to help specify what they want. Testers also help developers figure out how to test difficult sections of code or bring up unit-level test ideas that a developer may have overlooked. There is a good article by Bret Pettichord called Where are the Testers in XP? and Cem Kaner has an article on The Role of Testers in XP.
Interaction designers work with the customer to write and clarify users stories. Nothing much has changed, except that they don't get to do ALL their work before "throwing it over the wall" to the developers.
"Architects on an XP team look for and execute large-scale refactorings, write system-level tests that stress the architecture, and implement stories. Architects apply their expertise a little bit at a time throughout the project. They direct the architecture of the project throughout its evolution. The architecture for a little system should not be the same as for a big system. While the system is little the architect makes sure the system has just the right little architecture. As the system grows, the architect makes sure the architecture keeps pace."
Project managers facilitate communication both within the team and externally between the team and the rest of the organization. PMs should be constantly on the lookout for process improvements. I highly recommend a Scrum style of project management.
The product manager is in charge of the business aspect of the project. He or she writes stories and generally supervises requirements gathering, picks iteration themes, prioritizes stories, and decides what to cut if the schedule is too aggressive. Product managers are also the link between customers and developers.
Executives are to generally act as team and project champions.
Technical writers are the conduit through users learn how the features as implemented help them do their job. It isn't always documentation either! The most effective methods should be used, including video demonstration, walkthroughs, class teaching, standard documentation, context-sensitive help, etc. Technical writing is much more difficult in an XP environment due to the pace of change, and I don't think this area has been fully explored by the Extreme Programming community.
Developers/programmers estimate stories and implement them.
Human resources need to be able to change standard review practices to more align to XP's desired employee characteristics. In addition to the standard software development abilities, XP employees should act respectfully, be a good team player, take initiative, and deliver on commitments.
That wraps up XP's new views on the team. There is only another topic or two left to cover in this brief tour of XP v2, one on simple design and then one on a few miscellaneous issues.
Previous Topic
