Fundamental Concepts

MSF is built around the concept that process should enable you, rather than hinder you. If you implement too little process, you have to take great steps to stay on track. The inroads you make on a project will fully depend on the organizational skills of your team. The infrastructure will not support or enforce your process. Too much process inhibits productivity and velocity. MSF is the marriage of process and agility. The following sections take a look at the components that enable process within Team System.

Process template components

MSF comes with many principal template components to support a software development process including work products and work item queries.

Work products

Work products are the tangible assets that support the framework. They include documents, spreadsheets, binaries, and specifications necessary to support the process flow. These work products are usually included in process templates and are included in a new project when a process is selected.

Queries

Work item queries are important for gathering and supporting information about your activities and the activities of your team. They include some of the following:

• Active Bugs. Returns all of your active bugs (which you can export to Microsoft Excel).

• All Work Items. Returns active work items for your project. You can also use this query to schedule and manage work items.

• All Quality of Service Requirements. Returns all active project QoS requirements lists (which you can export into Microsoft Excel).

• All Scenarios. Returns a scenario list for your project (which can be imported into Excel).

• All Tasks. Returns all active tasks within your team project. The output from the query can be exported to Microsoft Excel or Project.

• All Work Items. Returns all of your project team's work items.

• My Work Items. Returns a list of your work items.

• Project Checklist. Returns a work items list for which the exit criteria field has a value of Yes.

• Resolved Bugs. Returns a list of resolved bugs.

Iterative process

The Microsoft Solutions Framework can handle quick multi-iterations to help you refine your code, wring out any bugs, and create better software. MSF includes a four-step cycle that enables you to incrementally develop and stabilize your application. Each iteration focuses on a different feature or bug fix. Smaller iterations are recommended for accurate project timelines. Here is an overview of the four iterative steps:

• Iteration 0: Plan and set up project

• Iteration 1: Plan, develop, and test application

• Iteration n: Plan, develop, and test application

• Final Iteration: Develop, test, and release product

Figure 21-5 illustrates the MSF iterative process in a nutshell. Team System supports quick iterations with continuous improvement. These iterations may overlap at times and the iterative process may be modified to fit your custom process. Iterations are supported in the product using the Areas and Iterations classification features (covered in Chapter 19). Using project management tools such as Team Explorer and Microsoft Project, you can organize your work items by iteration and map out the amount of time the iteration should take. On top of that, you can modify the process template to define default iterations as soon as a project is created. These are some of the ways Team System functionally support an iterative process.

Cycles

Cycles represent the process of building a software project and its associated tasks and activities. Cycles are another way of describing phases in a software development project that are not neccesarily sequential. Some of the most common cycles include the following:

• Check-in

• Daily Build

• Accepted Build

• Iteration

Figure 21-5

Smaller iterations enable you to quickly build features and reduce estimation errors, and they provide an effective feedback loop. Each iteration cycle should result in a solid feature in your product.

Cycles and iterations are loosely coupled. For example, a check-in may occur several time a day during a particular iteration of a project. Cycles represent a cross-section view of the MSF specifications. For more information about this view, please refer to the default process guidance documentation.

Personas

Personas are used to describe groups of users or customers. Instead of dealing with abstractions, you can tailor software to the needs, skills, abilities, and lifestyle of a fictional person. Personas should not be constructed in a vacuum; you must try to gather metrics to determine your audience and build a profile based on your gathered data. Personas are not a substitute for customer interaction. They are merely a way of communicating with customers.

Note

