Well, it depends…. If you are a small company that creates a finite number of internal projects then you will find it easier to create a single project for each of your products and have TFS do
the heavy lifting with reporting, SharePoint sites and Version
Control. But what if you are not… Update 9th March 2010 Michael Fourie gave me some feedback which I have integrated. Ed Blankenship via @edblankenship offered encouragement and a nice quote. Ewald Hofman gave me a couple of Cons, and maybe a few more soon. Ewald’s company, Avanade, currently uses Areas, but it looks like
the manual management is getting too much and
the project is getting cluttered. What if you are likely to have hundreds of projects, possibly with a multitude of internal and external projects? You might have 1 project for a customer or 10. This is
the situation that most consultancies find themselves in and thus they need a more sustainable and maintainable option. What I am advocating is that we should have 1 “Team Project” per customer, and use areas to create “sub projects” within that single “Team Project”. "What you describe is what we generally do internally and what we recommend. We make very heavy use of area path to categorize
the work within a larger project." - Brian Harry, Microsoft Technical Fellow & Product Unit Manager for Team Foundation Server "We tend to use areas to segregate multiple projects in
the same team project and it works well." - Tiago Pascoal, Visual Studio ALM MVP "In general, I believe this approach provides consistency [to multi-product engagements] and lowers
the administration and maintenance costs. All good." - Michael Fourie, Visual Studio ALM MVP “@MrHinsh BTW, I'm very much a fan of very large, if not huge, team projects in TFS. Just FYI :) Use Areas & Iterations.” Ed Blankenship, Visual Studio ALM MVP This would mean that SSW would have a single Team Project called “SSW” that contains all of our internal projects and consequently all of
the Areas and Iteration move down one hierarchy to accommodate this. Where we would have had “\SSW\Sprint 1” we now have “\SSW\SqlDeploy\Sprint1” with “SqlDeploy” being our internal project. At
the moment SSW has over 70 internal projects and more than 170 total projects in TFS. This method has long term benefits that help to simplify
the support model for companies that often have limited internal support time and many projects. But, there are implications as TFS
does not provide this model “out-of-the-box”. These implications stretch across Areas, Iterations, Queries, Project Portal and Version
Control. Michael made a good comment, he said: I agree with your approach, assuming that in a multi-product engagement with a
client, they are happy to adopt
the same process template across all products. If they are not, then it’ll either be easy to convince them or there is a valid reason for having a different template - Michael Fourie, Visual Studio ALM MVP At SSW we have a standard template that we use and this is applied across
the board, to all of our projects. We even apply
any changes to
the core process template to all of our existing projects as well. If you have multiple projects for
the same clients on multiple templates and you want to keep it that way, then this approach will not work for you. However, if you want to standardise as we have at SSW then this approach may benefit you as well. Implications around Areas Areas should be used for topological classification/isolation of work items. You can think of this as architecture areas, organisational areas or even
the main features of your application. In our scenario there is an additional top level item that represents
the Project / Product that we want to chop our Team Project into. Figure: Creating a sub area to represent a product/project is easy. <teamproject> <teamproject>\<Functional Area/module whatever> Becomes: <teamproject> <teamproject>\<ProjectName>\ <teamproject>\<ProjectName>\<Functional Area/module whatever> Implications around Iterations Iterations should be used for chronological classification/isolation of work items. This could include isolated time boxes, milestones or release timelines and really depends on
the logical flow of your project or projects. Due to
the new level in Area we need to add
the same level to Iteration. This is primarily because it is unlikely that
the sprints in each of your projects/products will start and end at
the same time. This is just a reality of managing multiple projects. Figure: Adding
the same Area value to Iteration as
the top level item adds flexibility to Iteration. <teamproject>\Sprint 1 Or <teamproject>\Release 1\Sprint 1 Becomes: <teamproject>\<ProjectName>\Sprint 1 Or <teamproject>\<ProjectName>\Release 1\Sprint 1 Implications around Queries Queries are used to filter your work items based on a specified level of granularity. There are a number of queries that are built into a project created using
the MSF Agile 5.0 template, but we now have multiple projects and it would be a pain to have to edit all of
the work items every time we changed project, and that would only allow one team to work on one project at a time. Figure:
The Queries that are created in a normal MSF Agile 5.0 project do not quite suit our new needs. In order for project contributors to be able to query based on their project we need a couple of things.
The first thing I did was to create an “_Area Template” folder that has a copy of
the project layout with all
the queries setup to filter based on
the “_Area Template” Area and
the “_Sprint template” you can see in
the Area and Iteration views. Figure:
The template is currently easily drag and drop, but you then need to edit
the queries to point at
the right Area and Iteration. This needs a tool. I then created an “Areas” folder to hold all of
the area specific queries. So, when you go to create a new TFS Sub-Project you just drag “_Area Template” while holding “Ctrl” and drop it onto “Areas”. There is a little setup here. That said I managed it in around 10 minutes which is not so bad, and I can imagine it being quite easy to build a tool to create these queries Figure: These new queries can be configured in around 10 minutes, which includes setting up
the Area and Iteration as well. Version
Control What about your source code? Well, that is
the easiest of
the lot. Just create a sub folder for each of your projects/products. Figure: Creating sub folders in source
control is easy as “Right click | Create new folder”. <teamproject>\DEV\Main\ Becomes: <teamproject>\<ProjectName>\DEV\Main\ Conclusion I think it is up to each company to make a call on how you want to configure your Team Projects and it depends completely on how many projects/products you are going to have for each customer including yourself. If we decide to utilise this route it will require some configuration to get our 170+ projects into this format, and I will probably be writing some tools to help. Pros You only have one project to upgrade when a process template changes – After going through an upgrade of over 170 project prior to
the changes in
the RC I can tell you that that many projects is no fun. Standardises your Process Template – You will always have
the same Process implementation across projects/products without exception You get tighter
control over
the permissions – Yes, you can do this on a standard Team Project, but it gets a lot easier with practice. You can “move” work items from one “product” to another – Have we not always wanted to do that. You can rename your projects – Wahoo: everyone wants to do this, now you can. One set of Reporting Services reports to manage – You set an area and iteration to run reports anyway, so you may as well set both. Simplified Check-In Policies– There is only one set of check-in policies per
client. This simplifies administration of policies. Simplified Alerts – As alerts are applied across multiple projects this simplifies your alert rules as per
client. Cons All of these cons could be mitigated by a custom tool that helps automate creation of “Sub-projects” within Team Projects. This custom tool could create areas, Iteration, permissions, SharePoint and queries. It just
does not exist yet :) You need to configure
the Areas and Iterations You need to configure
the permissions You may need to configure sub sites for SharePoint (depends on your requirement) – If you have two projects/products in
the same Team Project then you will not see
the burn down for each one out-of-the-box, but rather a cumulative for
the Team Project. This is not really that much of a problem as you would have to configure your burndown graphs for your current iteration anyway. note: When you create a sub site to a TFS linked portal it will inherit
the settings of its parent site :) This is fantastic as it means that you can easily create sub sites and then set
the Area and Iteration path in each of
the reports to be
the correct one. Every team wants their own customization (via Ewald Hofman) - small teams of 2 persons against teams of 30 – or even outsourcing – need their own process, you cannot allow that because everybody gets
the same work item types. note: Luckily at SSW this is not a problem as our template is standardised across all projects and customers. Large list of builds (via Ewald Hofman) – As
the build list in Team Explorer is just a flat list it can get very cluttered. note: I would mitigate this by removing
any build that has not been run in over 30 days.
The build template and workflow will still be available in version
control, but it will clean
the list. Feedback Now that I have explained this method, what do you think? What other pros and cons can you see? What do you think of this approach? Will you be using it? What tools would you like to support you? Technorati Tags: Visual Studio ALM,TFS Administration,TFS,Team Foundation Server,Project Planning,TFS Customisation
