Project Tracking with Team Foundation Server 2010

Microsoft recently released the second public beta preview of the 2010 release of it’s developer toolset, Visual Studio. A key plank in the Visual Studio 2010 story for development teams is their Application Lifecycle Management tool, Team Foundation Server (TFS).

With this release, Microsoft have made some significant changes to the way in which TFS supports project management, particularly with respect to Agile projects.

With TFS 2010, Microsoft have decided to place all the Process Guidance documentation online instead of embedding a copy of it in each individual project’s portal site. So, rather than just duplicate Microsoft’s content here, I’ll provide links to it from relevant points, and instead attempt to provide my own interpretation of what it means, and how to use the process.

I’m not a Project Manager, nor a process expert so why am I writing about this?

Ok, so I might not be a Project Manager by trade, nor am I PMP or Scrum certified or anything like that. What I am is someone who has a spent many years in software development, over a range of platforms, and leading projects both large and small. Over my time I’d like to think I’ve learnt a thing or two from my experiences.

This is my attempt to take what Microsoft are doing with Visual Studio 2010 and describe how I think it should be used. What I like, what I don’t like.

I’m learning as I go with these products, just like everyone else is. I’m hoping to gain a better understanding of the practical application of these new tools as I go. I’m also hoping that by sharing my experiences along the way on this blog, and with a bit of luck, it might just help you to use VS2010 and TFS better too.

What am I going to cover here?

Right, with that out of the way, what am I going to cover here? Well, lets consider the make up of a typical software development team. Over the years, I’ve worked on a range of projects varying in both team size and project scope. I once spent 18 months or so working on a project which only had .75 of a full time person employed on it. Bizarrely, I wasn’t the only person working on that particular project!

I’ve also been involved in projects that have involved upwards of twenty people, spread across 6 separate locations, in three different countries. But the one thing they all have in common is that the roles on the project can be broadly categorised into about 4 groups.

• Project management
• Business representatives
• Developers
• Testers

That’s not  to say that, for example, if you’re a tester you won’t be interested in the developer information however. But I am going to focus on the day-to-day uses of TFS for each of these team members.

It’s worth noting again that I’m talking here about project tracking with TFS, so I’ll be writing specifically about those aspects of TFS that relate to each of these roles with respect to progress through a project. So the features I’ll be discussing in this series will centre around work item tracking, reporting, and planning features.

First up, what is there in TFS2010 that will mean that Project Management will want to use it?

Reboot!

It’s been a while since I added to my series on VSTS 2010 in action, and a lot has happened since I posted Part 2.

For starters, VS2010 Beta 2 has been released. This refresh contains much more content around the Process Guidance for the MSF 5 process templates, and so I’ve taken a slight pause in transmission on this series in order to absorb this and to reboot, if you like, my series on VSTS2010. When I post again, I’ll be using, and referring to, the features in Beta 2.

This does mean that I’ll go back over what I’ve already covered too, and update it for the new bits. Conceptually it’s still the same, but it’s a chance for me to tidy up what I’ve said already so that it actually makes some sense!

As well as this, the company I work for, Optimation, has re-launched it’s web presence, and the new website includes a company blog, which I will be contributing to. In fact, these posts will be submitted to that blog also, and cross posted here. I can’t guarantee the order in which this will happen though, so I recommend that if you’re really hanging out for a new fix of VSTS2010 goodness from me, you check both places.

Also, as I’m not the only person who’ll be contributing to the Optimation blog, a whole range of content will appear there, from some really smart cookies, so do go and check it out!

So, to summarise, I’m re-starting the series, and it’ll be cross-posted (hopefully – depends on approval from the “editorial team” at work) on the blog of the company I work for, Optimation.

VSTS 2010 in Action Part 1 – Introduction

As mentioned, I’ve been playing with VS and TFS 2010 beta 1, and since I have a personal project that I can use them on, I’m going to cover my adventures in a series of posts.  

The way I plan to run my project is to follow as closely as possible the actual process we use at work, since one of my goals is to find out how well TFS 2010 fits with our current process out of the box, and to figure out where any gaps might exist. Once I’ve worked that out, I’ll also consider how we might close any gaps, be it through a custom process template, custom or modified work items, custom built reports, or whatever it might be.  

By way of introduction, It would be useful to first cover our current tools and our current process. This should provide some background on where I’m coming from with this, and hopefully provide some insight on a couple of the issues that I think are present in our existing toolset in particular.  

