Working with Microsoft Visual Studio 2005 Team System (Pro-Developer)

MSF for Agile Software Development

MSF for Agile Software Development is a prescriptive implementation of the MSF 4.0 metamodel designed for rapid development using adaptive techniques. This methodology uses best practices from the emerging agile development movement.

Roles

MSF for Agile Software Development implements the Team Model by prescribing a team of peers that represent all the constituencies involved in the project. Each team member assumes one or more of the following roles:

• Business Analyst

  Defines the business opportunity and recommends the solution to realize the opportunity. The business analyst works with the customers and other stakeholders to understand their needs and goals and translates those into persona—fictitious characters that represent the cross-section of typical users, described in terms that are relevant to the project.

• Project Manager

  Delivers business value within the agreed schedule and budget. The project manager is charged with planning and scheduling duties, including developing project and iteration plans, monitoring and reporting status, and identifying and mitigating risk. The project manager is also expected to consult with business analysts to plan scenarios and QoS requirements for an iteration, consult with architects and developers to estimate work, consult with testers to plan testing, and facilitate communication within the team.

• Architect

  Ensures success of the project by designing the foundations of the application. This includes defining both the organizational structure of the application and the physical structure of its deployment. In these endeavors, the architect's goal is to reduce complexity by dividing the system into clean and simple partitions. The resulting architecture is extremely important because it not only dictates how the system will be built going forward, but it also establishes whether the application will exhibit the many traits that are essential for a successful project. These include its usability, whether it is reliable and maintainable, whether it meets performance and security standards, and whether it can be evolved easily in the face of changing requirements.

• Developer

  Implements the application as specified within the planned time frame. The developer is also expected to help specify the features of physical design, estimate the time and effort to complete each feature, build or supervise implementation of features, prepare the product for deployment, and provide technology subject-matter expertise to the team.

• Tester

  Discovers and communicates problems with the product that could adversely affect its value. The tester must understand the context for the project and help others to make informed decisions based on this context. A key goal for the tester is to find and report the significant bugs in the product by testing the product. Once a bug is found, it is also the tester's job to accurately communicate its impact and describe any workaround solutions that could lessen its impact. The tester makes bug descriptions and the steps for re-creating the bugs easy to understand and follow. The tester participates with the entire team in setting the quality standards for the product. The purpose of testing is to prove that known functions work correctly and to discover new product issues.

• Release Manager

  Manages the rollout of the product. The release manager coordinates the release with those constituents who are responsible for operations or media control. The release manager also creates a rollout plan and certifies release candidates for shipment or deployment.

NOTE

On smaller teams, it might be necessary for team members to assume multiple roles.

Work Item Types

A work item is a database record that Visual Studio 2005 Team Foundation uses to track the assignment and state of work. Each work item is assigned to a work item type. MSF for Agile Software Development includes the following items:

• Scenario

  This item records a single path of user interaction through the system. As team members attempt to reach a goal, the scenario records the specific steps that they will take. Some scenarios will record a successful path; others will record an unsuccessful one. When writing scenarios, be specific. Because an infinite number of possible scenarios exist for all but the most trivial systems, you must be discerning when deciding which scenarios to write.

• Quality of Service (QoS) Requirement

  This item documents the required characteristics of the system, such as performance, load, availability, stress, accessibility, serviceability, and maintainability. These requirements usually take the form of constraints on how the system should operate.

• Task

  This process template item communicates the need to do some work. Each role has its own requirements for a task. For example, a developer uses development tasks to assign work derived from scenarios or QoS requirements to component owners. The tester uses test tasks to assign the job of writing and running test cases. A task can also be used to signal regressions or to suggest that exploratory testing be performed. Finally, a task can be used generically to assign work within the project. On the work item form, certain fields are used only in cases when a task relates to a particular role.

• Bug

  This item communicates that a potential problem exists or has existed in the system. The goal of opening a bug is to accurately report bugs in a way that allows the reader to understand the full impact of the problem. The descriptions in the bug report should make it easy to trace through the steps used when the bug was encountered, thus allowing the bug to be easily reproduced. The test results should clearly show the problem. The clarity and understandability of this description often affects the probability that the bug will be fixed.

• Risk

  This item documents and tracks the technical or organizational risks of a project. When concrete action is required, these risks might translate into tasks to be performed to mitigate the risk. For example, a technical risk can set off an architectural prototyping effort. The team should always regard risk identification in a positive way to ensure contribution of as much information as possible about the risks it faces. The environment should be such that individuals identifying risks can do so without fear of retribution for honest expression of tentative or controversial views. Teams creating a positive risk management environment will be more successful at identifying and addressing risks earlier than those teams operating in a negative risk environment.

Work Streams

Each work stream is characterized by entry criteria, activities, and exit criteria. MSF for Agile Software Development defines the following work streams by role:

