You, and every member of the team, will be responsible for the success of the project, meeting the client's needs, improving your skills, scheduling your tasks, and meeting your schedule. The tasks you will perform will depend on the role you assume in the team. The roles for the software team, as we listed them in Chapter 1, were project, product and component management, development, testing, user education, and logistics. Product management, user education, and logistics will all work with the client.
The client can be either external to the corporation or internal to the corporation. There is little difference between these two situations. Therefore, when I refer to client it can mean either an internal or external client.
Component management, testing and development will have relatively little one-on-one contact with the client and will focus on creating the project components. However, team members in these roles will be involved from the very beginning of the project in meeting the needs of the client. They will have contact with the client during meetings to discuss design and other issues.
The number of people within each role will depend on the number of people available, the size of the project, and the number of end-users and stakeholders. It is best if there is only one stakeholder, so that there is one person who can make final decisions. In this case, one product manager for the project may be sufficient. As we said earlier, a one to one ratio between developers and testers is best. For smaller projects, or when the team is shorthanded, there may be two to three developers per tester. To properly use these testers there must be a good testing plan in place. The number of logisticians and educators depend on the number of end users and what will be required to set up the final project.
When a team is very shorthanded, certain team members can play more than one role. Some roles conflict with each other and so the same person should not be in both roles. An example of this would be the tester and developer (though one developer testing someone else's code will probably not be a problem). Other roles, such as educator and tester, can be performed by the same person. The following lists give some guidelines on which roles are incompatible and which may be held by a single person.
Roles that cannot be filled by the same person:
> Component Management and Product Management
> Component Management and Development
> Project Manager and Development
> Project Manager and Product Management
> Testing and Development
> Product Management and Testing
Roles that can be filled by the same person:
> Product Management and Testing
> Product Management and User Education
> Component Management and Logistics
> Component Management and Project Manager
> Testing and User Education
Roles that have no conflicts but would be difficult for one person to do both:
> Component Management and Testing
> Component Management and User Education
> Product Management and Logistics
> Logistics and Testing
The advantage of creating a team from roles is that you can build a team from a group of people who have a wide range of skills and still have everyone find a role that they can perform well in. As each role has a well-defined set of skills, team members can easily determine what skills they will need to assume any role.
Once the team is assembled, decisions are made on a group consensus. If the members of the development team cannot reach consensus, the component manager will make the final decision; where the disagreement is between teams, rather than within a single team, it will be the project manager who must make the decision. Where consensus between the client and the software team cannot be reached, the stakeholder or the product manager will make the final decision. This means every member needs to understand how to make decisions, and how to participate in group meetings and discussions. Decisions do not always have to be made in formal meetings: a discussion can be started by an email sent to all members of the team. Each person can add to this email their ideas and suggestions, including the previous responses in their reply. The email will become a living document, containing the input of the entire team. Eventually, the discussion will lead to suggestions or solutions and (hopefully) a consensus on which is the best solution. Everyone on the team shares the same responsibility for making the best product within budget and time constraints. Every team member has a right to contribute to the group and to group discussions.
As team members assume responsibility for their tasks and the project, they will begin to identify with the product. They will feel that the quality of the product represents them. This will lead to better work and a more productive work environment.
Large projects will be big enough to have several component teams, consisting of a component manager, developers, testers, logistician(s) and educator(s). The logisticians, testers and educators may belong to more than one team or they may be roles filled by someone who is also in another role. The software team will work in an autonomous manner, coordinated by the project manager. This is possible because the software team will be building components. As long as the component supplies the appropriate public properties and methods, it will fit in with the rest of the project. Thus, each team can build their component separately from the other groups. Of course, best coding methods, techniques, changes in the design of any component, client issues, etc. must flow through the entire team and to all software groups.
A small team of four developers may look as follows:
The logistics and component management roles will be filled by one person (who will function as the project manager), as will the product management and user education roles. Operations support is the client's infrastructure support personnel.
In a larger project where there are many people to fill all of the roles, the project team may look as follows:
Component Team 1
Component Team 3
Component Team 2
Component Team 3
There are no direct lines connecting the component teams to the client groups, as members of the component team will usually communicate to the client through the appropriate liaison. However, if a member of the component team needs to speak directly to the client, this should be possible. If this does happen, the appropriate liaison should be informed of what was discussed. Communication can flow from any member of the team to any other member of the team.
Remember that this is not a hierarchy. This figure shows the flow of communication through the group; it does not indicate that any role is above any other. Again, the testing and development roles are likely to be filled by more than one person.
Was this article helpful?