Sidehistorik
Working as a consultant on JIRA and JIRA workflow, I have done some observations that I would like to share - hopefully brining some success into Your project and implementation.
Face the music (real life)
No workflow can be made on a piece of paper and be expected to work
No workflow can be made in JIRA (possibly from a piece of paper and be expected to work)
The only way to success in to get the hands dirty, sit down with the participants or "stockholders" - people with involvement and the daily participation in the processes and communicate
Train, test, change/ implement and repeat (A analoge to the The Cookbook principle for Changes and SOPs
Be the "Devils Advocate"
Ask questions, be opposite (in a nice maner) and ask again - "are this really needed or the way You actually do it?" No to be arrogant, but sometimes the thought of "what we do" and "what the hands (and other people) do" - are not equal.
KISS - Divide and Conquer
...
Keep Your workflows relative simple, and break them into sub-workflow handled by subtasks or links sub-issues or linked issues if possible. This has several advantages:
...
B. Specialities, as different Workflow for same issuetype in 2 projects are easier to maintain, as over issue types can still share the same workflows.
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.
...
In JIRA, Parent and Childs have different Issue TypeIssuetypes, ater after my openion opinion rather stupid, it could just be a setting like - this Issuetype can be: 1) Parent Only 2) Parent And Child or 3) Child only....
...
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 ScriptRunner for JIRA plugin and several of the JIRA Workflow Plugins - conditions, validations and post-functions are able to handle links to...
...
Remember, all changes are tracked, just dont don't let people have deletion rights.
...
| Tip |
|---|
A. Assigning the Issue to another user (out of sight) B. Close an issue (getting it done) C. Sharing the Issue with another user (can be making a subtask for fullfillmentfulfillment) D. Money (Bonus) E. Serious goodwill |
...
A. Only to make steps that fulfills triggers the drives/motivators mentioned above in the box.
...
| Gliffy Diagram | ||||
|---|---|---|---|---|
|
Hence, at least we need custom fields for "Incident start", "Incident End" fields for the white dot times, as the "issue createdtimes on the Issue "Created" is the red dot, and "Issue Resolved" is the Green dotgreen dot - these does not represent the real times.
| Tip |
|---|
The simple solution is to boil down a very ambisioned ambitioned workflow with a lot of transitions to the needed ones, often identified by the fact that the assignee changes with each transition. |
...
Workflow can be extended heavily with Plugins and custom code - but be aware this requires extra maintenance on the JIRA installation, and the risk of breaks are higher, getting raised for every extra plugin or code.
Is dont don't say, "dont don't use" - but "use with caution and keep everything updated".
...
Using a Log tool such as splunk or similar
Documentation
This should go without saying; - documentation and training are always needed beside the "technical" part...