Roles on the Contractor's Software Development TeamThis section describes the major roles on software development teams, their responsibilities, and the attributes of strong performers in each role. Figure 5-1 illustrates these roles. The roles described here are for software development teams ranging in size from 6 to 30 people. On the lower end of this range, the same person may perform more than one role. I do not pretend to believe that this is the only organization that works, or that these are the only roles needed. Your specific situation and organizational norms will dictate the exact staffing profile. That said, I have organized several teams around these roles and found them to be successful. In the absence of any guidelines from your organization, the roles described here are a good starting point upon which to build a successful software development team. Figure 5-1. Roles on the contractor's software development teamThe Project Manager RoleCertainly a common and well-recognized role, the project manager role has evolved in recent years. The project manager was once a role of authority. The project manager would identify the tasks, delegate the tasks to the staff, and apply pressure as needed to push the staff to work until the tasks were done on time. The project manager would seldom share much information with subordinates, other than what was necessary for them to get the job done. This type of project manager is rapidly becoming a relic. Project Managers and Team InteractionToday's project manager is more of an "enabler" of teams. The project manager still identifies and delegates many of the tasks, but equally important, this person shares the vision with the team. He collaborates more closely with the team. Here are some additional characteristics:
Qualifications Needed for the Project Manager RoleThe project manager is perhaps the most complex role on a software development team. The reason is because of the diverse skill set required. To be successful, a project manager must be proficient in the following areas:
Interfacing with Other OrganizationsNo project manager can work in a vacuum. You need to interface with a number of other departments within your company to be successful. Here are some examples of other groups within your company, along with the nature of the interaction you will have with them:
Aspiring to the Project Manager RoleMost project managers come from either the development ranks or nontechnical ranks. Each has strengths and weaknesses. A project manager coming from a development role already is acquainted with technologies and software development processes. You will be strongly tempted to get closely involved with coding, design, and other detailed activities. You need to resist this temptation. Remember the importance of other aspects of the project manager position, especially financial tracking and forecasting. Your ability to foster the relationship with your customer, and to work closely with the other departments in your company, is of paramount importance. Finally, team building, particularly for developers, is especially emphasized. For you to successfully resist the temptation to get involved with technical details, you need to have complete trust in the people who make the technical decisions on your team. A project manager who comes from a nontechnical background might find managing a software development project to be a bit of a culture shock. For project managers in this situation, your selection of the technical lead role on your project is especially important. In fact, you may want to choose a technical lead who has experience managing projects. The technical lead will become a trusted advisor. The most frequent frustration I hear from project managers in this situation is that software development in general seems very unpredictable. Seemingly small changes can have significant effects on cost and schedule. My advice to these project managers is not to commit to any changes without first consulting the project team. You need advisers you can trust, because you will encounter situations requiring judgment tempered by experiences you might not have. Another frustrating aspect is that measurable progress seems intangible. An iterative lifecycle process can help mitigate this. As executable releases are produced, some "hands-on" time with the releases can alleviate this frustration. The Developer RoleMost projects have many developers. In contrast with the project manager role, the developer's role appears straightforward and simple: Apply technical skills toward implementing the project requirements, and solve related problems. However, it is not always that simple. The developer role is an interesting balancing act of creative problem solving versus conformity to requirements. It also involves adapting to changing situations while working to control change. Finally, it involves quickly cranking out code versus building in quality along the way through unit-level and some integration-level testing. The best developers balance these factors well. Aside from the governing principles for team building in general, the specific skills needed for developers depend on the technologies used by your project, so we will not cover them here. Another consideration is the type of process used on the project. A large project with lots of formality and ceremony may not be a good fit for developers who have experienced only small, unstructured projects with no formal process in place. There is one caveat to observe with hiring developers. In addition to the usual skills with the languages and platforms used for software development, make sure that the developer is willing to use the tools provided as part of your software development infrastructure. In other words, tools such as configuration management, change management, visual modeling, and testing are important to the success of the team as a whole. I have seen a few otherwise excellent developers who are either reluctant to use these tools or who outright refuse to use them. If adherence to software process is important, make sure that the developer is on board with consistent use of these tools and adherence to the practices used by your team. The Architect RoleArchitects usually rise from the developer ranks. The typical architect is a senior developer rising in her career who eschews management roles in favor of "staying technical." This is an important role, because the architect identifies and develops the foundation or framework of the system being developed. Poor choices and decisions made in designing the architecture can lead to disaster later in the project. One of the underlying principles of the RUP and iterative development is that the architecture is the first priority in development and receives attention in the project's initial iterations. This makes sense, because the architecture is a major risk area, and the consequences of failure are high. Qualifications Needed for the Architect RoleQualifications for the architect role are similar to those of the developer role, but with some important additions:
The Technical Lead RoleThe technical lead is typically the most senior developer on the team. This person directs the dayto-day activities of the developers, testers, and analysts. He also mentors the more junior developers. He may also have some development tasks of his own. The technical lead is often a senior developer who aspires to be a project manager. In fact, the technical lead performs many of the tasks normally associated with the project manager. However, being a developer, the technical lead works every day with the other developers on the team and can delegate tasks according to the developers' specific skills and talents. Put another way, the technical lead is more of a tactical leader, and the project manager role is a strategic one. Qualifications Needed for the Technical Lead RoleThe technical lead role qualifications are similar to those for the architect. The technical lead must be respected both as a competent developer and as a leader. In addition, the technical lead is the project manager's right-hand person. In other words, there should be complete trust between the project manager and the technical lead. They should have similar philosophies regarding managing and motivating people. The Toolsmith RoleThe toolsmith role is one I seldom see mentioned, but it is still important. On all software development projects, the software development team uses numerous tools, technologies, and processes. Most projects need to customize or tailor some of these tools to the project's specific needs. The toolsmith installs and configures the software development environment toolset and readies it for use. In addition, the complexity of the tools used means that, at some point, problems will be experienced, often at the worst possible time. Someone who is familiar with the tools needs to solve these problems fast to minimize the impact on the project schedule. The qualifications to be a toolsmith are simple: knowledge of the tools, and the ability to customize them according to the organization's needs. Who Pays for the Toolsmith?Because this role is somewhat of a novelty, many customers do not understand this role and will question a bid that includes one. The customer clearly understands why a project manager, testers, and developers are needed, but a toolsmith sounds like a questionable item. Here are guidelines to follow:
The Requirements Analyst RoleThe requirements analyst role is unique in that the person in this role probably has the most contact with the customerpossibly even more than the project manager. The requirements analyst is responsible for translating the customer needs into specific requirements that are implementable, testable, and documented. This person also is consulted by the technical lead, developers, project manager, and testers whenever there is a question about the project requirements. Qualifications Needed for the Requirements Analyst RoleThe following are guidelines for the skills necessary in a requirements analyst:
The Tester RoleThe tester represents the last chance to catch problems before the system reaches the customer. Interestingly, the tester role has much in common with the requirements analyst role. Specifically, the tester needs detailed knowledge of the requirements. As with the developer role, the tester role is not really simple and straightforward. With the increased complexity of software systems today, software testers must be increasingly technical themselves. Testers need knowledge of testing techniques, methods, and associated tools. They must be able to hold meaningful conversations with developers and be able to glean useful information from them. They must be meticulous and organized (much like the requirements analyst) to be able to thoroughly validate a system's requirements. In the RUP, or any process involving iterative development, the tester needs to join the team much earlier than with projects that follow conventional Waterfall-based processes. The reason is that the development team will produce executable releases early in the project lifecycle, possibly as early as the Inception phase. Testing is covered in Chapter 11, "Testing." The Configuration Management/QA RoleOn small to medium-sized projects, the same person performs the configuration management (CM) role and the quality assurance role. As a team grows beyond 20 people or so, there is enough work for two people to perform these roles. The Configuration Management RoleFor the configuration management role, the primary responsibility is to be able to perform independent builds of the system without assistance from development. This person also works with the developers to document the build process. Another important responsibility is to know exactly which versions of files are needed to successfully perform the build. The CM engineer also needs to produce the exact versions of all the files that went into creating a release. The purpose is to make maintenance easier. When a problem with a software release is reported, the developers will have a much easier time reproducing the problem if they have the exact same version the problem was reported against. Finally, if an emergency bug fix is needed, the CM engineer must be able to re-create the exact source files used for a specific release so that she can correct the reported problem and deliver a patched release that has the exact same functionality as before but with the problem corrected. Finally, for each release produced by the development team, the CM engineer needs to be able to produce a report showing exactly what issues and problems were corrected with a given release, as well as which requirements were implemented. To be effective, the person performing the CM role needs a configuration management tool and should be competent in its usage. The Quality Assurance RoleMany organizations have a dedicated quality assurance engineer. Ideally, the person in the quality assurance role does not report to the project manager to ensure objectivity. The quality assurance engineer should not feel pressured to permit items affecting quality to pass. Quality assurance personnel should be familiar with applicable standards, such as CMMI, various development processes (such as the RUP), and many other standards. This includes coding standards, user interface standards, configuration management, requirements management, and, in general, the entire software development process. Quality assurance personnel have a tricky job. They must be able to focus attention on deviations from agreed-upon standards without invoking feelings of resentment among the project staff. Diplomacy is the key skill needed for these situations. |