We would like to use TFS2010
In my company, there is a single team working on multiple products at the same time. There is a visual studio solution for each product.
We can have the following scenarios:
Customer requirement 1 involves adding several features in product A and must be deliver in May
Customer requirement 2 involves adding several features in product A & B and must be deliver in Aug
Customer requirement 3 involves adding several features in product A & C and must be deliver in Aug
Customer requirement 4 involves adding several features in product B and must be deliver in Oct
Customer requirement 5 involves adding several features in product A & B and must be deliver in Oct
Developer Team is small (10 people) and can work on product a , b or c even though some developer know the product A better than the product B and so on.
In reality, we have almost 10 products. Sometimes we have hot fixes and I have to track all activities.
What do you recommend ? one or many team project ? if one team project, which structure do you recommend? Agile or CMMI templlate ?
The decision which project template to choose depends on you development process because the template represents it.
The CMMI template has a lot more fields for the workitem types (bug, task) than the agile one and is more formal. Take the time and think about your actual or future development process and take a look here to get an overview.
The scenarios you are decribing are reached via a branching strategy, take a look at the ALM Ranger branching guide
I would make one team project collection (because branching over team project collections is not possible).
I would create one team project and organize the products with the areas, iterations and team queries.
Reasons for my decicions
each team project gets its the version control and sharepoint site
you are a small team which work on all projects
the administrative overhead for each team project
Here you can find some good pictures and walkthroughs for working with one team project for different products.
Related
We are now starting development using Jira.
I currently have a team of 5 software engineers who can work on different projects and also on the same project a few times. What is the recommendation to use Jira? Do I create projects by "projects" or by team? How does the board formatting work in this case? When would you use an Epic?
I would like to understand cases of using Jira for you.
You should create a project per a project in your organisation, most likely it will reflect your organization structure. When it comes to the boards, you can display issues from several different projects on a single board so all members of your team can do a standup meeting without boards switching (Read more about boards here).
To the epics, consider creating an epic if you have a large user story that you want to split up into smaller chunks. You could also create an epic if you notice a pattern amongst several user stories you've created, and you want to bundle them into one group (you can read more here and here).
We have a five-member development team and will be building multiple internal projects in parallel. Upon researching, I find it is best to create one team project, even for our situation, correct?
If so, would you please recommend how to set up proper iterations for the projects and timelines?
TFS question - small team, multiple projects sounds similar to my situation, but I can't seem to get more than one "current" iteration in the TFS Agile process board.
Per team project you can have only one iteration tree (and therefore only one current iteration). You should decide based on how you plan your team resources. Do you want to have only a single backlog for the whole team or different backlogs for each project?
Each has its pros and cons, depending whether you want to use Visual Studio Team Service mainly for planning your team resources or planning your projects.
Using a single team project / backlog
With this approach it is easy to plan your whole team's resources for the next sprint. You can assign people to different tasks in different projects and have a good overview on what the team currently is working on. To assign work items to different projects you can use the area path.
Planning and tracking the progress of individual projects is a little bit harder with this approach since you have the same iteration structure for all projects and also only a common set of tags.
There are external tools which can integrate with Visual Studio Team Service available from the marketplace though, which can help you with planning individual projects.
Using a team project per project
With this approach you have a clear overview of the progress of each project and you can have individual iterations, tags, etc.
On the other hand it's harder to plan your team's resources since you won't have a single backlog and no place to see what your team is working on at the moment at a glance.
You can create one team project and set several child projects in it. With this, you can have the things configured for the whole project and also the child projects. Refer to this link for details: Multiple teams
I want to manage a 3-tier Application Develpoment (Data/Business/Presentation) with scrum in jira but do not know if I use 3 Projects (one for each Layer) or one project and arrange the layers with the epic tag function.
I have found a lot about big scrum projects but not with this structure and the most articles refered to big teams that we do not have.
The problem with tools is that they will attempt to drive your adoption of scrum. I advise stepping away from the tool and considering how you see the approach when simply using scrum. Then see whether the tool will model that.
For the situation you describe, I would think about one product and one product backlog, with multiple product backlog items. The product backlog items would describe vertical slices of functionality that cross all three tiers of your business model
It is unusual when using the Scrum framework to break out the tiers of the application in to separate projects. With Scrum we typically work on user stories that represent vertical slices through an application that deliver some business value.
Separating out the tiers means that:
You create external dependencies, which makes it difficult for teams to resolve their own problems. The Scrum Guide includes the following: "Cross-functional teams have all the competencies needed to accomplish the work without depending on others not part of the team."
Measuring the rate of progress of 'done' software becomes more difficult. The Scrum Guide says: "Incremental deliveries of “Done” product ensure a potentially useful version of working product is always available."
You create a synchronisation and resourcing problem in that the teams have to work at a balanced velocity so that they build the three tiers at a consistent rate. For example, the business tier development mustn't get too far ahead of the presentation tier.
Testing may be less effective as you have integration testing that spans several teams. This makes coordination more difficult and it may increase the time between when the code is written and when bugs are revealed.
We have a team of around 10 developers working on a new product.
We have split this product into two team projects on Visual Studio Online. Developers can work on both projects during any one sprint. Although we have two team projects, the entire team works together as one agile unit.
Why did we do this?
We want separate product backlogs
Each project has their own Product Owner
But this has led to two problems:
We have two burn downs, which can make it difficult to track team progress.
We have to split individuals' capacity between two projects, which is not easy to do in Sprint Planning and also makes it difficult to track individual progress.
I feel like this may be a common problem. Does anyone have experience here? Any suggestions?
You should have both teams in the same team project. You c Dan create multiple teams that all exist within the same team project and get their own backlogs.
http://nakedalm.com/creating-nested-teams-visual-studio-alm/
Most of my customers have moved to a single team project and I have a simple rule:
"If you have assets that are related (with assets defined as code, people, or work items) then you should be in a single team project."
I just got done in London merging about 15 team projects into one so that the entire org can work together. This was 6 teams across about 12 products, all moved to one team project.
The only effective way to collaborate is within a single bucket of work.
My company is a Software development company.
We planned to use TFS 2010 for our future customers development.
TFS 2010 introduce Team Project Collection in order to split related Team Projects.
So my question is, should i use Project Collection per Customers or should i use a unique Project Collection with a Team Project per Customers which will contains some customer solution projects in it
It depends on how independent your projects and customers are.
For example do you what change set number series to increment within a project, per customer or within your farm? See the following link for some of the implications:
http://blogs.msdn.com/bharry/archive/2009/04/19/team-foundation-server-2010-key-concepts.aspx
Here's what we've decided to do, since we're a pretty small company...
We're going to have very few collections. Our primary collection is called "Production" and we'll have a few others called "Playground", "Proof of Concepts", and "Educational References".
The reason for doing it this way is that our rules/workflow/data needed for work items/etc. for how we handle things is very consistent company-wide and rather than recreating this customized configuration for many different collections, we'll just use different projects for that. The collections will be for when we need to go by different rules (for example, there will probably be no check-in requirements in the "Playground" collection but there obviously will be for the "Production" collection.
So in case it's not obvious at this point, it sounds like a different project per customer is what I'm suggesting for you. But of course, it really depends on your company, how large you are, how similar your project management style is (if you do CMMI for some projects and agile for some others, you might want to separate them), and some other needs.