How effectively you can manage the day-to-day operation of your team is a crucial element to achieving success with any software development effort. Team System offers work items to help you get a handle on the progress of the entire team without having to call meetings. You can also get a handle on metrics such as bugs, requirements, and milestone slips.
Before you can start working with a project, you must first connect to your Team Foundation Server. The Team Explorer enables you to connect to different instances of Team Foundation Server and manage the associated projects. The easiest way to connect to Team Foundation Server is by clicking Tools Connect to Team Foundation Server. If the Team Explorer isn't showing up, you can bring it up by clicking View Team Explorer.
Once you choose to connect to the server, a window will appear to help you manage your server and Team Projects. Figure 19-6 shows the Connect to Team Foundation Server window. Notice that the team projects have checkmarks next to them — this enables you to narrow down the projects you want to load in the Team Explorer tree view pane (especially useful if you have a ton of Team Projects per server).
To add a new server to the list, click the Servers button. A new window will appear (shown in Figure 19-7) with an Add button. Click the button and enter a server name and URL to complete the process.
Once you have created a project, you need to be able to configure it to fit your needs. To access the project properties, right-click the Project name in the Team Explorer and select Properties.
Team Foundation Server has an extensive set of settings and centralized tools to help you create users and groups with predefined permissions, which enables you to efficiently administer and constrain your team members. For example, as a project manager, the last thing you want to do is allow every member of your team access to every report or give them the capability to create projects on the fly, without your authorization. To configure server security (including creating roles), simply right-click the server name in Team Explorer and select YourServerName Team Project Settings Permissions.
Some processes will automatically create groups when you instantiate a project. For example, the MSF for Agile Software Development process will create a Contributor group right out of the box. Feel free to manipulate the security settings to suit your particular needs. (You will need administrative privileges to view project-level information and to administer builds and test results.) The Project Security dialog box is shown in Figure 19-8.
You can work with two sets of settings: the Project Security settings (shown in Figure 19-8) and the Group Membership settings (which are accessible by selecting Team Explorer YourServerName Team Project Settings Group Membership). Why do you have two ways of manipulating security? Team Foundation Server enables you to assign permissions with three levels of granularity: serverwide groups (also called global groups), project groups, and users.
One of the easiest ways of organizing your work items is by grouping them together logically. In Team System, you can use Iterations and Areas. Most Agile software projects are built in iterative stages. It makes sense to organize work items in iterations, rather than wade through a huge pool of work items for each project.
To access the Areas options, right-click on your project and then select Team Project Settings Areas and Iterations. Click on the Iterations tab and you'll notice that there are already predefined iterations in place: Iteration 0, Iteration 1, and Iteration 2 (see Figure 19-9). You can rename these to whatever you like. For example, you can write in a logical sequence such as Alpha, Beta 1, Beta 2, and Release, or subdivide each project as DEV, PROD and QA (as shown in Figure 19-10).
To associate a work item with an iteration, simply edit the work item and click on the Iteration drop- down menu below the Title, selecting the iteration you want (see Figure 19-10).
Areas offer another way of organizing and classifying your work. Think of Areas as another word for "categories." You can define your own custom areas and assign work items to them. Then it is quite easy to filter the work items by area using work item queries. For example, if you wanted to get all the work items associated with an area called MobileProject, you could enter a query such as the one shown in Figure 19-11.
To access the Areas options, right-click on your project and then select Team Project Settings Areas and Iterations. To create a collection of areas, start by right-clicking on the root area node and selecting New. A sub-node called "Area 0" will appear right below the root node (as shown in Figure 19-12). You can rename this node to whatever you like. As you can see in the figure, you can create hierarchies and relationships between the nodes, which can reflect the way you organize your project outside of Team System.
To associate a work item with an area, simply edit the work item and select the area you want using the drop-down menu in the Classifications section below the title, and then resave your work item. Figure 19-13 shows a screenshot of the Area field on the work item form.
Through the project settings, you can easily configure the source control options. Figure 19-14 illustrates how you can set policies. In the example shown, the source code has to build without errors and go through code analysis before it is checked in the repository.
For a detailed overview of the Source Control options and features, please refer to Chapter 20.
Once your project has been created, a Team Project portal is automatically generated. Currently, the Team System project portals are based on Windows SharePoint Services (which makes them easily extensible using Web Parts). Figure 19-15 shows the layout of a typical project portal (which includes Documents, Process Guidance, and Reports). The front page of the portal includes announcements and links. You can also access some of the important metrics from your project (such as Builds, Remaining Work, Quality Indicators, and Bug Rates).
Project alerts are e-mail notifications sent to the project manager based on triggered events (such as builds, work item changes, and check-ins). Alerts work on a subscription-based system.
For the alerts to work correctly, you must provide Team Foundation Server with a valid SMTP server address and credentials during the server installation process.
You can configure project alerts by clicking on your Team Project title in Team Explorer, and selecting Team Project Alerts. The following window will appear (see Figure 19-16):
There are four default alerts:
My work items are changed by others.
Anything is checked in.
A build quality changes.
A build completes.
To add or edit an alert, simply click on the corresponding checkbox, add in your e-mail address and select whether you want to receive an HTML or Text e-mail. In order to view the target e-mail, you may need to have the proper credentials and note that you can view work items associated to alerts by clicking on the work item type and number in the e-mail
Alerts are defined on a project basis and are sometimes aggregated in one e-mail. You can control on a very granular level what projects should have alerts, and what alerts should be triggered.
You can of course extend and customize the project alerts. Jeff Lucovsky from Microsoft posted some details on how you can do it on his blog: http://www.blogs.msdn.com/jefflu/
Once you create a Team Project, you'll notice that it has a very specific "look and feel" (based on one of the standard templates available in Windows SharePoint Services 2.0). Windows SharePoint Services has a great administrative interface that allows any user to customize the portal to any specification. For example, you can upload documents, change the graphics on the portal, add web parts and configure the security settings to your heart's content. You can also configure links, announcements, contacts, events, tasks, issues, discussion boards, surveys, and much more.
The problem is, for every Team Project you create, you have to repeat the customization steps over and over again. This can be very tedious and unproductive. Fortunately, you can integrate some of these changes in a process template. Specifically, when you create a project you can pre-populate document libraries on the portal. Chapter 22 has some really useful information on how to work with the process templates. The key to customize the portal is an XML file called WSSTasks.xml:
<?xml version="1.0" encoding="utf-8" ?> <tasks> <task name="Create Sharepoint Portal" plugin="Microsoft.ProjectCreationWizard.Portal" completionMessage="Project site created."> <dependencies/> <taskXml> <Portal> <site template="TeamDocs#1" language="1033"/> <documentLibraries> <documentLibrary name="Security" description="Architecture Documents"/> <documentLibrary name="Testing" description="Testing Documents"/> ... </documentLibraries>
So far, we've looked at customization. What about extensibility? You have the option to create new web parts which can be integrated into the portal using the Microsoft Windows SharePoint Products and Technologies SDK. web part creation is a bit out of scope for this book, but we recommend that you refer to the SDK and the MSDN documentation for code, tips, and examples.
Here are the steps to add a new web part to an existing page (including a custom web part):
Click Modify Shared Page Design This Page.
Click Modify Shared Page Add web Part. You will then be presented with the following options: Browse, Search and Import.
Select Browse and then select the Page Viewer web part.
You can then drag the part to the left portion of the screen.
Click the down arrow at the corner of the web part and select Modify Shared Web Part.
In the Link section on the right, enter /Reports/">http://www.<servername>/Reports/.
The reporting site will now appear in the web part on the team portal (as shown in Figure 19-17).
One of the most requested site-customization questions I've been asked is how to change the "look and feel" of the site portal (for example, change the logo and colors on the main portal page). You can easily modify the Team Portal by using FrontPage 2003. Simply connect to the site (File Open Site) using FrontPage. (You may be prompted to enter your Team Foundation Server administrator credentials.) You can then import your logo (using File Import) and drag and drop it on the page. You can also change the colors on the site by modifying the style sheets in the "themes" directory.
When you first start working with Team Foundation Server, experimenting, creating multiple projects you might find that your server will start looking cluttered. Thankfully, Team Foundation Server comes with a handy tool called TFSDeleteProject which comes to the rescue. TFSDeleteProject is located in the C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies\ directory. You can delete a project using the following syntax:
TFSDeleteproject /TeamFoundationServer:TFS TestProject
In the preceding example, TFS denotes the name of your Team Foundation Server, and TestProject is the name of the project you want to delete. TFSDeleteProject comes with several useful parameters, as shown in Table 19-2.
The application will attempt to delete all parts of a Team Project even if problems occur.
You can specify the name of the server using this parameter. It is especially useful if you are running multiple instances of Team Foundation Server.
Run the project delete tool in "quiet" mode. You won't receive any confirmations or prompts during the deletion process.
Please note that once you delete a project, you can't recover it — the process is irreversible. Parts of the Team Project, however, will remain in the data warehouse.