Your longest running team project
*Note- I actually started this post November 1, 2006 and it has sat in my Draft folder for some time. I had a friend ping me about some screwed up work item fields in some projects and this reignited my need to push this post out.
I spend a lot of time working with clients and peers on projects or tasks related to the planning, installation, and use of VSTS and TFS. Most of the clients are larger enterprise clients because they have the complexity of environment and requirements that provide an easy decision on the cost/benefit for a number of weeks of my time to get them kick started. Invariably, in every shop a need for some extension of the base MSF process templates is desired. Many times it relates to more specific and granular security, other times it involves how work items map into Microsoft Project, or the creation of some custom fields in work items. Even if no extension of the TFS functionality is immediately desired it's likely that at some point the client will wish to do so. Thus one of my first acts is to always set the pattern for those changes. To start off on the right foot I invariably create a team project called TFS Implementation. You should do the same.
As soon as TFS is installed the first project created should be TFS Implementation. Then from that point forward the implementation, management, and extension of VSTS/TFS should be handled like any other software development project. The TFS Implementation project should be your company's longest running TFS team project. Why? TFS is an enterprise wide, multi-departmental server and any changes has an affect on everyone. Even if you are only installing for a smaller workgroup it's doubtful you'll use it in it's most vanilla form.
Step 1 of any TFS Implementation team project should be to download the MSF Agile and MSF CMMI process templates and place them in source code control under the TFS Implementation project. Then never again download the process templates from the server.
Step 2 is treat your process templates just like any other source code. If you find you desire a change in the process templates provided then create a new process template named something like "My Company Agile Process" branched from the appropriate template. Oh- and yes this placing of the base template in source and branching for your variation applies for SCRUM or any other third party template which can act as it's own base with "My Company SCRUM Process" as it's branched child.
Step 3 when a change is required or requested it should be logged into the TFS implementation project as a requirement, change request, scenario, whatever and then linked up with a work item or set of work items. In which you'll then check out the sections of the template in version control, make the changes, upload them for testing; preferably on a development TFS instance, and when it works as desired check in the files with the changeset associated to the workitem. Then you can upload to your production TFS instances. Do you see now why I say you should never need to download a process template again?
Downloading the template, making changes, and uploading again would be like taking your production .NET code and reverse engineering it back into C#, making changes, recompiling and placing it back into production.
Now that you are always making changes to your process templates within source control you never have to worry about screwing up and needing to revert back because you can do so. You'll also know who made the changes, when and why.
For individual changes that may not constitute an entire template change to be uploaded but only a change to a work item in some given existing Team Project this should be handled in a similar manner. Just because you are changing only one workitem type in an existing team project doesn't mean you shouldn't branch from the entire process template related to that team project and make those changes and upload via witimport. I recommend that if you do this you branch from the original template used to create the team project into a folder of the team project you plan to modify so that in the future you always have a repeatable and known state for all work item types, mappings, rules etc related to that specific project. Or at least branch that specific work item into the team project source tree. If the project never deviates from a known template then you needn't worry about having a full template in the project.
If you follow these simple rules your life will be much easier. It's nothing ground breaking. Just place your templates in source and treat them as you would any other source system.