Hi,
We are in the process of planning a JIRA/Fisheye implementation and are getting caught up in the different approaches could be taken with respect to project/task and component organization. In some ways I'm quite embarrassed to ask this as I doubt we are very complicated in the grand scheme of things, but here goes...
Ive tried to explain our situation as best I can below. It is quite long, so in summary:
I was hoping that somebody might be able to kindly offer their experiences or advise on handling situations where changes may span multiple system, and where there are different formalities of change request.
The long version is….
We are a team of 10 developers looking after ~50 systems. Our work consists of :
Small ‘business as usual’ (BAU) requests (eg, bug fixes / minor enhancements) that tend to come to us in an informal manner (email, phone, conversation)
Larger scale projects (referred to as internal projects from now on to differentiate from JIRA projects) that come to us in a more formal, documented manner.
BAU and Internal Project work can affect either single or multiple systems. Two simple examples would be…
Single System Change : Allow capturing of new data attribute to the trading system.
- Task : Database schema changes
- Task : New front end screen
- Deliverable : New build of trading system front end
Multi System Change : Build feed between Trading System and Fund Accounting System
- Task : Trading System : Extract changes to message bus
- Task : Fund Accounting System : Import notifications from message bus.
- Deliverable : New build of Trading System Backend
- Deliverable : New build of Fund Accounting System Backend
When we release software, we need to pass down a release ticket number. These are generated outside of our team (so cannot (for now) be JIRA numbers) and there must be one release number per system – ie, the multi system change above would have 2 release numbers.
We currently produce weekly reports to management (booo) that show the team activity for all our work. Project related report is grouped by project and then system, and the BAU report is grouped by system. (Note: The format of these reports can change)
As a starter for ten, our initial thoughts were to:
- Setup different task types for BAU and Internal Project work in order to allow us to capture the different data associated with each (eg, Internal Projects have project codes and external priorities that would be good to track in JIRA, where as the BAU work is lacking this)
- The 50 systems would be represented as components
- Setup a Development Work project that contained all accepted development tasks regardless of system.
- Single system change work would be handled the task/sub-task relationship. The sub tasks would be assigned single component to reflect the system, and the per system release numbers discussed above would be stored per sub-task.
- Eg, Parent Task : Build feed between Trading System and Fund Accounting System. Component: Trading System + Fund Accounting System
o SubTask : Extract changes to message bus – Component : Trading System
o SubTask : Import notifications from message bus – Component : Fund Accounting System
- Multi system change work would be handled the task/sub-task relationship. The sub tasks would be assigned single component to reflect the system, and the per system release numbers discussed above would be stored per sub-task.
- Eg, Parent Task : Build feed between Trading System and Fund Accounting System. Component: Trading System + Fund Accounting System
o SubTask : Extract changes to message bus – Component : Trading System
o SubTask : Import notifications from message bus – Component : Fund Accounting System
- Set up one project to act as an requests capture queue where the adhoc BAU requests could be placed prior to processing, rejection, acceptance, allocation, etc. This could be hooked up to a specific new-requests email address, or, ideally, we ask our the people making these requests to always make them via a screen so that we can ensure that a minimum level of information is included. If we accept a request, we will move it into the Development Work Project, linking it to components, possibly assigning to developers, and creating subtasks for the multi system related work.
Now, this seems to get us to a usable point, but there are a few things that smell bad.
- Is this a misuse of components? Shouldn’t component reflect the subcomponents of a system (eg, Backend, Frontend, Database, etc). Given the high level (mis)usage, we cannot break down further into sub components
- Is this a misuse of projects?
- Should there be one project per system? This seems to be the way with the Atlassian systems on their own JIRA, but how would this work if a project crossed systems?
- Should there be one project for all BAU work, and we create new projects for the longer running internal project work?
- There would be repetition of the bespoke project fields across each of the project tasks.
We’ve thought about alternative approaches, but they seem to have other problems. The obvious one would be to set up a JIRA Project per System, but…
- How would cross system changes be handled? I know we can link issues. Maybe we could create a parent issue/child-issue link relationship…. ?
- If Internal Project tasks were scattered over multiple JIRA projects, can you see them all in one place? Can you report across projects?
- Where would the container task live? Perhaps we could nominate one of the systems as an arbitrary home. Maybe we should have another JIRA project to house cross system work so that we can see them in one place… ?
Maybe the above plus the following plugins would be a good way to go, but I was hoping to stay fairly vanilla to start with
Multilevel Issues : https://marketplace.atlassian.com/plugins/com.almworks.jira.structure
Linked Issue Reporting : https://marketplace.atlassian.com/plugins/com.docminer.jira.issue-links
Another alternative we’ve considered would be to use JIRA projects to represent the Internal projects (rather than diff task types). The tasks would at least have a natural project grouping and it would be good to have dashboard metrics through the life of the project, but we would still have issues with representing cross system tasks, I’m not sure if it would be possible to perform cross project consolidated reporting (it appears that project cannot share components), and the BAU project is a an arbitrary catch all bucket. There would also be more admin involved in setting projects up (rather than simply creating a new Internal Project Task).
We are going to model a number of scenarios using various approaches and evaluate in terms of task setup, data repetition, ease of navigation, visibility of grouped items of work, and intrusiveness of workflow and report-ability, but any pointers would be greatly appreciated.
If you have read this far, many thanks for your heroic effort and for any help you may be able to provide.
Thanks,
Stu
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.