When leading a project a PM bases not only on chosen methodology but also on his own experience. Almost every manager has his own set of best practices which help him (and the team) to finish the project successfully. When a project involves large number of people you often use tools that support team work. There are many programs that assist you in using a concrete methodology. In most cases they are very helpful, but problems start when you want to change the methodology to better suit your needs.
I myself use a mix of Microsoft Solutions Framework v3 and some best practices. The main difference from MSFv3 is an additional role that is supported is MSFv4-the Architect. In my opinion a person who cares about the overall solution design is essential in almost all software projects. Second most important best practice is approach to risk management. Some people may ask if risk management is essential in project management. In my opinion it is one of most important factors that have impact on the project! Thanks to risk management we can predict forthcoming threats and prepare for them or even eliminate them before they occur.
The question is "how can I implement these best practices in Visual Studio Team System" which is ultimate tool supporting work group during any project based on .NET technology. The ones that deployed the Team Foundation Server may remember that it has two preinstalled methodologies: MSFv4 for Agile Software Development and MSFv4 for CMMI Process Improvement. But we are not limited to only these two! Thanks to Process Template Manager we can easily change them or add our own methodologies. But what is the Process Template? It is a set of XML files which tell Team System step by step exactly how to set up a new project. In very direct way, the process template defines the methodology for a project by specifying which process tools will be used and how these tools will be configured for the project. Because creating a process template from the scratch is quite hard I advise to export one of the attached MSF templates and edit them. You can use the export function in Process Template Manager to do it. What you get as a result is a zip file containing all the files that define to project. The most important is of course the ProcessTemplate.xml which stores settings and references to VSTS plug-ins.
Microsoft provides six of them:
- Classification Structure System (CSS) - defines project's initial iterations, organization units, components or future areas
- Group Security Service (GSS) - defines project's initial security groups and their permissions
- Microsoft Windows SharePoint Services (WSS) - defines the project portal for the team based on WSS site template files and process guidance
- Currituck - defines project's initial work item types, queries and work item instances
- Rosetta - defines a team project's initial reports
- Source Code Control (SCC) - defines project's initial version control security permissions and check-in notes
As you see the possibilities of TFS customization are almost endless. If you decide to extend this system (tweak it or add some plug-ins) you can create a tool that perfectly suits your needs. But let's get back to my methodology. Fortunately it is quite similar to MSF v4 for CMMI Process Improvement which supports the Architect role and has MSF v3 core.
Nevertheless I would like to extend its risk management by adding a Risk work item type. I could do it by editing xml file of Currituck (WorkItemTracking) plug-in but there is an easier way - Process Template Editor (PTE). It is a free tool created by ImagiNET Resources Corp. You can download it from http://www.imaginets.com/Default.aspx?tabid=133 . Unfortunately it is still buggy but it simplifies the process of customization-especially for TFS beginners. To add a Risk item type I have to add a new node in Work Item Type Definitions. To speed up I can base on the Bug item type and then change its fields, workflow or layout. I can edit an existing Risk item type in the same way. What I like most in this part of Process Template Editor is the ability to preview a form of an item type before it is deployed in TFS. After adding/editing a work item type I can add a query (in Work Item Type Definitions\Queries node) to find it easily during the project.
Then I may customize the Process Guidance Documentation to support the new/changed work item. In PTE you can find it in Portal node, but it is much better to use InfoPath and edit the xml files directly. To finish this process I could also add a new Report based on SQL Server 2005 Reporting Services.
As you see Team Foundation Server is very flexible as it comes to customization. There are many ways to edit the system settings, some of them to trivial to describe them here.
I hope that I encouraged you to discover the VSTS potential and to use it as a support of software development process.
Posted
11-04-2006 1:59 PM
by
Daniel Arak