Work items are no different than the task lists that are kept in project plans, bug lists, and feature lists. What is different is how the work item tracking system is integrated with the rest of Visual Studio Team System.
Team Explorer Window
Visual Studio Team Editions (Architect, Developer, Test, and Team Explorer) include the capability to connect to a Team Foundation Server (TFS). Users can add Team Projects to TFS, using their Team Explorer window.
The Team Explorer window allows the user to view and create new work items (see Figure 1). The work item data and the various work item types are defined by your chosen methodology template. When creating a new Team Project, the option is given to select a methodology template to use for the project. For example, selecting MSF for Agile Software Development creates several standard work items as part of the process. In addition, MSF for Agile Software Development makes use of five distinct types of work items: Scenario, Task, Quality of Service Requirement, Bug, and Risk. The Team Explorer window makes up the Team Explorer application, also referred to as the Team Foundation Client.
Figure 1. Add new work items
Project Management with Work Items
Project managers are probably the most familiar with the concept behind work item tracking. A good portion of their job entails creating and managing various tasks. They are usually responsible for mapping out all the tasks that need to be completed on a development project. The work item tracking system in Visual Studio Team System will allow them to take the work they currently do, and interact more efficiently with the rest of the team.
As part of the creation of a new Team Project, the project manger will select the appropriate process template. The process template will provide the definitions for the work item types, the initial work item list for the project, and other supporting information such as document templates and process guidance documentation. The selection is based on the type of project being undertaken. For example, a small informal Intranet Web application may be based on a less formal process, such as MSF for Agile Software development, whereas a more intensive project such as an airplane flight control system will require a more formal process, such as MSF for CMMI Process Improvement. The selection of the process template is important, because it can't be modified during the project. Future versions of the software can be based on different process templates and, of course, the contents of the work item list and document libraries will be modified during the project.
Project managers who install Team Explorer (formerly called Team Foundation Client) will be able to connect to a Team Foundation Server and import, as well as export, work items from either Microsoft Excel or Microsoft Project. Prior to installing Team Explorer on his or her computer, the project manager will want either (or both) Microsoft Excel or Microsoft Project installed with the optional Microsoft .NET interoperability components. Once installed, there will be a new menu option added to either (or both) Project or Excel, called Work Items (see Figure 2 for an example of this). This menu will allow the project manager to connect to a Team Foundation Server and download work items from any project that they have access to on the server. Once they do this, they can add additional items, change resource assignments, and complete the project plan. When they are ready, they can synchronize their changes with the Team Foundation Server using the Publish Changes option. Any assignments they make to individuals who are using the work item tracking system will be seen by those individuals when they run the My Work Items query from within Visual Studio.
As team members complete tasks, they mark those tasks as complete, using Visual Studio or Team Explorer. The project managers will receive this updated status the next time they synchronize with the Team Foundation Server.
Microsoft Project Integration
Installing Visual Studio Team System or the Team Explorer application provides extensions for Microsoft Project and Microsoft Excel. Using Microsoft Project, a project manager can retrieve data from Team Foundation Server, use Microsoft Project to manage and plan work, and then publish the updates back to the work item database for consumption by other team members. Figure 2 shows the Microsoft Project extensions that allow synchronization with work items.
The Microsoft Project file itself will generally be stored in a document library in the project team site. This will allow basic version control of the file, as well as make it available for other users to review.
Figure 2. Work item integration with Microsoft Project
Business Analysis with Work Items
Business analysts can also become more integrated in the development process by having their work managed through the same work item tracking system as the rest of the team. The various types of documents that are produced by business analysts should be stored on the team project portal. For instance, the creation of a requirements document could be a task assigned to a business analyst. Once compete, that document can be stored within WSS, and the business analyst would mark the work item as completed. A new work item can be created to actually implement that requirement, and a link can be set up from the work item to the actual requirements document on the WSS site. This allows the developer assigned the task to quickly navigate to and review the associated documentation. In order for business analysts to interact effectively with the work item system, they will need to install Team Explorer and have a client access license for the Team Foundation Server.
Developers
Developers and testers will be greatly impacted, from a workflow perspective, by the introduction of work item tracking. The system was designed to make the use of work items by developers as seamless as possible. Rather than being notified by e-mail, spending hours in planning and status meetings, or looking at the project plan, the developers will receive their work assignments from within Visual Studio. They will simply use the Team Explorer window to run the My Work Items query (Figure 3).
Figure 3. Work item list in Visual Studio 2005 Team Edition for Software Developers
Developers can begin their day by viewing their work items. As they work on tasks, they can update the status of their work items in two different ways. First, they can edit the work item information directly from within Visual Studio by simply selecting the work item they wish to edit from the list of work items. In this case, they can directly enter data such as status updates, or modify any other field exposed in the work item. Depending on process customizations, individual fields may be protected in such a way that other roles can set the work item field values but development can only read them, as may be the case when a bug work item is prioritized by a project manager or tester. Likewise, some fields may be modifiable by developers and not by other roles. Figure 4 shows a sample work item detail screen including a custom field Start Date added to the default MSF for Agile Software Development process. Additional information on customizing work items in Visual Studio Team System is provided later in this document.
Figure 4. Work item details in Visual Studio 2005 Team Edition for Software Developers
The second way to update the status of a work item is as a side-effect of the check-in process. When combined with Team Foundation Source Control, several powerful capabilities are added. Depending upon the policies defined for the Team Project, the check-in process may allow or require developers to link a work item to a changeset (a collection of files checked in as a group) during the check-in process. As developers complete their coding tasks, they simply associate code check-ins with work items.
For example, imagine that a developer has a coding task called "implement customer feedback form." When the developer completes this task and checks in his or her work, he or she has the option of associating that work item to the checked-in code. All of the different files that are checked in are called a changeset, and the work item will be associated with the changeset, not the individual files. The work items can simply be associated, or marked as resolved. Figure 5 provides a sample of how the work item is associated with the changeset during check-in.
Figure 5. Associating work items at check-in
This is a simple process and allows the work item status to be automatically updated. This updated status can then be used by the project managers when they synchronize their project plan. The associated work items will also be used in build reports that can be automatically generated and distributed as part of an automated build process using Team Build. This will allow testers to know precisely what items they should be testing in a new build.
Work Item Check-in Policy
Work item associations can be implemented and enforced in check-in policies. Check-in policies enforce certain behavior when team members attempt to check items into the source control system. One of the standard policies that can be enabled would require developers to associate a work item with all code check-ins. This ensures that all development efforts are tracked and visible. There is an option of overriding the policy, and notification can be set up to alert the project manager (or someone else) of the override.
Figure 6. Adding check-in policies
Bugs and Issues as Work Items
Using classic development practices, developers and testers perform work from several different sources. The project plan schedules work such as developing code and writing test plans. Separate lists are kept and scheduled outside of the project plan, to handle defect tracking, enhancement requests, issues, and risks. Project managers may set aside buckets of time to allow team members to work on these other lists, or they may create separate project plans. Regardless, the management of different types of work for the same development resources is cumbersome and error prone.
Since the work item tracking from Team System allows flexible and customizable tracking of all types of work in a single repository, managing these different types of tasks becomes easier. Different types of work items can be managed separately through different work item queries. However, since they are in the same Team Project, a work item list for a developer could have new development tasks, research tasks related to project risks, and bug fix tasks; all of them could be prioritized side by side and worked from a single list.
Testing
As implied in previous sections, testers also get significant integration in the overall development lifecycle as a result of work item tracking. Testers using Visual Studio Team Edition for Software Testers have full access to Team Explorer to view their own work items. For instance, many projects require the creation of manual test cases. These manual tests are created and managed in Visual Studio Team Edition for Software Testers. What test cases need to be written, and the status of those test cases, can be tracked by the work item tracking system. The project manager can then synchronize in order to track and manage the efforts of the test team as well as the developers. Testers follow the same process as developers do, and work on the tasks delegated to them through the work item tracking system. The manual test cases they develop would be checked into source control and can be associated with work items in the same fashion as developer code.
In addition, testers are able to review build reports to find out what features are ready to test. As developers complete development tasks and associate their code check-ins with work items, those relationships are stored by the Team Foundation Server. During the build process, the status of these work items can be updated to indicate that they are completed and included in the build. Those items included in the build are ready for test. By running a build report, a software tester will know exactly which work items they should focus their testing efforts on. Those work items could be requirements, bugs, or some other type of task.
This, however, is just the beginning. As testers discover problems in the system, they can report these back into the Team Foundation Server, using work items. By issuing a "Bug" or similar custom work item, the tester can record work that needs to be done. These new "Bug" tasks can be routed to a development lead, a project manger, or the appropriate developer, as specified in the process templates. In addition, the tester can set up a work item relationship so that the bug work item is connected to the original work item that he or she was testing against.
When the developer receives the work item assignment and addresses the defect, he or she continues the workflow. The developer's resolved "defect" work item would appear in build reports so that the test team can verify the fix. Since Team Foundation Server is acting as a back end for this entire process, requirements, development tasks, defect reports, and problem resolutions can all be tied together. These items can be traced and reported on with minimal effort from the team members.
Reporting and the Work Item Database
An important aspect of Visual Studio Team System and the Team Foundation Server is the storage of work items. All work item data is maintained by Team Foundation Server in a Microsoft SQL Server 2005 database. In addition to the flexibility, stability, and scalability of this approach, there is a tremendous value from a reporting perspective.
As a result of creating a Team Project based on a specific process template, the project portal exposes appropriate reports. Individuals who are interested in the status of a development project, but not directly involved, can run reports to get the status of development tasks, bug counts, and any other work item or non-work item reports. This is of great value to business users and IT management. The project portal is a WSS team site and contains a Web part that allows viewing of reports created in SQL Reporting Services. The reports available on the site can be customized through the methodology templates.
Work Item Customization
The process templates provided by Visual Studio Team System are highly customizable. Individual organizations and groups are able to modify almost all aspects of the process to be compatible with their own requirements. In fact, some organizations will want to create multiple types of custom process templates tailored to different types or sizes of development projects.
At a high level, the process template architecture provides customization of the following areas:
- Classification Structure Service (CSS)—Defines the structure for team projects, including the iterations defined for the project lifecycle and the project hierarchy.
- Group Security Service (GSS)—Defines the initial groups and permissions for the process templates.
- Reports—Defines the standard reports provided by the process.
- Source Control (SCC)—Defines the permissions and notes available for source control.
- Windows SharePoint Services (WSS)—Defines the document templates, document libraries, and the process guidance.
- Work Items (Currituck)—Defines the type and characteristics of work items, work item queries, a default list or work items for new Team Projects, and the mapping of work items to Microsoft Project.
In addition, you can actually change the contents of the work item definitions. For example, you may decide that a specific work item type needs additional attributes to make it useful in your environment. Adding a Severity field to your "Defect" work item type is as easy as editing an XML file. In addition, you may specify valid values for your new field (for example, Very Severe and Unimportant). You can also configure how the field is visible, and the permissions required for modifying the value. Additionally, there is support for basic workflow that will allow the Team Foundation Server to automatically impact the value of the field as your work items move through their lifecycle.
As an example of the different fields that are commonly associated with work items, the following list contains the default fields for the "Bug" work item defined by MSF for Agile Software Development, beta 2: Id, Title, Assigned To, Area Path, Iteration Path, History, Reason, Changed Date, Changed By, Created Date, Created By, Summary, Issue, State Change Date, Activated Date, Activated By, Resolved Date, Resolved By, Closed Date, Closed By, Priority, Triage, Test Name, Test Id, Test Path, Found In, and Integration Build. It is nice to note that with all of the fields that may hold data for this work item, many of them are automatically captured during standard processing, without extensive data entry for team members.
1 comment:
Excellent Blog!!!
I have posted a Quality Attribute Factor Table here:
QA Factor Table
A Quality Attribute is the same as the 'Quality of Service Requirement' shown above. It may help in showing the goals of compiling them.
Post a Comment