MSDN Magazine - December 2008 - (Page 45)

Figure 1 MSF Agile and MSF CMMI Team Member Roles area architecture architecture Development Development Development Product management Product management Product management Product management Program management Test User experience User experience Development Development Product management Program management Release Operations Release Operations Test architecture User experience Role Infrastructure architect Solution architect Build engineer Development manager Lead Developer auditor Product manager Sponsor Subject matter expert Integrated Project Management (IPM) Officer Test manager User education Specialist User experience architect Database Developer Developer Business analyst Project manager Database administrator Release manager Tester architect Business analyst CmmI y y y y y y y y y y y y y y y y y y y y N N agile N N N N N N N N N N N N N y y y y y y y y y influences the TFS process guidance, though MSF has its own rich set of guidance resources, which are available at microsoft.com/technet/solutionaccelerators/msf. You can find further useful information in the book Microsoft Solutions Framework Essentials (Microsoft Press, 2006) by Michael Turner. The prescriptive guidance included with the Microsoft process templates dives into how to run a development project and how to structure your work streams. This guidance is focused on the process of development, not the mechanics of Visual Studio or TFS. You access the guidance through the Process Guidance link off the home page of your team project’s SharePoint portal home page. The guidance is also available for download on its own from Microsoft (go.microsoft.com/fwlink/?LinkId=131713 for MSF Agile and go.microsoft.com/fwlink/?LinkId=131714 for MSF CMMI) if you want to peruse it without needing live access to TFS. An easy way to contrast the MSF Agile and MSF CMMI process templates is agile versus formal. Both templates define different roles based on a team of peers broken down into seven logical areas. The MSF Agile template defines 8 roles as part of its team model. In contrast, MSF CMMI defines a whopping 20 roles. As shown in Figure 1, the CMMI template expands each logical area with more specific roles. These include managers and additional stakeholders that are not part of the core development team. Beyond the roles, you find work items have a number of differences (see Figure 2), including differences in the actual work item types provided for each template. Microsoft composes each work item type from four facets: purpose, fields, workflow, and layout. Thus, while both templates have a bug work item, fundamentally they are different types. In fact, a key difference between the MSF Agile and the MSF CMMI work items is their workflow expressed as states and transitions. If you drill into the process guidance for an MSF Agile bug and examine the States and Transitions section, you’ll note that an MSF Agile bug has three states and 23 transitions (see Figure 3). In contrast, the MSF CMMI bug has four states and 17 transitions (see Figure 4). You’ll notice, for example, that the CMMI bug starts in a proposed state while an MSF Agile bug is active once created. Anoth- Inside the MSF Templates and defines your default security groups, areas, iterations, and version control settings. And finally, a process template provides prescriptive guidance as part of your SharePoint site. When you first install TFS, you will find that it provides you with two process templates. Their official names in the 2008 release of TFS are Microsoft Solutions Framework (MSF) for Agile Software Development (MSF Agile) and MSF for CMMI Process Improvement (MSF CMMI). MSF promotes an iterative development process with heavy customer interaction. The current release of MSF is version 4.0 and Figure 2 MSF Agile and MSF CMMI Work Item Types Work Item Type Change Request Issue Requirement Review Bug Risk Task Quality of Service Requirement Scenario msdnmagazine.com Description A change request identifies a proposed change to some part of the product or baseline. The issue work item documents an event or situation that may block work or is currently blocking work on the product. Requirements capture and track what the product needs to do to solve the customer problem. The review work item documents the results of a design or code review. a bug is a work item that communicates that a potential problem exists or has existed in the system. a risk is any probable event or condition that can have a potentially negative outcome on the project in the future. a task work item communicates the need to do some work. Quality of service requirements document characteristics of the system such as performance, load, availability, stress, accessibility, serviceability, and maintainability. a scenario is a type of work item that records a single path of user interaction through the system. CmmI y y y y y y y N N agile N N N N y y y y y December 2008 45 http://www.microsoft.com/tech-net/solutionaccelerators/msf http://www.microsoft.com/tech-net/solutionaccelerators/msf http://go.microsoft.com/fwlink/?LinkId=131713 http://go.microsoft.com/fwlink/?LinkId=131714 http://www.msdnmagazine.com

Table of Contents Feed for the Digital Edition of MSDN Magazine - December 2008

MSDN Magazine - December 2008 Contents Toolbox CLR Inside Out Advanced Basics Cutting Edge Patterns In Practice Team System Real-World WF Visual Studio OBA Tools SOA Data Access Geneva Framework Test Run Foundations Windows With C++ Going Places End Bracket

MSDN Magazine - December 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.