Team Foundation Server 2012 (TFS 2012) is the latest version of Microsoft's Application Lifecycle Management (ALM) system. It covers all the aspects of managing a software product over its complete lifecycle, from inception, through development and the subsequent maintenance phase for as long as it is in use.
TFS 2012 governs all the aspects of software development, including requirement management, project management, development, testing, deployment and quality assurance. It has four major traits that make this very valuable:
Traceability
Visibility
Automation
Flexibility
An important aspect is the multiple ways of accessing TFS 2012. It can be accessed using the brilliantly new Agile Web Access, using Visual Studio, or a multitude of other development IDEs, Microsoft Office products, or even through Java development platforms such as Eclipse. There is also a rich ecosystem of third-party tools available, which integrates into TFS 2012. Some examples include inteGREAT from eDevTech, TeamCompanion from Ekobit, and InRelease from InCycle Software.
TFS 2012 has four major operational parts or stores, namely the work item system, the version control system, the build system, and the test system. In addition, it has a reporting data warehouse and a SharePoint project portal; the latter can be used for both document management and for accessing reports. It is a multi-role system, so that all the major roles in an organization can use TFS 2012 for their own purpose.
TFS 2012's major advantage lies in its internal integration. All the stores are coupled together so that information is automatically linked together as the different operations take place.
A typical case story for how different roles work together using TFS 2012 is as follows:
A Stakeholder adds a requirement to the work item system using the Agile Web Access.
An Architect sits down with the stakeholder and enters test cases as the acceptance criteria into the work item system using the test manager, and in doing so, connects the requirements with the test cases.
The Product Owner moves the requirements into the upcoming sprint.
The Scrum Master sits down with the team and breaks down the requirement in tasks using Excel.
The Developer receives the task in Visual Studio and develops the source code. He/she checks in the source code to the version control system of TFS 2012, and in doing so connects the task work item with that source code.
The TFS 2012 build system detects the check in and starts an automated build. The build is connected to both the source code and the task work item.
The tester detects a new build in his test manager, and starts running a new test run based on the test cases entered earlier and the compiled code based on the new build.
A Bug is detected, and the Test Runner collects information from the Test System with all its Test Results, connects this to the bug, and the bug to the test case and the build.
The circle is now complete—all these artifacts are all stored in TFS 2012 and what is so great—the artifacts are all linked together! Anyone can now access this information from any point, and drill down into any other part of connected items.
This story showed a scenario with many roles and many processes in place, but you can start much simpler. You can even start without nearly anything. For example just start with testing, run an exploratory test session with nothing else in place; just run the test and create bugs as you find them. From there you can, if you like, use the bugs to create test cases, and collect the test cases together to form user stories.
These are just some examples of the flexibility you have. TFS 2012 can support nearly any process you have, and you can choose for yourself how much or how little you want to use. Then, as time goes on, you can add more features, without compromising anything you have done earlier.