Partitioning Mechanisms in TFS

In our discussions with Customer A this week, we focused for quite a while on the differences between the various work partitioning mechanisms in TFS:  areas, iterations, and source control organization.  At a high level, you can think about them this way:

• Areas - Useful for logical partitioning of workitems by functionality
• Iterations - Useful for temporal partitioning (e.g. beta1, beta2, release, servicing)
• Source code organization - the source control repository's tree structure for partitioning by code modules

Customer A had some great questions about how they might organize their team project and its many sub-projects using areas & iterations and how that relates to the tree hierarchy of their source code. 

The quick answer is: "You decide!"

We suggested building up an area hierarchy based on the major functionality provided by the sub-applications in their large IT project (served by a single Team Project).  Areas are primarily used to organize tasks, workitems, and bugs.  Some teams organize their areas in the same way their department or organization is organized, but I tend to prefer the functionality approach - reorgs happen all the time, and you don't want to have to update the areas for all your bugs every time you get a new VP :)

As for iterations...  These are useful for organizing a project based on time.  For example, major milestones:  iteration 1, iteration 2, beta 1, beta 2, RC (release candidate), RTM, and servicing.

In source control, you might be tempted to mirror the area hierarchy to organize your code.  If you're product is a code library or SDK, this might make sense.  But you probably want to organize more on a structure that makes sense for the way you've modularlized your code.  For example:

    $/OurTeamProject/main
       /GUI
        /BusinessLogicLayer
     /DataAccessLayer
        /CommonCode

Of course, this is just a very simple example.  Depending on the granularity of your team project, you might have one or more layers of subfolders under the TeamProject before you get to actual code for your assemblies/DLLs/exes.

So there's a quick spin on areas vs. iterations vs. source hierarchy.  As we continue through the week with Customer A, I'll continue posting about any points that seem to be applicable at a broad scale.  Of course, if you have any requests, let me know!

cheers,

-Jason

Update 8/28/2006 - Based on comments, I've updated the version control tree structure above to include a "main" branch directly under the team project node.  This is necessary if you're using a branching model and want to branch to folders under the team project.  If you still have questions, let me know and I'll do a follow-up post to explain this better.