Current tools

Currently we only use a subset of the functionality in TFS 2008, as we have other software that we use for things like Project Tracking, and team collaboration. For better or worse, I’m going to work through my project in this series whilst making use of the entire TFS toolset, since my personal belief is that by doing so we’ll get better value for money, as well as enable some key code quality and engineering practices that we currently are not able to perform.  

Our current toolset includes a Software as a Service project management/tracking tool called Rally, which has a really nice user interface and supports a variety of different approaches to agile project management. However, since Rally sits not just outside TFS but outside the firewall, there are some interesting problems we face with it.  

We are, in my opinion, also hamstrung by the fact that we cannot link user stories, defects, tests, etc to items within TFS source control, meaning that we lose the benefits of traceability that an integrated solution offers us. That said, Rally does have a good open API which we can, and do, use to integrate with TFS.  

However, these integrations have to be built by hand, which means someone taking the time to build and test them, and we just don’t have the time to do that. Add to this the fact that the API changes periodically, meaning that we run the risk of having our integrations just stop working suddenly. Add to this also the fact that any outage in connectivity at all means you lose access to the tool, plus the additional license cost (which is considerable with Rally, I’m told), and you begin to see why I’m keen to see whether we can get by with TFS instead.  

As I mentioned, we currently use TFS 2008, but only for Version Control and build. We have one or two projects that make use of the SharePoint integration for collaboration but by and large, projects instead use a Wiki for collaboration, with document storage done on the file system. The Wiki tool we use also incurs a license cost, so I’m planning to evaluate the experience of using the wiki pages built into the TFS SharePoint templates, whilst also using the project portals for document sharing.  

Our current process 

Without going to great lengths explaining our current development process, I’ll just say that it takes elements of SCRUM, and throws in bits of a couple of other methodologies as well. We generally describe our requirements with User Stories, and elaborate on these by adding tasks to them. Our PM practice lead is keen on 2 week iterations, which I find a little short, but not too bad.  

At the start of the project we’ll have a workshop with the customer to outline the user stories, so come iteration zero we will have some idea of what we’re aiming towards. We’ll also have the list done in some sort of priority order, so we also know which order we should be tackling the stories in.  

We’ll typically start with an iteration zero, which we would use to do project start up, as well as perhaps a prototype or proof of concept for the project. This is one area I’m looking at doing something a bit different with my project, but I’ll talk about that in a later post.  

Prior to each iteration we’ll do a planning session where we size the user stories using story points, which is a relative sizing method. Again, more on this in a later post. At the planning session we’ll take the stories from the top of the backlog, and estimate the amount of effort involved in doing each one. We take the total number of available developer hours for the upcoming iteration and subtract the hours for each story off the total until we’ve used up all the hours we have available.  

Before we do the estimating for the next iteration, we first do a retrospective for the previous iteration. This gives us a chance to discuss what went well, what didn’t, and what we’re going to do about it.  

The Project 

My project is focused on building a website for a (currently!) fictional business that uses flight simulators to provide customers with multiplayer simulated air to air combat. The website will have a range of static content on it, but also include some content managed areas. Content management won’t be anything too fancy, though, since the aim of the project isn’t to build a CMS, or even a CM enabled website. The site will also include a blog, and an online store, so that people can purchase merchandise online, to help fund the business and get it off the ground. 

In my next post I’ll start actually talking about TFS 2010, beginning with getting my product backlog set up. Specifically, I’ll cover using VS2010 with Team Explorer, the Web Access tool and project portal, and finally Excel to create and manage the backlog.

TFS and VS2010 – play time!

Well, I’ve finally got the chance to have a play with Visual Studio 2010, and so I thought I’d give it a decent working over.  

I’ve got myself a copy of the Beta 1 release of VS 2010 Team Suite edition, plus TFS2010. One of my main interest areas is in the use of TFS, and therefore I’m keen to explore the changes and (hopefully!) improvements in the 2010 release of this, as well as Visual Studio itself. Hopefully I can get a feel for the changes in store for us, since we’ve paid for Software Assurance with TFS 2008, meaning we get a “free” upgrade to TFS 2010 when it arrives.

I have a project that I’ll be working through using VS 2010 and .net 4, and I’ll be using TFS for source control, work item tracking/project management, and build services.  

So I’m off to have a bit of a play!