I have a question.
Lets say I have 3+ projects in TFS
For example
Microservice A
Microservice B
Microservice C
And now my company sign 2 contracts. With Company ABC and Company ZYX.
Now Project Manager want to open tasks for 2 projects - Company ABC and Company ZYX.
But those tasks associated with ALL MICROSERVICE .
That is mean he is need to open tasks in each projects in TFS.
Question is:
If he able to see what is status of projects (where projects is project with Company ABC and Company ZYX.)
P.S - Integration with Project Server is not good. Looking for something else (better inside TFS )
You could create a task in every team project that has work to be done and use tags in tasks, user stories, etc to track for which customer it is for.
Create a custom cross project query to get all you workitems.
You could filter by tag or list all tasks and put the tag as a column.
It's not suggested use one team project for two companies. For enterprise-level organizations, it may be necessary to scale up, to create additional teams and/or team projects. These can be created within the single account or collection. Please check the following link:
https://learn.microsoft.com/en-us/vsts/work/scale/scale-teams?view=vsts
Related
We have a department team section in JIRA setup as a project and I have been asked to create Kanban boards and set the section up ready to use but I'm not sure the best way to apply the work the department team is managing into JIRA.
We want to have Kanban boards for two different specialties and for e.g. one of the specialties we have two projects and one of the projects has a subproject and also one of the projects may sometimes overlap with both specialties.
For example:
Build team
Development Kanban Board
Project A
Project Sub Project/Stream A
Project Sub Project/Stream B
Project B
Test Kanban Board
Project A
My current thoughts are:
Project = Team
Component = Project A
Epic = Project Sub
Project/Stream
Labels = Specialty Kanban Board
Is the above correct or is there another approach that would be best practice for this scenario? At the moment I think we are tied into having the Project in JIRA set as the team
Usual practice is to make your projects correspond to JIRA projects (thus the name). You can set up the filters for Kanban boards to bring in issues from multiple projects according to whatever criteria you want. This will make it easier if issues need to flow from the dev team to the test team. The "Team" can be defined by assignee, status, or another field if you prefer. Epics are good for time-bounded subprojects, components are good for ongoing subelements (e.g. UI, database, etc.).
I have inherited a TFS 2017 on-premise. It has 1 collection which contains 10 projects. Each project has its own work items, builds, source code and produces a separate application/website. This all makes sense from a developer perspective as all the software is independent and builds/releases separately. Each new 'business project' however does tend to span multiple 'TFS projects' in order to deliver the features needed.
How is it best to organise this from a management perspective?
Options:
1) Create a 'Management' project that has no code or work items but just has dashboards and queries.
2) Put all the code into one project.
3) Create a 'Epic TFS project' that just contained Epics - with PBIs in the relevant TFS project.
4) Secret option 4 that I don't know about.
Use one team project with multiple teams underneath.
Your current structure is like this:
Team Project Collection
Project 1
Project 2
Project N
The structure you're after is this:
Team Project Collection
Project A
Team A
Team 1 (corresponds to Project 1)
Team 2
Team 3
Basically, each Team is assigned to a separate area path. You can use the hierarchy of area paths to subdivide everything so that it can be rolled up and easily reported. In the example above, you can report on Team A (which rolls up Team 1, 2, 3), or on each of the Teams individually.
Each team can have its own separate subareas, iterations, etc. But all source code, builds, and so on live within the same team project. Access to those entities can be controlled via security groups.
Now, the question of "How do I go from the current structure to the new structure?" is a much bigger problem. There's no easy way to combine multiple team projects.
I've recently completed the deployment of TFS 2015 Update 1, we have around 15 development teams in the UK and previously we have always structured our TFS projects as follows:
Default Collection
Application 1 (Team Project)
Application 2 (Team Project)
This caused issues with sharing work items across teams as it is difficult to move WI's across the project boundary.
Rather than create a new team project for each team, I want to manage things with a single team project and create separate areas\iterations\teams for each one. So:
Project Collection > Master Team Project > Area 1
Area 2
Area 3
etc
in terms of permissions I would like to add in each of the standard TFS permission groups to each area. I would also like to create a root folder for source control for each area.
At the moment I can't work out how to do this? Can anyone help?
I suggest you to look at the some community suggestion on this topic.
One Team Project to rule them all
Why You Should use a Single (Giant) TFS Team Project
How to implement a multiple team strategy in Team Foundation Server 2013
In general it is a good practice (I won't say best practice as it is not the right thing to do in some cases).
Regarding you question, you should focus on Team to define developers access, and TFS groups for general (e.g. administrative) access.
I'd recommend you to use the multiple teams feature in TFS2015. It allows you to manage the team members, permissions, work items more easily. And you can track the entire project status from the team project page and track the individual feature team status from their own project page. The work items can be also moved between the teams easily (Just change the area path). Refer to this link for details: Multiple Teams
I have been reading a lot on the recommended project structure in TFS. I am considering moving my company to Visual Studio Team Services (was VS Online) and have been trying to set up and test to get my head around how it will work. Based on articles I have been reading, it is recommended to have one team project with many areas/iterations/teams (http://nkdagility.com/one-team-project/, http://nkdagility.com/working-within-a-single-team-project-with-team-foundation-server-2012/).
What I am struggling with is how to make this work for my specific environment and what I would like to see. We are a small development team consisting of myself as a manager and 2 developers. With our current structure (outlined below), I cannot see across team projects for our full backlog. To see how individual work is progressing, I would have to go into the individual team projects.
Current Structure
TFS (Server)
Accounting (Collection)
Application 1 (Team Project)
Release
Test
Application 2
Engineering
Application 3
Application 4
I like the idea of being able to see a master backlog and then assign work items to the individual projects. However, I would still want to be able to manage sprints and see burndown charts down to the individual project level. For example, if developer 1 is working on Project 2, I would like to assign PBI's to that project and see the burndown chart at that level.
New Structure
Team Services (Service)
DefaultCollection (Collection)
DefaultProject (Team Project)
Accounting (Area)
Application 1 (Application)
Application 2
Engineering
Application 3
Application 4
Basically, as a manager, I am looking to be able to see a status of where we as a department stand in our overall backlog. As a developer, I want to know what items are assigned to me, regardless of which application they are related to. Am I on the right track for this? In typing this question, I've almost convinced myself that I don't actually need to know backlog of an individual application. Rather, I should be managing all of the work across all applications and using that as a sprint backlog. Sometimes this sprint will be multiple releases in larger application and sometimes this sprint will be updates across multiple smaller applications. Any help that can be provided to help point me in the right direction will be appreciated.
You can create multiple teams in the same Team Project and you can nest them to facilitate hierarchy.
http://nkdagility.com/creating-nested-teams-visual-studio-alm/
You can see how to configure this in my post above. It's fairly easy to use...
The new structure is good. And you can create two teams from your project Control Panel\Overview: one for Accounting and one for Engineering. Check "Create an area path with the name of the team" option when you create the team. Then you will have 1 overall project page for your team project and 2 sub project page for Accounting and Engineering like following:
In the overall project page, you can manage your overall backlogs, check the Burndown charts for the whole project. And in the sub project page, you can manage the backlogs and check the Burndown chart for individual project.
I'm new to Team Foundation Server 2010 and I have a question about permissions.
Is it possible for a project to inherit permissions from a project collection? I want to setup a custom contributor group at the project collection level and add the developers to it. Each time they create a new project I want to inherit the permissions from the project collection. That means I don't have to explicitly add the developers to the project each time they create one.
Maybe there is some other way of doing this and not having to setup a custom contributors group? Any help would be appreciated!
I would recommend setting up some Active Directory Groups along the lines of:
TFS Contributors
TFS Administrators
TFS Project Managers
(You could also do this for specific projects. You get the idea.)
Give these AD groups the permissions you need, and simply add/remove the developers to the AD groups. If you can get the ability to manage the AD group, this will be much simpler that administering through the TFS admin tools.
Hopefully, you'll already have AD groups that fit these needs, saving you the trouble. Maybe a team-wide distribution list, for example?
You can create collection level roles (TFS Groups) and edit your process template to grant permissions to those roles so there are set by default in every new project.