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.
