Having recently migrated to TFS 2010 I was wondering what the best or most widely accepted definition or configuration is for an Area?
The only useful article I can find online is this one and is what I would have assumed to be correct. However it got me thinking if any of the following is indeed more widely accepted.
Areas by business functionality
Areas by technology
Areas by system layer
Areas by physical or geographical location
It really depends on the product/project you 're building, I suppose it was made available as a general-purpose placeholder which can get its meaning from the context of the team & the team mission.I can imagine projects, where ignoring it on the grand total, would also be a perfectly acceptable solution.Our initial TeamProject structure in fact did ignore Areas for our flagship product we construct in a Team Collection. This resulted in a reporting nightmare, since we needed it on a platform-level (TeamCollection), rather than a distinct part of it (Team Project). When we realized the problem, we went searching & found this article, which made us change course: we are now using TFS Areas within one single Team Project & found what fitted best to our situation. In our universe Area = a distinct release line within the platform.
Areas in my opinion is a grouping mechanism, with Areas you can group your wortitems in any kind you want.
I think everything which fits to your development process and or make you more productive is ok.
All of your items on the list are valid types of areas, I saw all of them in projects.
But too deep hierarchies are not really helpfull, because if you create a workitem you than you have to choose/select the right area.
Related
My questions are listed at the end of this post but reading the background info first will help understand the context of the questions.
Background
I've had some limited experience working with TFS (on-premise) as a development team member in the past, and I'm generally familiar with the basic concepts. But now I'm also tasked with administering a VSTS instance (cloud). Most of my experience using TFS was centered around the project management features (backlogs, sprints, work items, etc.).
I'm rolling out VSTS in 2 phases. The first phase focuses on the non-technical project management aspects of the configuration. The second phase will focus on technical aspects such as managing source code and other development artifacts. I have some experience working with the source control aspects using TFVC repository, but no experience with Git repository.
I completed the preliminary design of the basic configuration (Teams, Area Path, Iteration Path, etc.) for VSTS. I suspect that my Area Path will need adjustment at some point in the near future. From what I've read, VSTS does a decent job of automatically updating Work Items (e.g. Features, Product Backlog Items, Tasks, etc.) when changes to the Area Path are made.
Questions
What I'd like to know is how other technical areas of the product (e.g. code repositories, build definitions, etc.) are affected when changes are made to Area Path. For example, if I inserted a completely new node somewhere within the Area Path, how badly will that "break" existing VSTS functionality (and what type of functionality will be broken and require manual repair)?
This is an easy one:
Area paths only affect work item tracking. Period.
Trying to figure out best way to setup Jira for cross-organizational project. We have a Continuous Delivery Program that will split off into separate backlogs to be worked by different teams based on Themes.
Wondering if we should setup one project to manage the overall high level project, and then different projects per theme of work that will be managed by the individual teams.
Are there ways multiple teams can work out of the same project but track their work separately (including if their work is Kan-Ban, Scrum-Ban or Sprint based?)
Regarding the question in the title. It's possible to move issues in JIRA from project to project. This feature is quite handy and you even can do bulk operations. See Moving an issue for more details.
Regarding structuring your projects. Out of the box there is no feature in JIRA to create such a workflow with projects and sub projects you have described.
A possible workaround could be using components as sub projects.
In this case you would create a project which act as your high level project and divide this project into several components. For components you can add a lead, do versioning but you can not set security permissions based on components for example. So this is not a perfect solution and have indeed some limitations since components are not projects. But you have to evaluate this approach by yourself if it is sufficient for you.
Another option would be to use a plugin e.g. Structure. I am pretty sure there are even more out there which promising to solve your problem. From my experience also using a plugin may be not the silver bullet you are expect. You have to evaluate it first if it really suits your workflow.
For the scenario you describe, the issues that you start from are probably more high-level than the actual work that has to picked up in the separate teams.
What I find to work well, is to keep 1 project (ie. Opportunity Backlog) for the high level issue (ie. an Opportunity) and when an opportunity gets detailed out, just create issues in the projects of the teams that will work on them. You can still link those issues to the opportunity so people who look at it can see what is happening in each team.
Another option is to keep everything in 1 project, but to make the relevant issues show up on the board for the team that has to work on them. A board can list issues of multiple projects. You just need to update the JQL query for the board accordingly. For more details, check the documentation. Note that working with sprints can get cumbersome if the same issues are listed on boards of multiple teams though. Best to configure things such that an issue is only displayed on the board of 1 team.
I wouldn't bother with moving issues too much. It's not a very user friendly action.
We've been using Fogbugz for a few months now, and have about 6 projects (aside from the default Inbox project for incoming mail).
We work in week-long sprints, so we have set up global milestones for each week to prevent having to enter them multiple times (for each project).
The iteration planner doesn't support planning for multiple projects simultaneously.
As we are sprint planning in a global fashion (across all the projects at once), would having one project with multiple areas be a better fit for this workflow/planning?
Does this go against a design principle of Fogbugz, or will it make some features not work correctly?
The documentation on Projects and Areas doesn't mention pros and cons of one over the other.
Lou # Fog Creek replied:
I would say that, instead of pros and cons, there's an idea of grouping for the purposes of planning. Planning units should get their own projects, and any natural subdivisions within that unit most likely merit an Area. The main advantages of Areas is being able to have different primary contacts for workflows and organization.
So it seems the overall design concept of Projects is something that is individually planned, and in this situation, all our activity fits into one Project.
My company started using JIRA for issue tracking two years ago, and we have struggled with optimizing the workflow for it since. The main problem is that we have a number of modules and libraries that are shared between different products, whereas JIRA has a "silo" view of projects. Basically, JIRA is fine for tracking issues from a "customer project" point of view, but I started to see it as more and more useless for a "back-end development" point of view.
JIRA's components are not good enough for my needs, since the developer of the module or library cannot correlate the issues appearing in different projects for her module and assign them to different versions of it. What I need is a hierarchy of projects, where a component in a higher (product) level project relates to another project at a lower (module) level.
Atlassian seems to be unwilling (unable?) to add such a feature to JIRA, despite numerous related issues dating back up to nine years. Moving to another issue tracking software that has this feature (if there exists any) is not feasible for us at the moment, though.
Judging from the number of replies on the related issues in Atlassian's JIRA system, we can't be the only company with this problem, so I would like to know what other people are doing to get around it.
My current plan is to use components for the product projects, and automatically create and link clones of component issues in the relevant module/library project. Clones are sub-optimal, since they are not as strongly linked to the original as I would like, and they double the number of issues in the system (or more, if the issue in the module project needs to be duplicated in other higher projects, say, if the fix would break the API or if it was a critical issue that any user of the library should be warned about), but I'd like to keep the original, since after fixing it in the module and closing the module issue, there'd be more time needed for integrating the fixed module into the product.
I have found plugins that allow post-functions on transitions, e.g. "CustomWare JIRA Utilities", so that should work for automated cloning, linking, and updating, although I am not 100% sure.
What is missing, though, is a good way to manage the dependencies between the different versions of products and modules (i.e., version X.Y of product A uses version I.J of library B), since versioned components are another thing that JIRA doesn't do.
Any better ideas?
I would treat reusable components the same way they're treated for distribution (e.g. DLLs), as separate projects in Jira.
Track your issues against the affected version of the module. You can always move an issue between projects if it's discovered to be a different part.
This won't help maintain cross project mapping (I.e. System A v1.3 requires Component B v2.7) but it becomes simple enough to dump in a Wiki.
Another approach is to create your own multiselect custom field, make it valid across multiple JIRA projects and use that instead of the system components field. You would lose the ability to automatically assign issues but gain the ability to use "components" that are valid in more than one project.
~Matt
OnTime uses a tree-based structure for projects, allowing you to open a filter to view descendents as if they were on the current branch. I don't know if that is much help for you.
I was wondering if someone could tell me what area/iteration in Team Foundation Server WorkItems is and how it should be used with projects?
Is it as simple as:
Area = Project Collection?
Iteration = Version Number?
I can't seem to find much information on what these are and what they are used for?
The short answer is that the area classification is the logical division of your product or project, and the iteration classification is its chronological breakdown into releases and development iterations.
The area path describes the logical part of the system that your work item relates to, e. g., which module or subsystem some bug was found in.
Likewise, the iteration path tells you which iteration put release a work item should be handled in, for example, this task is for the third iteration of the fifth release.
The logical and chronological breakdowns can be done any way that makes sense to your team, as long add the structure remains that of a tree.
Does this help?
Assaf.
The application and usage of areas and iterations seems to be a difficult choice for quite a few (myself included). There is of course also the consideration that you might want to have one or two physical "TFS projects" and place all your projects under that separated by areas and a larger hierarchical structure.
This blog post has some intersting questions and answers showing pros and cons on the matter:
http://blog.hinshelwood.com/when-should-i-use-areas-in-tfs-instead-of-team-projects-in-team-foundation-server-2010/
One cool explanation that stuck with me is this one "think of Areas as slicing and dicing a team project by “functionality” (like UI, Business Layer, DAL etc), and think of Iterations as slicing and dicing by “time”. Iterations are like “phases” of a lifecycle, which can dissect the timeline of a project effort into more manageable time-based pieces."