|
History
| Log In
|
|
|
|
[
Permlink
| « Hide
]
Gavin Bee - 21/Feb/07 11:11 PM
In a product suite approach, each shared component would be its own project. Projects would be linked together into product suites. For example, the projects (and versions) Core 3.1, WebApp 1.2, and WindowsApp 2.2 would make up Product Suite "Super Duper Suite 1.2".
Sub-projects are related to unioned filters because you could create a unioned filter that represents "Unresolved issues in Product X version 2008" by unioning the "Unresolved issues in Project 1 version 2.4" and "Unresolved issues in Project 2 version 3.2" filters.
I have linked all of the sub-project and sub-component issues that I could find as being incorporated by this issue. I believe that one single feature could satisfy the use cases outlined in all of these linked parts.
I hope that seeing all of these issues together clarifies the demand for this feature. I think this is a very good idea.
We use JIRA for keeping track of issues in embedded systems - both the software and electronics. One such product contains 3 pieces of software (application, bootloader, self-test), and 2 PCBs (motherboard, communications board), each of which has its own version label and components. Together they make up a single assembly, which has a corresponding assembly number. At present, each of these parts is a project in itself, which is not ideal - not least because you don't need many products being tracked on JIRA for the project list to become very, very long. The Categories function could help a bit - but we're reluctant to spend $4000 to upgrade to the Enterprise edition for such a small change in functionality. Having "suites" (or assemblies) would tie together the various projects making up a product very neatly. While unioned filters is a wonderful idea, it's not exactly user-friendly. You might satisfy the technical people, but it will confuse the hell out of every non-engineer who has to interact with JIRA. At our company, the number of non-technical people interacting with JIRA is very large, which is good. Half the reason for having such a system is to provide external visibility into what we're up to.
In order to keep from confusing the users, we've had to oversimplify our components and projects - we were spending far too much time correcting poorly-chosen components previously. This solution has reduced frustration on the part of the users at the expense of the software team - very broad components (ex. "Appliance back-end or support processes" - this appliance has dozens of processes, daemons and jobs running on it) result in more accurate classification, but effectively make JIRA useless for tracking issues with specific pieces of software in a large system. Understand what this means: we cannot use this tool to help us plan long-term improvements to our product based on defect rate analysis without a painful, manual data-mining processes. Subprojects or subcomponents allow us to present the increasingly granular details of the product in a simple, logical fashion. They also allow a user to say "I don't know which of the subcomponents to pick, so I'll use the parent (general case) instead", while giving us the ability to properly classify that issue when we receive it so that we can properly associate a defect with a piece of software. Splitting the components across projects works (we did this originally), but it makes release management a nightmare. I agree that a single feature should satisfy most of these use cases. n-level nested 'projects' are fine, n-level nested 'components' are fine - it doesn't really matter what they're called, IMHO, just that this ability to organize hierarchically exists. The ability for a sub-project or sub-component to have multiple parents would be unbelievably good - it would satisfy the 'suite' or 'product' use case as well. I think this is a very useful feature for sizable projects. We are currently looking into buying JIRA Enterprise edition and ability to have sub-projects is really crucial for us. Does anyone have an idea when it will be implemented?
I would agree with all of the comments here. We are currently managing approximately 8-10 JIRA projects for a Weekly Release cycle and use Filters to try and gain full visibility to the current status of the tickets. This is painful. We are considering making all of the projects Components instead as a hack/workaround, but now face the problem where a true project might require or benefit from Components.
All of the "goodies" you get with a proper Project are lost if we switch to treating/converting Projects to Components (i.e. the Roadmap, the Calendar, Popular Issues links on the Project page, etc.) In addition, any time we conduct an adhoc search, we had better remember to include all the Weekly-type projects or our results are incorrect. We have 8-10 Weekly Release type of projects...and another 10-15 or so that are not Weekly Release projects. It's currently a lose-lose situation. There are a lot of issues at the point that Jira works project based and not product based. According the number of issues i think they choose the wrong product. I think we are one of them. We are using Jira enterprice and the enterprice version is very limited in working product base.
Implement I would like to add an other feature. Make it possible to have schemes for versions. The reason for this Last point: Can atlassian finally a making a decision what happening with issues older as fi 2 years. So that customers can decide what to do with Jira. None of the issues in the Popular Issues list is assigned to a new release. Hey All,
The feature to have sub projects is a huge feature and a great reason for people to upgrade. We have been using Jira for a year or so and we decided not to continue our subscription due to not having this feature. We will upgrade asap when this feature is implemented. for example: Project Build a Car Very useful |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Major
Support for Product Suites / Sub-Projects
