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.
Related
I am to set up Jira in my organization and there arise some questions, for which I could not yet come to a, for me convincing, decision... may you give me your opinion, what the best configuration would be?
(I will be talking here about projects but it might be found out, that should later be boards or whatever)
I have requested my org the creation of a Jira account for my department, and as seen from the settings, I got created a Board associated to me as an admin
We are a team of 15 people in the department
We want to start setting 10 different projects, some might be related to the other ones but still keep an individual sense, thus, each should have its own Backlog
The scheme of the projects should all be the same (notifications, workflow, issue types...). Ideally, if changing something lately in the scheme, all projects should actualize to this automatically
We will be all teammates allowed to work on all projects within the department, always, no restrictions
We want all to be able to check for the statistics etc. related to any project in the most easiest way
Users want to have on their board (screen) all projects and tasks, in the order planned for them to be performed, don't matter if they belong to different projects. Desired view would not be a flatt Kanban but issues being classified by Project > Epic > Sprint
The ideas I came up with are:
(1) Me --> Board --> 1 JiraProject --> n Epics (each = OurProject)
Having just one project (namely, the name of my department) and then create one Epic for each "real" project we want to handle. Then, to each Epic create the Issues related to each of our real projects. The problem with this is, that we would need a second level of Epics to suborder into each of the main Epics (representing our real projects) so that we can group their issues into logical parts of the project. This second level of Epics seems to me not to be possible. Additionally, this approach will just provide us with one Backlog common for all our projects (here provided as Epics).
(2) Me --> Board --> n JiraProjects (= OurProjects) --> each JiraProject
This seems to me to be the best approach, but has the inconvenience, that when a person has to work on several projects he has not the insight of the order of the tasks he has to perform, nor if any of these collide in time with any other of any project.
I ended up creating a single Project with a single Board.
In Project Settings (left side panel, bottom):
I enabled Components to appear on the left side panel
I set Issues to show the field "Component" when they are created
The Jira logical classification will be now like this:
PROJECT is my department
BOARD is the common view all users will share
VERSIONS are Versions
EPICS are my different Projects
COMPONENTS are now a kind of Epics for my projects, but with the disadvantage that:
a) they are all shown in a separately view, not as a side panel similar to VERSIONS and EPICS
b) they are all listed straight forward, which requires to give an identifier at the beginning of their name to differentiate to which Project they belong to
USERS: all Users will manage to see the main Project (which is my Department) and inside of it, all the Epics (which are my Projects). This was initially my requirement, so it is ok.
I wish Jira was a bit more flexible on letting us creating some additional group categories similar to VERSIONS and EPICS, so that we could get and extra group layer.
The use of Components here is not really very useful, but also confusing and not intuitive, but is the only option available at the time of this post to extra group somehow my Issues.
Problem:
Customers that become access granted, can access and see all or projects, what is naturally not good!
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 project with multiple customers. Suppose application name is Ali-Systems. Foo company will have Ali-Systems Foo, Bar company will have Ali-Systems Bar and so on. All versions have almost same structure. But their logic are different. For example there's a BillIssue method for all versions, but its logic may be different. Either how to calculate or even the difference between their DB models(we are using ASP.Net MVC Entity Framework)
As I understand there is some branching strategies categorized by Microsoft like Development Isolation(which enables
concurrent development of the next release, experimentation, or bug fixes), Release Isolation(which enables concurrent
release management), etc.
Can I take advantages of Branching for this purpose and how? Or I should create separate repository for each customer's project?
NOTE : In fact I want to clone the base of a project to some derived projects which will never merge again together. But we must able to add features to all derived projects(probably with help of another branch)
Microsoft has Visual Studio Team Foundation Server Branching and Merging Guide , that can be used to choose the branching structure. Including Main Only,Development isolation,Feature isolation,Release isolation,Servicing and Release isolation,Servicing, Hotfix, Release isolation...
In your case, the core of the project, is similar , but for each company has its own personalization of the product(logic / DB models ), and maybe will evolve independently in the future.
Using some branching structure, the main limitation it becomes a maintenance nightmare for solving bugs and global changes.
For example, if you want to merge changes from one company to another was very complex and it required retesting each version separately . Moreover, for bug tracking, one team will solve the bug in their version and another team will have to merge that change from the version they don't fully understand.
To support such development scenario suggest to share extensible core
and data model which will be configurable from upper customizable
application layers. This core should be used as the base for each
customer/company specific customization and maintained by separate
team(for each company). It will include some management complication
because multiple project managers may need resources from the same
team but it is a good way to make architecture consistent, control the
whole process and keep versions in sync.
Besides ,if a person or team need to work across multiple companies in the local machine, one way to keep the local environment clean is Using multiple workspaces with Visual Studio
In our company there are a lot of projects that are connected by resources (people). So, people from one project works in onother one too. We are going to create Global Iteration (Iteration Path) that to assign items on it from different projects that to see all planned work in one common backlog.
But as far as I know it is not possible to do that for different projects.
Moreover, combining two projects is not a solution for me. Any ideas?
PS: I know the advantages and disadvantages of Single project (see topic) but it is not my case.
Currently, you can't show work items from multiple Team Projects on a single Kanban board in TFS.
As a workaround, you can either create your own query as #DaveShaw mentioned, or use one Team Project with multiple Teams and use features from Agile Portfolio Management. See https://www.visualstudio.com/en-us/docs/work/scale/portfolio-management
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