TFS process guidance template lock-in?

Question

My team is looking to migrate many of our tools (SCM, bug-tracking, builds, testing) to TFS. We're considering moving each system in stages. For example, move source control first, bug/feature tracking next, etc...

Since we have to choose a process template to use source control (or anything in TFS) how locked in are we with the decision? I'm looking to avoid having to create another project later (or is that not as bad as I think it would be?).

I know I can in theory customize everything the process template configures after the fact (right?), but how feasible is this in practice?

Here is how I see things happening:

1. We migrate our source code. We choose Microsoft's CMMI template.
2. We create a new work item (or check-in note) that is a simple link to our legacy bug tracking system.
3. We work for awhile.
4. We wait until the powers that be (we're a decent sized software company) to work out a new TFS development workflow. This may be a simple collection of new work items or an entirely new template that configures all sorts of stuff.
5. We try to migrate our TFS project to this new system without loosing our history.

Will we be sorry we didn't just wait until all these decisions were finalized before using TFS?

Answer 1

So, you are right to think about your process template as there is a certain amount of "lock-in" however it isn't too severe. It's like you are stuck to your process template with honey rather than super glue.

Personally, I would start with the MSF Agile template. It is much lighter weight and contains less work items - so you more likley to want to add things to it (very easy in TFS, very well supported) rather than take them away (more complicated and not entirely satisfactory).

However, if the power's that be decide to go down an uber process definition process and magically come up with a new process template in 12 months time that they want you to use then it isn't completely lost. If you find that you want to create a brand new Team project, as long as it is on that server (or Project Collection in TFS 2010) then you can either branch your code over to the new team project (which means that history is somewhat obscured in current versions of the TFS clients) or you can create a new Team Project with an empty folder for source control and then move the child folders over from the old team project to the new one. This will preserve history perfectly as TFS maintains history for moves on the same TFS instance. Your work items from before the move will be stuck over in the old process template though and you'll need to decide if you want to copy them or just leave them to get closed out naturally.

Obviously, by actually using TFS for 12 months on real projects, when the powers that be come knocking you are also going to be in a much better position to know what you want your shiny new process template to look like - and I've often found that this is an excercise that just never happens and most people are happy tinkering around the edges of MSF Agile or pick something more prescriptive like Scrum For Team System.

Hope that helps,

Martin.