Compartilhar via

Requirements Management for Ranger Projects – What I wish we did differently with our Team Projects

  • Artigo

In Team Foundation Server on Windows Azure … Rucking along and visualizing the good, the bad and the ugly we mentioned some of the good, bad and ugly findings in terms of the process. What we did not mention is that we would probably (highly likely) have structured out Team Projects differently … why?

How did we structure the Team Projects?

WBN_1

We used a single Team Project Collection scenario, which was kind of enforced upon us by the Team Foundation Server on Windows Azure Preview … which is the good.

We then created a separate Team Project for experimentation sandboxes (which is good) and for each project within the Visual Studio 11 Readiness “Gig” as shown above to create a self-contained and manageable project ecosystem, within the “Gig” solution. As every ALM Ranger by default has access to everything we created a security group, which was added to all the relevant Team Project groups, whereby each “MyTeam” team was updated to include the relevant team members and in some cases renamed to make the teams more recognizable in the drop downs.

While the individual teams have been working effectively with this model, our Ruck Master has had a horrid experience trying to aggregate and consolidate the overall status and to get a uniform environment implemented in each team.

What would we do differently?

If we could do it all over again, we would do things slightly differently, based on the following requirements:

  • All teams share the same security models
  • All teams use the same methodology (Ruck) and therefore the same process models or different ownership, we consider a separate Team project
  • All projects are owned by the Rangers
  • All projects are part of the same deliverable, the Visual Studio 11 Readiness conspiracy

As shown below, we would create one Team Project for the “Gig” and individual Teams, with their own individual focus and backlog. The TP-Sandbox is a “play and experimentation” Team Project and the TP-Legacy contains previous (legacy) releases for reference.

WBN_2

What’s the difference? The next image on the left shows how we “feel” that the teams are co-operating in the existing environment and on the right it shows how we “think” that they would collaborate with the revised structure:

PPP_PRD_476_3D_people-Hierarchy PPP_PRD_132_3D_people-Puzzle

Unfortunately merging Team Projects at this stage would be a difficult, risky and high impact exercise, something we can ill afford with milestones lurking behind the horizon.

Note to self: Read our upcoming guidance and plan, plan and plan some more Smile

Where can I read more?

Cape Vulture Visual Studio ALM Rangers Team Foundation Server Project Planning Guidance … aka African Cape Vulture (ACV) … is one of the projects we are working on as part of the Understanding our Visual Studio 11 Readiness conspiracy, which covers guidance on exactly this topic. We hope that we can avoid similar “oh no, too late, bite the bullet…” event in your environments.