What Can You Customize?
Virtually every aspect of Visual Studio Team System can be customized to some degree, and we’ve already explored many ways you can do this, such as creating new work item queries and customizing areas and iterations. This chapter expands upon the most common customization scenarios, which were briefly introduced in the previous chapters. The following sections provide you with an overview of what you can customize in Visual Studio Team System . The details of how you can perform these customizations can be found later in this chapter. Figure 7-1 depicts the most common customizations of Visual Studio Team System from a project manager’s perspective.
Figure 7-1: Opportunities for Visual Studio Team System customization
Work Item Customization
Work item customization is perhaps the most common type of customization you can make to Visual Studio Team System. As defined in earlier chapters, work items are specified by an XML file called a work item type definition. This open and declarative way of specifying work items provides you with the opportunity to customize virtually every aspect of a work item and provides the ability to create your own work item types and add them to Visual Studio Team System. In fact, one of the most common work item customization tasks many project managers make is to add new fields to a work item type definition to capture additional information that may be relevant to your project or organization. For example, suppose you are using Visual Studio Team System to manage bugs for your company’s line of products, and you would like to track which customer discovered each recorded defect. In this case, you could add a Customer field to the Bug work item that would allow your team to capture this information. You could even display a list of all of your customers in a drop-down list to make it easier for your team to enter the appropriate value.
Another common work item customization is the modification of existing work item fields. There are many reasons why you might want to change various aspects of a work item field, such as its description, default values, drop-down list values, prohibited values, or even help information that describes the field and how to use it. You might also want to provide some additional rules that govern how each field is used, such as making a field required or read-only for certain groups of users. You will learn more about the details of work item field customization later in this chapter.
Another common work item customization is the modification to the workflow definition that each work item type describes. Each default work item type released with Visual Studio Team System as part of the default set of process templates specifies a certain set of workflow states and a set of paths that specify valid transitions between those states. For example, the Bug work item from the MSF CMMI process template has four states: New, Active, Resolved, and Closed. In your organization, you might want to have a fifth state called Validate, which could be used by the testing department to track which bugs must be manually verified prior to marking the bug as resolved, which is equivalent to transitioning the bug to the Resolved state. The work item type definition file will allow you to create new states and transitions that will help to accommodate this need.
The XML that specifies a work item also provides information regarding the layout of the fields when the work item is displayed from within Visual Studio. For example, the work item definition will specify the order of each of the fields displayed, the location of each field, the available field tabs, and field labels. Modifying the layout information contained within the work item definition XML files will allow you to control exactly how each field is placed on the screen, modify the structure and content of existing tab pages, and even create your own tabs to better organize your custom fields.
You can even create your own work item types and add them to existing Team Projects or to project templates to be used for future projects. Work items are simply structures that allow you to track the assignment and state of work. Microsoft conveniently includes a few definitions as part of the process templates installed by default in Visual Studio Team System; however, you can use the same very powerful feature to create different types of work items. For example, you might want to create a Persona work item type that will allow you to capture information about the users of your system. A Glossary work item type is another that is very commonly added to projects. Generally, if you need to track a list of items, you can typically represent each item as a work item in Visual Studio Team System. Figure 7-2 shows a work item that was created using a custom work item type called Glossary.
Figure 7-2: Custom work item type
Work Item Query Customization
Every method of accessing work item details requires a work item query, and so it is important that the entire team understands how to customize existing work item queries in addition to creating and sharing new ones. In fact, during the course of most projects, you will want to add new work item queries for your team that will make it easier to find and work with the growing database of work items. Work item queries provide the criteria for the work item search operation and establish the conditions that must be met for a work item to be returned as a query result. For example, the Mitigation Action Status query returns a list of work items that represent all mitigation actions in the Team Project. The criteria specified in the Mitigation Action Status query are listed in Table 7-1.
Using the Mitigating Action Status work item query as an example, you might want to create a new work item query called Mitigating Action Assigned to Me, which would be modified to add an additional query criterion, as shown in Table 7-2.
| And/Or | Field | Operator | Value |
|---|---|---|---|
| Team Project | = | @project | |
| And | Work Item Type | = | Task |
| And | Task Type | = | Mitigating Action |
Open table as spreadsheet | And/Or | Field | Operator | Value |
|---|---|---|---|
| Team Project | = | @project | |
| And | Work Item Type | = | Task |
| And | Task Type | = | Mitigating Action |
| And | Assigned To | = | @Me |
| Note | Notice the use of @Project and @Me in the work item query definition. These are examples of special parameters that are derived at the time the query is run. This will be discussed in more detail later in this chapter. |
Work item query definition is typically an evolutionary process starting with the default work item queries provided to you out of the box by Visual Studio Team System and evolving based on the needs of your project team. Every time you need to view a different subset of work items, you need to either modify an existing work item query or create a new work item query with specific constraints that specify the details of the work items you would like to see. When you create new work items queries, you will have the ability to save the work items queries for the entire team to access or in a private area called My Queries, which is accessible only to you. If you have the appropriate permissions, you can also make copies of existing work item queries and change the names of existing queries.
Default Work Items
You might have noticed that whenever you create a new Team Project, you get a number of work items automatically created for you. These default work items are included within the process template you used to create your new project, and because of this, you will be able to modify the default work items list by changing the underlying process template definition. Changing default work items is essential when you want to integrate your own processes and methodologies into Visual Studio Team System. Default work items represent work that should always be performed when you are working on a project of a particular type. You might want to completely replace the MSF process templates’ default work items with your own, perhaps to handle certain required organizational documentation, which might be unique to a particular project.
Classification Customization
Classifications are very important to work items and ultimately work item reporting because they provide ways in which you can categorize work item instances by specifying either a functional area or iteration that reflects blocks of time on your project. Classifications are easily modified from Team Explorer; however, you can also modify the default set of areas and iterations your projects will have after you create them. Once again, process templates specify the default set of areas and iterations that will be created for your project. Suppose that you wanted every project to be standardized on a pre-established set of areas such as User Experience, Business Facade, Software Interface, and Application Services (as depicted in Figure 7-3). All you would need to do is modify the default classification settings within a process template, and every new project that is based on the modified process template will have these same initial classifications.
Figure 7-3: Example of area classification customization
Report Customization
The reports that Visual Studio Team System provides are really cool, and just like virtually every other aspect of Visual Studio Team System, they are completely customizable. Some, however, are sufficiently complex that they might require a senior developer to make certain changes to them. Nonetheless, it is actually quite simple to make certain changes, such as adding company logos or additional header and footer information, to these reports. Report definitions are referenced from within process templates but are actually constructed with Visual Studio’s Report Designer for Microsoft SQL Server 2005. There are really two ways that you can modify reports: within a process template or after the report is deployed as part of your project. If you modify report definitions after you create your Team Project, note that the modifications will not be reflected in any new projects you create. For report customizations that you want to be reflected in all new projects, perform the customizations on the report definitions stored within the process template definition. Because Visual Studio Team System uses SQL Server 2005 Reporting Services to manage reports, you can also use the same tools Microsoft uses to create your own reports from the rich data stored within the Visual Studio Team System data warehouse.
| Important | To build even simple reports based on the data contained within the Visual Studio Team System data warehouse, you will need a deep understanding of the data and structure of the data warehouse. This book does not cover use of Visual Studio to author complex reports or details on the complex underlying structures of the Team Foundation Server data warehouse. |
Source Code Control Customization
There are many customizations you can make to the Source Control features of Visual Studio Team System. Such modifications include making check-in notes to help capture additional metadata information regarding a check-in operation and source control policy settings, with which you can choose to have Visual Studio Team System check that certain conditions are met prior to the check-in operation, such as requiring the association of a check-in operation to a work item. Suppose, however, that you wanted to make sure that all code that enters the source repository has a copyright statement at the top of every file containing source code in your project. You can achieve this by creating new source control policies that implement rules specific to your environment and your needs. The creation of new source code policies is a job for a senior developer who is familiar with the Visual Studio Team System application programming interface (API) and is not covered in much detail in this book.
Default Security Customization
By default, all Visual Studio Team System projects specify a certain set of security groups and settings. These settings might not be appropriate for your project or your organization. You can choose to change the default project security settings after you create your Team Project, or you can modify the process template that specifies them in the first place. Modifying the default security configurations for new projects might be required if you want to have different roles (such as project managers, developers, testers, and project administrators) having different sets of permissions for every new project. In that case, you can create new roles (also known as groups) with specific security rights within a process template, and every new project will have these enforced automatically. Modifying security settings, however, is likely not related to the role of a project manager and is not covered extensively in this chapter.
Project Portal Customization
Visual Studio Team System uses Microsoft Windows SharePoint Services (WSS) as the project portal, and thus, you will be free to customize each portal according to the functionality of WSS. Visual Studio Team System adds functionality to the portal that you normally would not see in a typical WSS site such as links to Visual Studio Team System reports, a reporting Web part that displays the Remaining Work report on the main page of the WSS site, and links to process guidance, which can provide your team reference information regarding the methodology you chose to use for your project. WSS sites can do so much more than what you see, so much in fact that entire books have been written on the subject. For this reason, we won’t go into a great amount of detail on how to extend WSS sites. Instead, let’s summarize the realm of possible customizations you could make to project portal sites and leave the how for a book that specializes in WSS customizations.
Create custom lists Windows SharePoint Services provides the ability to create SharePoint lists, which act much as work items in Visual Studio Team System. You may want to create lists of information in categories that do not make good sense to store in Visual Studio Team System, such as budget items or contact information.
Rearrange Web parts SharePoint appears through Web parts. You don’t need any programming skills to be able to extensively customize the content and location of these Web parts.
Alter themes Users can change the theme and skin of a site to better represent the culture of the team or project.
Collaborate using Announcement, Links, and Events Users can use Visual Studio Team System to collaborate with team members outside of Visual Studio Team System.
Tools for Customization
A great deal of the customization just mentioned can be performed right within Team Explorer. Other customizations are a bit more complex and will require some technical skills to accomplish. The following is a list of the additional tools you will need to perform the customizations discussed in this chapter:
XML Editor of Choice The process templates used during the creation of new Team Projects provide a number of customization opportunities. Process templates are specified in XML, and you will need to have an XML editor, such as XML Marker or Notepad 2, to make these customizations. XML-editing features and is a good choice if XML requires direct modification.
Visual Studio 2005 For more extensive customizations, code will need to be written to take advantage of the extensive programmatic interfaces in Visual Studio Team System. (This book does not cover any details of this process.)
Process Template Editor The Process Template Editor was originally created by Imaginet Resources Corporation and was intended to make the job of editing process templates less tedious. The Process Template Editor provides an intuitive graphical interface that makes it possible to edit virtually every aspect of a process template. The tool also provides a great deal of template validation to help ensure that you don’t make any mistakes or configure a template in a way that would be inconsistent or in error. In addition, you can use the Process Template Editor to edit live information on your computer running Team Foundation Server, such as graphically editing a work item type in an existing project or adding values to a special server-side list called a Global List. The Process Template Editor is covered in more detail later in this chapter.
The remainder of this chapter provides a detailed discussion of customizations that can be performed by a non-developer. This means that many of the customizations mentioned in this chapter are not be covered. Please note that the following is a list of customizations that may require the aid of a software developer, and for that reason, are omitted from this chapter.
-
Custom source control policies
-
Complex editing of process templates
-
Non-trivial report customization
Important Extensive programmatic customization and extension of Visual Studio Team System can be extremely complex and requires writing code. This book will not address deep extensibility of Visual Studio Team System, but it will highlight opportunities for such extensibility. To get more information about the programmatic interfaces provided by Visual Studio Team System, download the Visual Studio 2005 software development kit (SDK) from https://affiliate.vsipmembers.com/.
Before we continue, it is important to point out that there are two general ways to customize Visual Studio Team System. The first is on existing Team Projects. These customizations are important because they will allow your project team to gradually adapt the features of Visual Studio Team System to meet the changing needs of the project. The second grouping is on project templates. These customizations will not affect any existing project and will focus on new projects based on the modified templates.
EAN: N/A
Pages: 93