Roles

The role is a very important concept in Team System regardless of which process you decide to implement. The underlying process and tooling is built around the interplay between project managers, architects, developers, and testers. To enforce this concept, Microsoft has designed different versions of Visual Studio that play on the strengths of each of the principal roles. MSF for Agile Software Development defines six primary roles:

• Business analyst

• Project manager

• Architect

• Developer

• Tester

• Release manager

Important

In recap, MSF for Agile Software Development has six defined roles. MSF for CMMI Process Improvement has seven defined roles. In the following section, we will look at all seven roles.

What if you have a very small team or the members of your team take on several roles? Microsoft took this into account in the creation of the Team Suite, a version of Team System that incorporates all of the primary roles within a software development team. Moreover, you aren't limited to the roles defined in

MSF for Agile Software Development or CMMI. You can modify the process to remove roles and incorporate your own custom roles. For example, if your team has members that are both developer and tester, you can create a new role called DevTest.

Note

When you are looking at the process guidance documentation, you'll notice that there is a Set as Start Page option with a checkbox on the top-right side of the screen (once you click a specific role). Selecting the checkbox will set your home page to the role description and bookmark the tasks and other useful information pertinent to your role.

MSF is quite flexible regarding the definition of a role. For example, if you are both an architect and a developer, the only requirement set in place is that you have the expertise to effectively perform tasks within each role, and act as advocates for the technical solution.

The following sections provide an overview of the roles on a software team as defined by both versions of MSF. For greater detail about a specific role, we recommend that you refer directly to the MSF documentation.

Business analyst

The goal of a business analyst is to analyze the business requirements and opportunities and outline the applications that will help the company reach their business goal. The analyst has to translate the business requirements from stakeholders and customers into requirements for the development team.

The business analyst advocates for the customer and should provide direct customer contact to the other roles in the development group whenever it is needed and where possible. Often, there are quintessential customers willing to work directly with the development team. The business analyst is responsible for managing these relationships and making these folks available to the project team to create maximum agility.

From a business perspective, business analysts manage customer expectations and act as an advocate for the customer. They play an integral role in the planning stage of the product — especially in terms of building business cases, a communication plan, marketing and evangelism, defining and managing the customer requirements, and driving business value in a software development project. A business analyst will also help the project manager balance resources, scheduling, and features.

Within a software development process, the business analyst's role is to help determine quality of service requirements (QoS), create use cases and scenarios, and define personas. MSF for Agile Software Development provides a business analyst with three primary workstreams:

• Capturing the project vision

• Creating scenarios

• Creating quality of service requirements

Once the project vision report and scenario are completed, they are typically published to the project portal. You can also publish the quality of service requirements to the project site and create quality of service and scenario work items to relate to your project plan. Examples of quality of service requirements include load and stress testing, security, platform, and performance.

MSF for CMMI Process Improvement adds four extra roles to the mix: the sponsor provides the funding and governance for the project and helps define the feature spec of an application. The subject matter expert provides input on the technical requirements of an application. For example, Microsoft uses most valuable professionals (MVPs) as valued customers and experts when they define technical feature sets for their products. Both these roles provide a "reality check" to determine whether the software will meet business and real-world requirements. The auditor also plays an important part in the process, verifying that the project is within budget and meets the business requirements. Finally, the product manager will take the vision statement and specifications and work closely with the project managers in the implementation phase of the project.

Project manager

The project manager (or project lead) is responsible for coordinating and facilitating software development projects — from scheduling to the overall budget. Project managers usually create project and iterative plans and analyze reports to identify and correct problems before they happen.

They are the connective glue within a team. PMs communicate with business analysts to ensure that a project is hitting all business requirements. Alongside the analysts, they are the primary architects for the project.

Project managers also handle implementation details such as administrative tasks, negotiation, and communication within a software development team. They are responsible for managing the project specs, quality assurance, and risk. They also have to interface with solution and operation architects, developers, and testers to correctly estimate, deploy, and maintain the project plan and scheduling.

For a detailed overview of the project management features of Team System, be sure to take a look at Chapter 19 and the MSF for Agile Software Development documentation. In MSF for Agile Software Development, a project manager performs three workstreams:

