UFMG - ICEx - DCC

DCC630 – Engenharia de Software – Turma M
2o. Semestre de 2011

---

The Whole XP Team

Testers

Interaction Designers

Architects

Project Managers

Executives

Technical Writers

Users

Programmers

Human Resources …Given the choice between an extremely skilled loner and a competent-but-social programmer, XP teams consistently choose the more social candidate. The best interviewing technique is to have the candidate work with the team for a day. Pair programming provides an excellent test of technical and social skills.

Roles …Roles on a mature XP team aren't fixed and rigid. The goal is to have everyone contribute the best he has to offer to the team's success. At first, fixed roles can help in learning new habits, like having technical people make technical decisions and business people make business decisions. After new, mutually respectful relationships are established among the team members, fixed roles interfere with the goal of having everyone do his best. Programmers can write a story if they are in the best position to write the story. Project managers can suggest architectural improvements if they are in the best position to suggest architectural improvements.

In saying that the above roles can contribute to an XP team, I don't mean to imply that there is a simple mapping from one person to one role. A programmer may be a bit of an architect. A user may grow into a product manager. A technical writer can also test. The goal is not for people to fill abstract roles, but for each team member to contribute all he can to the team.

As the team matures, keep in mind the alignment of authority and responsibility. Everyone on the team can recommend changes, but they should be prepared to back up their concerns with action.

Kent Beck & Cynthia Andres 2004 on Software & Taylorismo

The first step of social engineering in Taylorism is the separation of planning from execution.

It is the educated engineers who decide how work is to be done and how long it will take. The workers must faithfully execute the assigned task in the assigned way in the allotted time and all will be well. Workers are cogs in a machine. No one wants to think of himself as a cog.

Echoes of Taylor can be heard in software development any time a person in authority makes or changes an estimate for someone else's work. The echoes can also be heard when an "elite" architecture or framework group prescribes precisely how work should be done by someone else.

The second step of Taylorist social engineering is the creation of a separate quality department.

Taylor assumed that workers would "soldier" whenever possible (work slowly or badly but not so slowly or badly as to be noticed). He created a separate quality control department to ensure that workers not only worked at the right pace but in the specified way, in order to achieve the right level of quality.

Many software development organizations are directly (and even proudly) Taylorist in having a separate quality organization. Having a separate quality department sends the message that quality is exactly as important to engineering as marketing or sales. No one in engineering is responsible for quality. Someone else is. Putting QA as a separate department within the engineering organization also sends the message that engineering and quality are separate, parallel activities. Separating quality from engineering organizationally makes the job of the quality department punitive instead of constructive.

I am not saying that quality, architecture, or frameworks are unimportant to software development. Quite the contrary. They are too important to be left to Taylorist social structures that impede the flow of communication and feedback vital to creating working, flexible, and inexpensive software in a changing world. We'll see in the next chapter some more recent ideas from the world of manufacturing that provide alternative social structures to meet these goals of productivity and quality.