Sidehistorik
...
C. Parallel processing can be done on sub- or linked tasks by several other Assignee's - whereas one large workflow is serial with one Assignee at the time.
Tasks or subtasks?
In JIRA, Parent and Childs have different Issue Type, ater my openion rather stupid, it could just be a setting like - this Issuetype can be: 1) Parent Only 2) Parent And Child or 3) Child only....
For example; at my work we have Changes and (yes) - SubChanges - hence 2 IssueTypes to maintain...
Learning more and more, I tend to prefer linking over child (sub) issue types, as they are more useable for every purpose, and the binding is as "strong" as in Task/SubTask relations.
With the Script Runner plugin and several of the JIRA Workflow Plugins - conditions, validations and post-functions are able to handle links to...
Have a loose view on restrictions and conditions
Also, take a loose a perspective as possible on restrictions and conditions, setting the workflow up with tight restrictions breaks agility in the real world, for example under illness and leave, issues can be stuck.
Remember, all changes are tracked, just dont let people have deletion rights.
The human factor
Thing This is to bring up a question:
...
| Tip |
|---|
A. Assigning the Issue to another user (e.g. out of sight) B. Close an issue (getting it done/out of sight) BC. Sharing the Issue with another user (can be making a subtask for fullfillment) CD. Money (Bonus) DE. Serious goodwill |
Most of the time, "A" and "B" is the common (and powerful) reason that drives the normal JIRA user.
...
| Gliffy Diagram | ||||
|---|---|---|---|---|
|
Now, Support Managers what want to log all times in all of the JIRA "phases" - hence 3 times:
...
In real life, if the JIRA User handling the Incident is that same, he will typically make the 2 last transitions (e.g. clicking the buttons) right after each other, or perhaps if this is late and he is tired, the next morning.
...
B. Make a "post" function that collects/enter the correct times in additional fields. In the case above, the Service is down before the Incident is created, and up before the user resolves the issue, there times can be entered manually.
| Gliffy Diagram | ||||
|---|---|---|---|---|
|
Hence, we need "Incident start", "Incident End" fields for the white dot times, as the "issue created" is the red dot, and "Issue Resolved" is the Green dot.
The use of Plugins and custom code
...