Logically (or conceptually), a team project is a single infrastructure that encompasses all of the separate tools and elements used in the life cycle of the development of a software application. Each software application, or "team project," in development is virtually grouped in its own namespace intended solely for the team project. Therefore, a team project is simply a container isolating all of the tools and artifacts associated with a particular software application in development, such that all other team projects will not have access to those tools or artifacts (for example, source code, work items, and documents).

The team project is the central concept that holds together the team endeavor of creating a specific software technology or product. The team project is the virtual collection of artifacts relevant to a software application on which a team is working. For the team members, the team project concept eliminates the problem of having access to multiple artifacts not relevant to the team project; such an excess of artifacts causes confusion and delays the software development process. At a minimum, the team project consists of a set of tools and artifacts. The team project may also include source control policies, a team project reporting site, and a team project portal. The Team Foundation team project allows the process template, during the creation of a team project, to select which tools are relevant and will be added in the team project container.

The team project concept enhances reporting across all the tools used by the team. In the past, cross-tool reporting was challenging because the data from different tools was not related. For example, if a software developer wanted to obtain a cross-tool report on defects, he or she would have to distinguish the defects from multiple projects, since the defects were all stored in a common location. A team project is created in a namespace containing only tools and artifacts relevant to the software project; therefore a common filter is created which can relate different artifacts from different tools.

A single Team Foundation Server server may contain multiple team projects, each of which are created in a separate namespace, such that a document named X in namespace A is not the same as a document named X in namespace B. Creating a team project in a separate namespace allow artifacts or tools to be unique to the team project for which they belong, such that a tool or artifact contained in team project A is not accessible to a software developer working on team project B.

The logical definition and conceptual boundary around a team project is made real through Team Explorer. Team Explorer is an extensible tool window within Visual Studio which groups tools and artifacts by team project. At a minimum, the team project consists of the set of tools and artifacts specified when the team project was created by the process template. Depending upon the process template used to create the team project, the team project may also include source control policies, a team project reporting site, and a team project portal.

When you first open Team Explorer, it is empty, and you must connect it to a Team Foundation Server. Then you can select which team projects you want displayed in Team Foundation Server. Team Explorer connects to only one Team Foundation Server, and therefore only displays team projects from one Team Foundation Server. Again, depending upon the process template used to create the team project, team members can use Team Explorer to view information on the product builds, launch to source, query on tasks assigned to them, view overall project status, locate documents, view reports, and create work products associated with the team project. For example, a team project created with the MSF for Agile Software Development or MSF for CMMI Process Improvement process templates will display the following nodes:

• Work Items   This node provides access to create and view queries against the work item database and to create new work items. Project queries are implemented by the process template or project manager at the creation of the team project. User defined queries are not implemented during the creation of the team project but are later added as custom content.

• Documents   This node provides access to work products such as documents, spreadsheets, project plans, process guidance, and other intangible output from development activities. The documents are stored in a single, central location on the team project portal.

• Reports   This node provides access to reports containing metrics for the team project and to a means of gathering information from the various tools contained within the team project namespace. The SQL Reporting Services report site is designed to perform cross-tool reporting by bringing together diverse information from various tools within the team project and form a report by employing semantics and syntax appropriate for the information exported from each tool.

• Team Builds   This node provides access to the builds of your team project.

• Source Control   This node provides access to artifacts such as source code and text. Program developers use the source explorer to check in and check out source code. The source control explorer is a browser of the team project source files. A number of user defined custom tools may be implemented by a user.

Team project settings and properties vary from team project to team project. The team project properties are set from the Team menu in Visual Studio and define settings for groups and permissions which identify members of the team project and their access rights. For example, one software developer may have access to change document X in a team project but not document Y, while another software developer involved in the same team project may have access to change both documents X and Y. Assigning groups helps to establish the various sub-teams within the team project and to better manage the required tasks. Team project settings also include the virtual hierarchical groupings for artifacts within a team project. The classification structure may include the life cycle iterations that make up a team project and the components or features of a team project. Work items and other artifacts such as test cases, may also be classified against the structures/hierarchies to make for easier tracking and reporting.

Source control policies help define source control settings. Source control settings characterize check-out settings, check-in policies, and check-in notes. The source control settings define which artifacts may be checked out and by whom, they also help define settings which enable a user to go back in time and check out different versions of an artifact which may have been produced during the life cycle of the project.

Concepts

Other Resources