Oct 19, 2010 at 11:46 PM
Edited Oct 20, 2010 at 1:51 AM
I guess we will have to agree to disagree on this point. You have made repeated references to the Developer Division and the Office Team. Both these teams are working on completely different programs with very different release schedules and
milestones. There is no need to track work items across these two teams as a general rule. This is precisely the case where I recommend separating two very different programs and their teams into separate Team Projects.
Along the same lines, all of the products developed by the office team do have the same release schedule and milestones. These products are highly integrated. This is precisely the scenario where I recommend having even a large complex team working on many
features (products) all working in the same Team Project.
There is not a huge issue, in my opinion, around process templates, work item definition changes, etc. These are easily managed for the most part. A benefit of having separate team projects is that the process templates may be the same but can also be quite
Test plans, test suites, reports, VMs are all likely to be very different for the office team and the dev div team. These are NOT reasons to force these two teams into the same Team Project.
With respect to the check-in policy bug - this will be fixed, and should not be a controlling factor this decision.
I just have to completely and totally disagree with the perspective that one would never ever use more than one Team Project. That perspective may work for your organization. It would not work for Microsoft internal development ("in lieu of EVER using
multiple team projects")
A benefit of Team Project Collections (TPCs) is that they provides for great scalability and reduced back up and recovery times. Each TPC has it's own database, and can be serviced by it's own Data Tier server if necessary. The approach of having
all development and release activity taking place on a myriad of branches all within a single Team Project simply won't work for all cases. I am not opposed to having making this recommendation in some (or many) cases. But it should not be a hard and
fast, universal, inviolable rule.
VS ALM Ranger