Kim Goodwin (who works for Alan Cooper's firm Cooper Interactive Design) is the originator of personas. Alan Cooper made personas famous in his book The Inmates are Running the Asylum (Sams, 2004). You can read an article on the origins of personas on his personal website at http://www.cooper.com.

"Bob" is an example of a simple persona:

• Role: New user.

• Motivation: Wants guided search results.

• Usage: Bob is unfamiliar with the web and related technologies. He types in the URL for the search engine looking for guidance. Fortunately, the search engine provides a portal categorized by topic to allow unfamiliar users to find what they want.

"Jill" is another example of a persona:

• Role: Power user.

• Motivation: Wants quick search results.

• Usage: Jill is familiar with search engines and types in her keyword query. The search engine returns highly relevant results that enable her to gather research for a term paper.

Note

Personas are used widely at Microsoft. For example, "Mort Gaines" is the personification of a hobbyist VB developer, as opposed to Elvis (a C# developer) and Einstein (a C++ developer). You can find photos and profile information about Mort on presentation materials such as Microsoft PowerPoint slides and internal posters.

Governance, tracks, and activities

Governance measures value based on budget and scheduling. MSF for Agile Software Development has five tracks (not to be confused with the Track view) relating to work cycles and iterations. The five general questions (or checkpoints) you should be asking yourself are as follows:

• What are our current objectives?

• Are we making the necessary progress?

• Are we on track for designing a quality product?

• Are we addressing the risk?

• Are we ready to deploy?

These checkpoints are defined from within MSF. To measure these governance checkpoints, you must evaluate whether the project is on target from both a business and operational perspective at all stages of the software life cycle. The CMMI for Process Improvement incorporates the following five tracks of the software development lifecycle:

• Envision

• Plan

• Build

• Stabilize

• Deploy

Using tracks, you can organize activities to address matters of governance. Different tracks can overlap with each other. They don't have to describe specific tasks — they are meant to be conceptual "buckets" to organize how you approach your process. Each track corresponds to a governance checkpoint.

Activities describe a collection rather than an ordering of tasks undertaken to perform a single action. There are defined activities for each role, and they may overlap with other roles. You can track an activity using work items or create work products to support them. Within most tracks, you'll find a variety of activities, including:

• Analysis

• Create Solution Architecture

• Develop Documentation

• Establish Environments

• Establish Project Process

• Fix a Bug

• Implement a Development Task

• Release a Product

• Test a Customer Requirement

• Verify a Product Requirement

The Develop Documentation and Verify a Product Requirement activities are examples of activities that provide a level of verification and accountability in the process. Tracks enable you to judge whether your process is on "track" — are we properly envisioning the project? Do we have a clear idea of what the software will do? What exactly are we building? By following the tracks and incorporating the right activities per track, we can avoid being led astray.

Note

Both MSF for Agile Software Development and MSF for CMMI Process Improvement have consistent views, including disciplines, qualities of service, cycles, and tracks. The chapter provided a very cursory examination of the tracks for MSF for Agile Software Development. If you look closely at the Agile documentation, you'll notice that the information presented under Governance and Tracks is identical. For more information, please refer to the process guidance documentation.

Work item types

Team Foundation Server uses work items to track assignments and work. MSF for Agile Software Development contains five work items: bugs, risk, tasks, scenarios, and quality of service requirements. Figure 21-6 shows a view of the Work Items window.

Note

SCRUM (one of the Agile methods) popularized a key innovation called the Product Backlog to track work progress. Product Backlog loosely inspired the Work Item Tracking functionality in Team System. In MSF, the product backlog is contained in two work products. The scenario list is the list of scenarios waiting to be implemented. The quality of service requirement list contains a list of quality of service requirements.

Figure 21-6

Please refer to Chapter 19 for more detailed information on the work item schema and how to customize work items within a team project.

Bug

A bug is a work item used to track and monitor problems within a software product. In order to be effective, a bug must be well documented, including the steps to reproduce the issue. A clear description of the bug is key to the process of "bug bashing" and will result in a higher-quality product. From the work item, the impact of the bug should be easily and clearly recognized. In MSF for Agile Software Development, bugs have four defined states:

• New: All new bugs need to be added to the work item database and documented as soon as possible.

• Active: This is the default state of a bug. An active bug means that the bug has been documented but not yet dealt with.

• Resolved: A resolved state means that a bug has been handled by a developer or tester. Once resolved, a bug can be classified as "Fixed" or included "By Design."

• Closed: A closed status means that the bug has been completely dealt with, including a verification process.

Figure 21-7 shows a state diagram illustrating how a bug might transition in a practical scenario.

Figure 21-7

Quality of service (QOS) requirement

Quality of service is central to the MSF for Agile Software Development process. The mindset should be reflected from all roles represented on the project team and all tracks of the software design process. (See the "Mindsets," "Tracks," and "Roles" sections near the end of this chapter for more details.)

In particular, quality of service focuses on user experience, security, and performance. You can measure these factors using functional testing (stress and load testing, performance testing). Quality of service requirements set a high quality bar for your application. These requirements contain four default states:

• New: You can create a new quality of service requirement using the Requirements folder in the document library. You can also create a new work item in Team Explorer by right-clicking the Work Items folder.

• Active: Like many other work Items, quality of service requirements are by default "Active." The requirements are originally designed by a business analyst. Then the requirements are passed along to the developer team to write the necessary code. The requirements stay in Active mode during the coding process.

• Resolved: You can resolve a quality of service requirement when code has been written to implement it. A tester is then assigned to test the code to determine whether it adequately fills the requirement.

• Closed: Once a quality of service requirement passes testing, it is assigned the "Closed" status. A requirement can also be Removed, Deferred, or Split into two or more requirements.

For example, a load test might have to be performed for every build of a web application. This requirement might be enforced constantly throughout the development of an application. Once the load tests have been designed, they may be transitioned to "Resolved." Once the load tests have been performed and have passed testing, you can "Close" and complete the requirement.

Scenario

Scenarios take the place of use cases in MSF for Agile Software Development. They are built to determine a set of goals for each defined persona you establish in your project. Scenarios are used because they represent smaller pieces of functionality, a requirement to keep the iterations small. You must then figure out how to prioritize the list by looking at the outcomes. Will the customer be dissatisfied? If so, how much? Scenarios may take into consideration quality of service requirements.

Important

Scenarios should be written jointly with the customer wherever possible.

For each goal, create a list of successful and unsuccessful scenarios. In other words, try to figure out how the persona will reach the goal. These scenarios will be recorded as work items in Team System and will serve to help you anticipate problems and bottlenecks.

The scenario work item has four states:

• New: You can create scenarios using the Quality of Scenarios list found in the Requirements folder of your project. You can also create a new work item in Team Explorer by right-clicking on the Work Items folder.

• Active: Scenarios are usually designed by business analysts and are "Active" by default. They are then assigned to the development team and implemented as code.

• Resolved: Once the scenario has been coded, the developer (or developer lead) will change the status to "Resolved." It is then reassigned to a tester to confirm that it meets all criteria.

• Closed: Once testing is successfully completed, the tester can close a scenario. It can also be closed if it's Removed, Deferred, or Split into two or more scenarios.

Risk

A risk is a new work item type introduced in Team System (risk is not usually measured in the Agile development process). It can be defined as an outcome that can adversely affect a project. Each role within a development team should submit risks as work items, including as much information as possible to identify and mitigate it. It is important that you establish an open environment within your team to enable all members of your team to submit risk documentation.

A risk can be technical or organizational in nature. As you will learn, risk mitigation will help lower special cause variation within your project. The risk work item has three states:

• New: Any team member can create a work item once a new risk has been identified. A full detailed description of the risk should be written down, including negative effects and the impact to the project. Depending on the source of the risk, it should be reassigned to another team member. For example, solution or architectural risks should be assigned to the solutions architect.

• Active: By default, a new risk is set to "Active" once it is created. An active risk can pose a problem to your project and should be dealt with.

• Closed: A risk that has been dealt with is classified as "Closed." It should be re-examined during periodical team operations or risk reviews.

Note

Risk can be found in the Identify Risk and Create Architectural Prototype workstreams.

Task

Tasks are created within a project to assign and complete work. Tasks can be specific to each role, such as development tasks and test tasks. When you create a task work item, it will be formatted (fields will be added and omitted) depending on the corresponding role. A task work item has three states:

• New: You can create a new task work item in Team Explorer by right-clicking on the Work Items folder. There are three varieties of tasks: Development, Test, and Generic.

• Active: Once a new task work item is created, it is automatically set to "Active." The Active status denotes that there are work requirements that need to be completed. Tasks can be reassigned to other team members depending on the role.

• Closed: The "Closed" state means a task has been completed. Development tasks are completed once code updates have been implemented. Test tasks are completed when all tests have been executed for a specific feature or component.

Reports

Reports provide you with valuable metrics to measure the success and health of a software development project. In Team System, reporting is tightly integrated with the Team Foundation version control repository, the work item database, Team Foundation Build, and the test components of Visual Studio 2005. In MSF, reports provide snapshots of your project progress within each iteration; a progress meter on quality metrics; and a means to track and measure the effectiveness of each role within your software development team. For more information about reporting, please refer to Chapter 19 and the MSF for Agile Software Development documentation.