Business Analyst

• Capture project vision

  Getting a project started requires the clear establishment of the project vision. Capturing and communicating this central vision is the most important element to keeping a project focused. During the project, this vision might change as a result of the business or project climate. If change occurs, you'll have to realign the project to the new vision. From the vision, you begin to understand who the users will be. Usage patterns and goals of these users will be captured using personas. You'll also understand whether the project is driven by date or by content. The vision and its related activities create the solid foundation on which a project can be built.

• Create a scenario

  Scenarios capture the functional goals of the system. To find these goals, examine the unique needs for each persona of the system. These goals can be initially listed and later written as scenarios. For each of these goals, also consider the scenarios that might result from unsuccessful or nonoptimal attempts to reach the goal. Scenarios are created through brainstorming, lifestyle snapshots, or exploratory testing, and they are added to the scenario list. Scenarios are prioritized and written when they are scheduled for an upcoming iteration. Scenario creation is complete when all the scenarios scheduled for delivery in an iteration or architectural prototype are written.

• Create a QoS requirement

  Quality of Service requirements are used to capture nonfunctional requirements or constraints on the functionality of the system. QoS requirements must be precise and not subjective in their definition. The requirements are identified, prioritized, and if scheduled for the current iteration, written.

Project Manager

• Plan an iteration

  To plan an iteration, determine the right balance of scenarios, QoS requirements, and bug allotments for the upcoming iteration. The amount of work that can be done in an iteration is limited. The scenarios and QoS requirements with the biggest business value are prioritized for inclusion in the current iteration. An initial iteration plan is created using the estimated scenarios and QoS requirements. After the scenarios and QoS requirements are part of the iteration plan, they are written up by the business analyst as scenarios. Developers and testers then divide the scenarios into tasks and create more detailed estimates. The new detailed estimates are used to load balance the tasks assigned to developers. The iteration planning meeting brings together the appropriate business analysts, project managers, and developers to finalize the iteration plan.

• Guide project

  To guide a project, progress must be constantly monitored and reported. Changes should be made as necessary to keep the project on track. The progress being made within an individual iteration as well as the overall project progress should be tracked. Bugs and risks need to be identified and assigned a priority.

• Guide iteration

  Similar to guiding a project, but just for a particular iteration. Within the iteration, the project manager must monitor the progress of those tasks relating to the scenarios and QoS requirements of that iteration.

Architect

• Create solution architecture

  A good architecture has a clean and simple internal structure for the major elements of the application. A simple structure reduces the complexity of the application. The architecture can define structural elements that enable the application to better handle changing requirements and allow areas of the application to develop independently. Good architecture also takes advantage of layering to increase structural reliability and decrease time to market. When technology risks pose a threat, prototyping can be used to mitigate those risks and provide greater insight. Finally, security and performance are architectural concerns for which work must be done over the entire system.

Developer

• Implement a development task

  A development task is a small piece of development work that stems from a QoS requirement or scenario. Implementing a development task involves adding the appropriate new functionality to the architectural form of the system. After the development task has been completed, it must be unit-tested, reviewed, code-analyzed, integrated, and checked in to the existing code base. The scenario or QoS requirement is then passed on to test.

• Fix a bug

  A bug indicates a potential need for corrective work on already implemented work product—typically source code. Fixing a bug might result in no action beyond a change of state of the bug, or it might result in changes to code. To prevent bug fixes from disrupting working code, the bug-fixing process must be systematic and controlled. After a bug fix has been completed, the changed code must be checked against the design and coding guidelines, unit tested, reviewed, integrated, and checked in. The bug owner follows all code requirements that pertain to the affected code, as well as the design concepts and guidelines that drove the implementation. Failing to do so can cause the “fix” to be worse than the original problem.

• Build a product

  A build compiles all new changesets and existing code into a single product. However, when a new set of changes is checked in to the build, it must be acceptable. The changeset must compile and pass build verification tests. Ensuring that the changesets added to the build do not cause problems is part of accepting a build. Each build contains a set of build notes that outlines all the new changes.

Tester

• Test a scenario

  A scenario is divided into test tasks as well as development tasks. These tasks are assigned to testers to develop and run test cases. The assignment of a scenario to test indicates that the functionality has been integrated into a build and is ready to be tested. Validating that a build reflects the functionality envisioned in the scenario requires an understanding of the scenario and its boundary conditions. Validation tests must be written to cover the complete functionality and the boundary conditions of the scenario. Validation tests are run until none is blocked. Bugs are created to report any bugs that were found.