• Planning iterations

• Guiding projects

• Guiding iterations

Within MSF for CMMI Process Improvement, there are two advocacy roles: the project manager and the integrated project management (IPM) officer. The IPM officer is an executive who is responsible for a collection (or portfolio) of projects (a project manager is typically responsible for a single project at a time). The IPM officer can manage multiple project managers, distribute resources across multiple projects, and involve stakeholders during set milestones in the project.

Architect

An architect's role is to model the structure and foundation of a software application. Using the Team Suite for Architects tools, an architect can define the physical and logical structure of a service-oriented system and the operational constraints of a network. Based on the quality of an architecture, the system will be usable, scalable, secure, and performable. For a more detailed overview of the resources available for an architect in Team System, please refer to Chapters 1 through 7. In MSF for Agile Development, the architect has a single workstream: to create a solution architecture.

Within the MSF for CMMI Process Improvement process, the architecture role is divided in two:

• Infrastructure architect

• Solution architect

The infrastructure architect is responsible for creating a system design (in other words, mapping out the logical topology). The solution architect can then validate his or her solution design against the topology. This is a great way to identify security issues, and other real-world scenarios before the application moves on to the coding phase.

Developer

Developers are responsible for the implementation of a software application in code within certain constraints (such as schedule). In the MSF for Agile Software Development framework, developers contribute to the modeling of the project infrastructure, requirements, and features. As subject matter experts, they can provide invaluable input on the selection of the proper technological approach.

Developers build the features with an eye on maintaining quality and mitigating risk, and they set up the deployment details. They can also provide services writing documentation and consulting. Here are the important workstreams associated with a developer:

• Implementing development tasks

• Fixing bugs

• Building products

To learn more about Team System's development tools, please refer to Chapters 8 through 12. The development advocacy group in the CMMI for Process Improvement process is split up into four key roles to ensure predictability and accountability:

• Developer

• Lead developer

• Development manager

• Build engineer

Tester

Testers have an important role within the software team. They must create and update test plans and strategy, and perform a battery of tests to uncover problems within code. There is a wide spectrum of tests to implement, including functional, usability, quality, documentation, and many others. Once a bug or issue is found, it must be addressed and communicated to the rest of the team in an effective way.

The tester has to have a deep understanding of project requirements to provide the team with actionable information about a bug. Once the tests have been performed, the tester has the responsibility of signing off on a feature and approving a release. If the quality of a product is not up to par, the entire project suffers. The tester has to document and create workarounds, re-create the steps to reproduce a bug, and ideally try to discover new bugs within a product.

Finally, a tester must comprehensively report on all issues for the rest of the team. Here are the work- streams associated with the tester:

• Testing scenarios

• Testing quality of service (QoS) requirements

• Closing bugs

For more in-depth information about the Team System testing tools, please refer to Chapters 13 through 17. MSF for CMMI Process Improvement adds the test manager role, in order to track and measure progress of the testing phase of a project.

Release manager

Not all teams have a release manager: In some instances, your developer or project manager may handle release details. If your team is large enough, the release manager's main responsibility is deploying a product. The release manager must create deployment plans and coordinate the transfer of products to media (such as CD-ROM, DVD, online distribution or other delivery channels), the shipment details, and rollout plans (if applicable). If a product is to be rolled out, the release manager must prepare the target site.

Release managers use quality reports to ascertain the readiness of a product release. They are also responsible for the smooth ongoing operation of software after deployment, including coordination with operations personnel. A release manager has but one workstream: releasing a product. For more information about product deployment, be sure to read Chapter 24. Both MSF for Agile Software Development and MSF for CMMI Process Improvement include the release manager role.

User experience

The user experience advocacy group is unique to MSF for CMMI Process Improvement. It incorporates two advocacy roles: a user experience architect and a user architect specialist. The architect will constantly evaluate the overall usability of an application, whereas the specialist will work on design elements, prototypes, and technical documentation related to facilitating the product's use. The user experience experts are user education specialists — for example, technical writers.