This chapter is from the book
This chapter is from the book
This chapter is from the book
Process Templates
The process template supports the workflow of the team by setting the default work item types, reports, queries, roles (i.e., security groups), team portal, and artifacts. Work item types are the most visible of these because they determine the database schema that team members use to manage the backlog, select work, and record status as it is done. When a team member creates a team project, the Project Creation Wizard asks for a choice of process template, as shown in Figure 2.2.
)
Figure 2.2. The Project Creation Wizard lets you create a team project based on any of the currently installed process templates.
Microsoft provides three process templates as standard:
- Microsoft Visual Studio Scrum: This process template directly supports Scrum, and was developed in collaboration with Ken Schwaber based on the Scrum Guide.2 The Scrum process template defines work item types for Product Backlog Item, Bug, Task, Impediment, Test Case, Shared (Test) Steps, Code Review Request/Response, and Feedback Request/Response. The reports are Backlog Overview, Release Burndown, Sprint Burndown, and Velocity.
- MSF for Agile Software Development: MSF Agile is also built around an agile base but incorporates a broader set of artifacts than the Scrum process template. In MSF Agile, product backlog items (PBIs) are called user stories and impediments are called issues. The report shown in Figure 1.4 in Chapter 1 is taken from MSF Agile.
- MSF for CMMI Process Improvement: This process template is also designed for iterative work practices, but with more formality than the other templates. This one is designed to facilitate a team’s practice of Capability Maturity Model Integration (CMMI) Level 3 as defined by the Software Engineering Institute.3 Accordingly, it extends MSF Agile with more formal planning, more documentation and work products, more sign-off gates, and more time tracking. Notably, this process template adds Change Request and Risk work item types and uses a Requirement work item type that is more elaborate than the user stories of MSF Agile.
Other companies provide their own process templates and can have these certified by Microsoft. For example, Sogeti has released a version of its Test Management Approach (TMap) methodology as a certified process template, downloadable from the Visual Studio Developer Center at http://msdn.microsoft.com/vstudio/aa718795.aspx.
When you create a team project with TFS, you choose the process template to apply, as shown in Figure 2.2.
Teams
Processes tend to prescribe team structure. Scrum, for example, has three roles. The Product Owner is responsible for the external definition of the product, captured in the product backlog, and the management of the stakeholders and customers. The Team of Developers is responsible for the implementation. And the Scrum Master is responsible for ensuring that the Scrum process is followed.
In Scrum, the team has three to nine dedicated members. Lots of evidence indicates that this is the size that works best for close communication. Often, one of the developers doubles as the Scrum Master. If work is larger than can be handled by one team, it should be split across multiple teams, and the Scrum Masters can coordinate in a scrum of scrums. A Product Owner can serve across multiple scrum teams but should not double as a Scrum Master.
In TFS, each team has a home page with data from the current sprint of its project, like an up-to-date burndown chart and the remaining, incomplete PBIs, as shown in Figure 2.3. Additionally, the team gets its own product backlog and a task board—both are available using the Web browser. To support larger projects with multiple teams, TFS enables the concept of master backlogs that consolidate each team’s product backlog into a single view.4
)
Figure 2.3. The tiles on the team’s home page represent the team’s current progress as well as favorite metrics, including work items, testing, source control, and the automated build and test results. Additionally, you can jump to all important views from this page.
In most cases, it is bad Scrum to use tooling to enforce permissions rather than to rely on the team to manage itself. Instead, it is generally better to assume trust, following the principle that “responsibility cannot be assigned; it can only be accepted.”5 TFS always captures the history of every work item change, thereby making it easy to trace any unexpected changes and reverse any errors.
Nonetheless, sometimes permissions are important (perhaps because of regulatory or contractual circumstances, for example). Accordingly, you can enforce permissions in a team project in four ways:
- By role
- By work item type down to the field and value
- By component of the system (through the area path hierarchy of work items and the folder and branch hierarchy of source control)
- By builds, reports, and team site
For example, you can set a rule on the PBI work item type that only a Product Owner can update PBIs. In practice, this is rarely done.