We promised to keep you transparently informed of our Visual Studio 11 Readiness initiative and associated projects. I am honoured to be the project lead and work together with a bunch of competent and most importantly passionate Rangers in this project.
Working with Visual Studio is our business, thinking outside of the Studio is our passion!
We will deliver practical and scenario based guidance for the implementation of Team Foundation Server. In essence, we will guide you through the decisions whether to have one or more Team Foundation Servers, one or more Team Project Collections, one or more Team Projects and one or more Teams, based on scenarios and implications of each decision.
You should be used to raptor names by now and this project is proudly representing the African Cape Vulture (ACV).
… visit this beauty at http://birdsofprey.co.za/ in Dullstroom, South-Africa.
As mentioned we have a phenomenal team, whereby PO = Product Owner, RM = Ruck Master and PM = Program Manager / Project Lead.
Revised Epics [under consideration]
The revised Epics, as of this morning are:
- Epic: As Dave, the Team Foundation Server admin, I would like to understand the impact of Dev11 on Visual Studio Solutions and Projects, on Team Project Collections and Team Projects
|Epic: As Dave, the Team Foundation Server admin, I would like to understand how to structure Team Project Collections (TPC) within my organization |
- Epic: As Dave, the Team Foundation Server admin, I would like to understand how to structure Team Projects (TPs) within my organization
|Epic: As Dave, the Team Foundation Server admin, I would like to understand how to structure Project Teams within my Team Projects (TP) |
|Epic: As Dave, the Team Foundation Server admin, I would like to understand the implications of large projects and a mix of internal and external development teams on TPC and TP planning|
|Epic: As Dave, the Team Foundation Server admin, I want hands-on lab and video material based on guidance to be used as quick-starts |
The planned deliverables are just that … planned :) We are planning to include the following:
- One guidance document
- Three cheat sheets
- One quick reference poster
- One consolidated hands-on lab
At this stage we are wrapping up the planning and infrastructure preparations, moving over to research, training and design of the content. We are on an aggressive schedule and if you are interested to influence the initiative by giving feedback you need to act quickly.
Some Initial thoughts to get the discussions going … which I pulled from our project forum
Thanks Bill, Daniel and Jim for your *active* discussions, from which I extracted these
In terms of Team Projects
- Key questions to consider:
- Are these teams (work streams) working on the same code base?
- If these teams (work streams) ARE on the same code base, are they working on the same release milestones?
- Team Projects are *one* way of isolating different teams from each other, but it is not the only way.
- Single Team Project Advantages, include for example: Long Term Maintainability and easier Branching/Merging
- Multiple Team Project Advantages, include for example: Ability to have quick starts and the ability to have multiple process templates and customize *some*
Some of the core questions we will ask ourselves
- When should I have multiple Team Foundation Servers?
- Should I scale up or out when having multiple Team Foundation Server?
- When can I go virtual with Team Foundation Server?
- When should I have multiple Team Project Collections?
- When should I have multiple Team Projects?
- When should I have multiple Teams?
- What are the implications of huge projects and going across multiple (developer/consumer) boundaries?
So, what are your thoughts and questions?