TFS Tips and Tricks

TeamLook and TeamSpec to simultaneously-ship with Visual Studio 2010

2010-02-04T19:11:14Z

TeamSolutions, LLC, Visual Studio Industry Partner*, announces plans to simultaneously-ship TeamLook and TeamSpec with Visual Studio 2010 prior to 5/30/2010.

TeamLook is a convenient software project dashboard that allows all stakeholders in a software development project to communicate and collaborate using Microsoft Visual Studio 2010 Team Foundation Server from within Microsoft Office Outlook.

TeamSpec provides rich team project artifact management directly inside Microsoft Office Word allowing specification, requirement and other document content to maintain integrity with Microsoft Visual Studio 2010 Team Foundation Server.

* The VSIP relationship is currently listed under Personify Design. Personify Design spun off TeamLook and TeamSpec into its own brand (and company) called TeamSolutions, LLC in 2009.

So what’s your process template?

2009-11-08T20:58:56Z

Almost everyone knows about the extensibility of the process template that defines the team project within Team Foundation Server. I’m always interested in hearing what other teams have done to modify either the Agile or CMMI template to better tailor it to their internal processes. So I thought I’d share what we’ve done to extend the process template ourselves.

We are big fans of the Agile methodology and work in a semi-scrum environment. We started with the standard Agile work items (Bug, Task, …) and everything was working pretty well. Fairly soon though we found we could really use some additional states on the work items to allow us to better report on the current status of our work. This was before the days of the power tools that have really simplified these types of changes. We jumped on the internet and started reading about witimport.exe and how to modify the XML that defines the work item types. We added the states and happily moved along.

After our team grew we realized we needed additional workflow to better manage the work as it moved through the team. So we once again extended the process template. Now, for example, the work item lifecycle looks something like this:

A change request from the customer would be communicated to the project manager via email. She would then use TeamLook to create a work item and assign the appropriate priority and severity. At this point it would be dropped into a pending iteration waiting for the next triage meeting.
At the triage meeting we estimate the effort needed to complete the work item and assign start and finish dates. This allows us to manage the work within Microsoft Project very easily, but that will need to be another blog post. We also assign the iteration that the work will be completed in. The iterations are generally a month long, depending on the project. The work item state is set to scheduled and ready for a developer to begin work.
The developer uses TeamLook to view their work items and sort them based on the priority and importance. After choosing the most critical work item the state is changed to in-progress signaling that work is underway.
When the developer has done their code review and checks in the changes, the work item is associated with the changeset, and TFS changes the work item state to resolved.
A continuous integration build is fired off and an email sent to the team informing them of the state of the build. A nightly build runs that incorporates all of the changes checked in during the day and those changes are pushed to the test environment.
The tester reviews the previous day’s changes and validates the work. Upon approval the changes are pushed to the staging environment and the work item state is changed to verified.
The project manager uses TeamLook to aggregate the verified work items and sends the list to the customer to notify them that their requests have been staged. The customer can confirm the changes meet their expectations to the project manager, who then changes the state of the work item to reviewed.
When the iteration’s release date arrives the deployment lead verifies that all work items are set to reviewed and can be released to production. We’ve created an internal tool that can pull out the changed code from source control based on a team query. This simplifies checking what changes need to be pushed to production.

That’s a lot to read, so where’s a pretty picture instead?

Welcome to TFS Tips and Tricks

2009-09-17T00:47:00Z

Having worked with Microsoft's Team Foundation Server since TFS 2005 was pre-beta we have gained a deep knowledge of the API and its inner workings. Starting with the Outlook Starter Kit back in 2005 as an example of how to interact with the work item object model, we have had the opportunity to work with many of the methods and objects exposed through the TFS API.

I'd like to use this blog to share some of the tips and tricks we have found over the years. Hopefully it will be helpful for other developers working with the TFS API as well as a repository of tricks and helper apps so we can find them later as well. J

I will also share some of the ways we have modified the Agile process template to work with our internal methodologies at TeamSolutions as well as its sister company, Personify Design. The extensibility of TFS is really one of its core strengths, and I think we've managed to do some substantial "extensions" (including TeamLook and TeamSpec!)

Thanks for stopping by!
Eric