Du ser en gammel version af denne side. Se den nuværende version.

Sammenlign med nuværende Vis sidehistorik

« Forrige Version 3 Næste »

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.

 

KISS - Divide and Conqur

 

The human factor

Thing is to bring up a question:

What "drives" a normal JIRA user to make a transition?

A. Assigning the Issue to another user (e.g. getting it done/out of sight)

B. Money/Bonus

C. Serious goodwill

 

Most of the time, "A" is the common (and powerfull) reason that drives the normal JIRA user.

One of the most common things I encounter, is the diversity between some one's reporting "needs" versus the number of steps in a workflow, lets take the good old "Incident Management" process (a small version), that could be:

HumanFactor1

Now, Support Managers what to log all times in all of the JIRA "phases" - hence 3 times:

 

  • Diagnose done  (Status going from Open ->Under investigation)
  • Investigation Done (Status going from Under investigation -> Under Resolution)
  • Resolved (Status going from Under Resolution -> Resolved)

In real life, if the JIRA user handling the Incident is that same, he will typically make the 2 last transitions right after each other, or perhaps if this is late and he is tired, the next morning. 

I have seen this all the time in reallife systems, users does not transist Issue unless one of the reasons above is the motivator.

The solution is 2 parts:

A. Only to make steps that fullfills,

B. Make a "post" function that collects/enter the correct times. 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. 

The use of Plugins and manual code

Documentation 

 

  • Ingen etiketter