• Test a QoS requirement

  The assignment of a QoS requirement to test indicates that the build reflects the constraint and is ready to be tested. Validating that a build reflects the constraints envisioned in a QoS requirement requires knowledge beyond the constraint. In many cases, scenarios are attached to the requirement to show the areas to be constrained. Testing a QoS requirement demands that performance, security, stress, and load tests be completed and that none be found to be blocked. Based on the test results, bug reports are created to document the issues discovered.

• Close a bug

  A bug can be closed for several reasons. Once closed, no more work is done on the bug during the current iteration. Valid reasons for closing a bug include that it is fixed, deferred to another release, demonstrated invalid, not reproducible, or a duplicate of the bug already logged. Closing bugs usually occurs during triage or to verify a fix.

Release Manager

• Release a product

  Releasing a product marks the end of an iteration of application development. If the project is date driven, allow time to “finish” the product. A rollout plan for the release is created. The release process and corresponding rollout plan differ depending on the type of product and whether it is for internal or external consumption. For externally released software products, marketing effort and sales collateral are often included. Internal systems require training and operations support. Each of these cases requires a different rollout plan.

Disciplines

Disciplines are non-technical areas of expertise that span the entire project and concern all members of the team. MSF 4.0 includes two disciplines: project management and risk management.

• Project management

  A project is a venture of finite duration—it has a clearly defined beginning and end. Project management refers to the set of skills required to plan and control a project. These skills include planning, scheduling, managing scope, and managing cost. Although the Project Manager role assumes primary responsibility for project management, all the team members are expected to participate.

• Risk management

  The MSF risk management discipline emphasizes taking a proactive approach to dealing with uncertainty, assessing risks continuously, and using risks to influence decision-making throughout the life cycle. The discipline describes principles, concepts, and guidance together with a five-step process for successful, ongoing risk management: identify risks, analyze risks, plan contingency and mitigation strategies, control the status of risks, and learn from the outcomes.

Qualities of Service

Quality as it relates to software takes many forms. MSF 4.0 organizes software quality into three categories: security, performance, and user experience. Everyone on the team should be conscious of the QoS requirements for the project and use these requirements to inform design, implementation, testing, and deployment.

• Security

  This QoS becomes ever more important as software evolves into a distributed architecture. Security starts with threat modeling, which then drives the requirements for authentication, authorization, validation, and other security measures.

• Performance

  This QoS relates to several aspects of performance. The most obvious performance considerations involve responsiveness, performance under stress, and availability. Performance can also include other aspects, such as serviceability and maintainability.

• User experience

  This QoS relates to the quality of the application from the user's point of view. The user experience starts with overall ease of use, or usability. The user experience is also affected by the quality of the user documentation, training, and support.

Governance and Tracks

Governance involves the control of time and money relative to the flow of value for a project. MSF defines five governance checkpoints, each of which focuses on a specific question to answer. The activities and work streams leading to the checkpoints are called tracks. It's important to note that these tracks are not the same as the cycles within the MSF 4.0 Process Model shown in Figure 8-5. Rather, tracks group the activities that lead to governance checkpoints. Each track can span multiple iterations. Tracks also overlap and interact as continuous feedback occurs among activities in different tracks.

The MSF for Agile Software Development tracks are defined as follows:

• Envision

  The envision track addresses one of the most fundamental requirements for project success—unification of the project team behind a common vision. The team must have a clear vision of what it wants to accomplish for the customer and be able to state it in terms that will motivate the entire team and the customer. Envisioning, by creating a high-level view of the project's goals and constraints, can serve as an early form of planning. As such, it typically occurs during the setup iteration.

• Plan

  The plan track is where the bulk of the planning for the project is completed. Within this track the team prepares the functional specification, works through the design process, and prepares work plans, cost estimates, and schedules for the various deliverables. Each iteration also includes a planning cycle, where the team revisits the plan, makes adjustments as needed, and performs the planning specific to the iteration.

• Build

  The build track is where the team accomplishes most of the construction of solution components (documentation as well as code). However, some additional development work might occur in the stabilization track in response to testing. The build track involves more than code development and software developers. The infrastructure is also developed during this track, and all roles are active in building and testing deliverables.

• Stabilize

  The stabilizing track is where the team conducts testing on a solution whose features are complete. Testing during this phase emphasizes usage and operation under realistic environmental conditions. The team focuses on resolving and triaging (prioritizing) bugs and preparing the solution for release.

• Deploy

  The deploy track is where the team deploys the core technology and site components, stabilizes the deployment, transitions the project to operations and support, and obtains final customer approval of the project. After the deployment, the team conducts a project review and a customer satisfaction survey.

• Continuous

  These other five tracks are analogous to phases of a software development project. Continuous involves work streams and activities that occur throughout the duration of the project. These work streams and activities can occur in any iteration, from startup to release.

NOTE

Although these tracks may look a lot like the concept of phases from MSF 3.0, they have been completely reworked and are similar only in name.