Tips for organizing Team Projects?

vcohen · April 9th, 2007, 05:10 PM

All, we're about a week away from our first stab at setting up TFS. A small team went to two days of TFS deep-dive, and got a great overview of how the system works and some info on limitations and workarounds. I need some advice on the part that worries me the most, the way Team Projects are organized.

Here's my situation: I work in the IT dept. of a 3,000-person company. We have a lot of COTS apps with customization and configuration, and a moderate amount of app development -- web apps, reports, middleware, etc., mostly for internal use. We're in a single geographic location, have a single data center, and about 20 developers and an ever-changing cast of consultants who need access to source control. We have a Project Management Office (PMO) and an app maintenance group, and about 150+ applications to support, each with one or many projects. We're currently using VSS 6.0 :-(

Projects may get initiated through the PMO, worked on and eventually transferred to the Maint. group once they go live. Or, if small enough, they may originate in the Maint. group, either as brand-new work or as enhancements to existing systems.

At our training, we were told that ALL TFS Team Projects must hang off the root:

Code:

$/Project1, $/Project2,

etc. And, there's a limit of ~500 Agile projects on a server. We could easily have 500+ projects, if they all hang off the root.

In VSS, I can create subprojects, so my repository root can be fairly clean, and all the real changing items are a couple levels deep. E.g. in VSS I can have

Code:

$/PMO/Financial Systems/FinProject1
$/PMO/Property Management Systems/PMSProj1
$/Maint/Intranet/InetProj1
$/Maint/Middleware/Messaging/IntProject1
$/Maint/Middleware/ETL/ETLProj1

But the root just looks like

Code:

$/PMO
$/Maint

From what I can tell, in TFS, all these projects must hang off the root, either like

Code:

$/FinProject1
$/PMSProj1
$/InetProj1
$/IntProj1
$/ETLProj1

or

Code:

$/PMO_Financial Systems_FinProject1
$/PMO_Property Management Systems_PMSProj1
$/Maint_Intranet_InetProj1
$/Maint_Middleware_Messaging_IntProject1
$/Maint_Middleware_ETL_ETLProj1

That causes me some pain: We have LOTS of projects, and not much consistency in naming conventions. So it could be very hard for people to locate the project they should work on. Grouping by the dept that owns the project, and by functional categories below that, makes it pretty easy to zero in on the items of interest. And we'd never get near the 500-project limit if we could group them.

Our team has been kicking around ideas to deal with this. One is to go ahead and make the owning depts. the top-level "Team Projects", and the actual development artifacts as sub-sub-folders within that, just like the VSS example above. But from what I understand, ALL projects under that root TP must share the same Methodology.

What other limitations does this structure imply? How do people in corporate IT environments like mine deal with this? Any tips appreciated!

- Val