Jira Workflows: Best Practices und typische Fehler

Wenn ich in ein Unternehmen gehe, habe ich stets eine Liste mit Best Practices und typischen Anfängerfehlern für Jira dabei. Diese Liste wird von meinen Kunden sehr geschätzt, da sich die Fehler häufig vermeiden lassen und gerade in der Anfangsphase eines neuen Systems jeder Fehler kritisch beurteilt wird. In der folgenden Artikelserie werde ich einen Teil dieser Liste mit der Jira Community teilen und bin gespannt auf neue Anregungen und Kommentare.

Overengineering

Jira Workflows werden typischerweise den realen Arbeitsabläufen in einem Unternehmen nachempfunden. Dieser Ansatz ist soweit richtig – allerdings sollte eine sinnvolle Abwägung zwischen der Abbildung des realen Arbeitsablaufes und der letztendlichen Benutzerfreundlichkeit in Jira stattfinden. Dieser Schritt ist einer der komplexesten und bedarf einiger Erfahrung der Möglichkeiten und Grenzen von Jira. Meiner Erfahrung nach lautet die goldene Regel für Workflows in Jira:

So viel wie nötig, so wenig wie möglich!

(Oder auch das „KISS“-Prinzip: Keep it short and simple). Soll heißen: so viele Workflow-Schritte wie nötig, aber so wenig wie möglich. Welche der realen Arbeitsschritte als Workflow-Schritt in Jira benötigt werden, kann man nicht grundsätzlich beantworten, da man stets die konkreten Umstände des Unternehmens und der Mitarbeiter berücksichtigen muss. Es gibt allerdings einige Fragen, anhand derer man die Notwendigkeit eines Schrittes prüfen kann:

  • Findet ein Wechsel der Verantwortlichkeit statt?
  • Dürfen nur bestimmte Personen oder Benutzergruppen diesen Schritt durchführen?
  • Müssen Benachrichtigungen versendet werden?
  • Muss ich nach diesem Schritt filtern können, d.h. eine Übersicht aller Vorgänge im verknüpften Status sehen können?

Je mehr dieser Fragen mit „Ja“ beantwortet werden, um so sicherer sollte dieser Schritt auch in Jira abgegildet werden. Häufig werden in der Konzeptionsphase zu viele Schritte in einen Workflow eingebaut, was das Eingangs erwähnte Overengineering zur Folge hat. Ein solcher Workflow ist zwar fachlich korrekt, stößt aber durch seine Komplexität bei den Benutzern auf Unverständnis – die Folge sind Fehlbedienungen und Ablehnung des neuen Werkzeugs. Ein Negativ-Beispiel:

Die fiktive Firma RequirementsUnlimited möchte das interne Anforderungsmanagement mit Jira umsetzen. Sie erstellt daher einen Workflow, der den fachlichen Prozess bei der Aufnahme einer Anforderung widerspiegelt. Die ersten 4 Schritte für den Vorgangstyp „Anforderung“ lauten: Offen, In Abstimmung, Anerkannt, Eingeplant.

Klingt soweit ganz gut. Allerdings: um eine neue Anforderung aufzunehmen, werden bereits 4 Workflowschritte benötigt, durch die sich der Benutzer im Zweifel „durchklicken“ muss. Hier sollte man also prüfen, ob wirklich alle Schritte notwendig sind. Bei RequirementsUnlimited besteht z.B. der einzige Unterschied zwischen den Status „Anerkannt“ und „Eingeplant“ darin, dass der Vorgang in diesem Statusübergang einem konkreten Release (in Jira also einer Lösungsversion) zugeordnet wird. Auf die Frage, warum dafür ein eigener Status notwendig ist, antwortet der Projektleiter: „Ich will filtern können, welche Vorgänge anerkannt, aber noch nicht eingeplant sind!„. Mit dieser Information kann man nun guten Gewissens empfehlen, den Schritt „Eingeplant“ zu streichen: man kann per Filter auch alle Vorgänge anzeigen lassen, die im Status „Anerkannt“ und keiner Lösungsversion zugeordnet sind. Sofern die Filtermöglichkeit also die einzige Notwendigkeit für den Schritt „Eingeplant“ war, kann man diesen streichen und die vorhandenen Filter anpassen.

Im Beispiel mag es zunächst trivial klingen, ob der Workflow nun einen Schritt mehr oder weniger hat – bei größeren und komplexeren Workflows erzeugt jeder zusätzliche Schritt jedoch eine neue Stufe von Komplexität und Abhängigkeiten. Diese gering zu halten, ist das Ziel eines sauberen und benutzerfreundlichen Workflows.

Schlechte Namensgebung bei Statusübergängen

Eine beliebte Quelle für schlechte Benutzbarkeit von Workflows ist die Namensgebung der Statusübergänge. Beim fachlichen Erstellen eines Workflows ist man geneigt, Statusübergänge danach zu benennen, was im letzten Status passiert ist, anstatt danach, was im nächsten Status passieren wird. Dabei muss man wissen, dass die Namen der Statusübergänge dem Benutzer als verfügbare Workflow-Schritte angezeigt werden:

Anzeige-der-Statusübergänge-in-Jira

 

Die Benutzer von Jira wissen in den meisten Fällen, was gerade mit dem Vorgang passiert ist und wollen in der Anzeige der verfügbaren Schritte stattdessen sehen, in welchen Folgestatus der jeweilige Schritt führen wird. Ein Negativ-Beispiel:

Jira Workflow - Bad Practice

Ein Statusübergang „Abstimmung beendet“ führt beim Benutzer unweigerlich zu den Fragen „Was bedeutet das?„, „Was passiert, wenn ich da jetzt draufklicke?„. Die Folge ist wiedereinmal Unsicherheit und Fehlbedienung. Der Statusübergang sollte in diesem Beispiel besser wie folgt lauten:

Jira Workflow - Best Practice

Durch die Bezeichnung „Vorgang bearbeiten“ wird dem Nutzer sofort ersichtlich, in welchen Folgezustand ihn seine Aktion führen wird. Die Regel für die Benennung von Statusübergängen lautet demzufolge: aus dem Namen eines Statusübergang muss erkennbar sein, in welchen Folgestatus der Vorgang dabei geführt wird.

Dies waren nur zwei von zahlreichen Beispielen, die bei der Konzeption und Einrichtung von Workflows in Jira beachtet werden sollten (u.a. noch zu nennen: Verwendung der Status Gelöst und Geschlossen, Globale Statusübergänge, Vergabe von Workflow-Bedingungen uvm.). An dieser Stelle natürlich meine abschließende Frage: mit welchen Fehlern oder Problemen hatten Sie bei der Erstellung von Workflows zu kämpfen? Über Ihren Kommentar würde ich mich freuen!

28. November 2012 von Sebastian Höhne
Kategorien: Jira | Schlagwörter: , , | 9 Kommentare

Kommentare (9)

  1. Hallo Sebastian,

    danke für den guten Überblick, gerade das KISS-Prinzip bei Workflows, common Transitions, das verpflichtende Setzen von Lösungen in bestimmten Status sind auch immer wieder Dinge, die ich als sehr wichtig erachte.

    Ich würde mich freuen, wenn es zu solchen Themen also Admin-Best Practises mehr Tipps und Guides geben würde. Selber habe ich einige hiervon veröffentlicht (https://www.xing.com/topics/de/10-wertvolle-jira-tipps-fur-administratoren-102) und bislang ebenfalls gutes, weil dankbares Feedback bekommen. Ich plane es ebenfalls weiterzuführen.

    Ich habe meinem Netzwerk (einige JIRA-Admins) auf jeden Fall erst einmal Deinen Blog empfohlen.

    Weiter so!
    Kai

  2. Hallo!
    Mir gefällt dieser Beitrag sehr gut und ich kann aus persönlicher Erfahrung sagen, dass es für die Akzeptanz des Workflows sehr entscheidend ist, ihn schlank zu halten. Das angesprochene Overengineering habe ich in der Praxis mehrfach erlebt. Außerdem würde ich sehr dazu raten den Workflow gemeinsam mit den Hauptbeteiligten (idR die Entwickler) zu definieren.
    Viele Grüße
    Dominik Grusemann

    • Hallo Dominik,

      danke für das Feedback! Du hast Recht, die Beteiligten des Workflows sollten unbedingt mit einbezogen werden – schließlich sind es ja deren Arbeitsabläufe, die abgebildet werden sollen. Häufig wird dabei auch der Unterschied zwischen den theoretischen Unternehmensprozessen und gelebter Praxis deutlich. ;)

      Grüße,
      Sebastian

  3. Hallo Sebastian,

    Ich habe eine etwas andere Frage, die Workflows betreffend. Bisher habe ich in meinen Workflows die Status immer nach der aktuellen Aktivität benannt. Also „in Diagnose“, „Lösung Problem“, usw.
    Anscheinend ist das aber nicht „Best practise“!? Zustände beschreiben angeblich immer ein Aktivitätsende. Also „Bewertet“, „Implementiert“, usw.
    Aber irgendwie finde ich das verwirrend. Ich will doch beschreiben, was in diesen Status passiert, oder?
    Danke und Gruß,
    Sven

    • Hallo Sven,

      meiner Erfahrung nach gibt es da keine „entweder/oder“ Best Practice. In vielen Fällen ist tatsächlich es am besten, wenn ein Status die aktuelle Aktivität beschreibt – also „In Umsetzung“, „Im Test“ usw. Genauso kann es aber notwendig sein, ein Aktivitätsende oder eine Inaktivität als Status zu verwenden, z.B. „Anforderung abgenommen“ oder eben „Implementiert“. Das macht vor allem dann Sinn, wenn der Vorgang nicht sofort weiter bearbeitet wird, sondern eine Entscheidung getroffen werden muss (per Statusübergang) oder der Vorgang bis zur weiteren Bearbeitung in eine Warteschlange kommt. Den Status „Implementiert“ könnte man z.B. verwenden, damit die Tester einen Pool von Vorgängen sehen, der bereit zum Test ist. Wobei ich persönlich den Status dann eher „Bereit für Test“ nennen würde, denn dann muss man ggf. nicht extra erklären, dass „Implementiert“ bedeutet, dass der Vorgang jetzt getestet werden kann.

      Dass beide Varianten fachlich valide und notwendig sind, sieht man schon an den Standard-Workflows von Atlassian: „In Progress“ beschreibt eine aktuelle Aktivität, aber „Resolved“ beschreibt ein Aktivitätsende. Genauso steht „To Do“ im Agile-Workflow für einen Pool aus inaktiven Vorgängen, aus dem heraus sich die Entwickler ihre Aufgaben nehmen und in den aktiven Status „In Progress“ setzen.

      Also zusammengefasst: dass Status immer ein Aktivitätsende beschreiben, halte ich für falsch. Wenn wir uns aus deinem Beispiel den Status „Implementiert“ anschauen: in welchem Status wäre denn der Vorgang in dem Zeitraum, in dem der Entwickler den Vorgang tatsächlich implementiert? Müsste ja dann weiterhin „Bewertet“, „Konzipiert“ o.ä. lauten – das erscheint auch mir etwas verwirrend. Aber: ein Status kann natürlich auch ein Aktivitätsende oder eine Inaktivität beschreiben, u.a. wenn der Vorgang in diesem Status verbleibt, ohne dass gerade jemand aktiv an ihm arbeitet.

      Ganz pauschal versuche ich persönlich, meist (Aktivitäts-)beschreibende Status zu verwenden, da diese Variante für den Nutzer intuitiver ist. Die Aktivitätsende-Status setzen implizit voraus, dass jeder Nutzer weiß, was dieser Status denn jetzt für den Vorgang bedeutet: wartet ein Vorgang im Status „Implementiert“ gerade auf den Test, oder auf eine Abnahme durch den PL, oder auf Auslieferung…? Auf dem Papier sieht so ein Workflow schön aus, aber intuitiv zu bedienen ist das meist nicht.

      Hoffe, das hilft dir weiter. ;)

      Grüße,
      Sebastian

  4. Pingback: Was macht einen guten Workflow aus? | Jodocus.io

  5. Pingback: What makes a good Jira Workflow? | Jodocus.io

Schreibe einen Kommentar zu Sebastian Höhne Antworten abbrechen

Pflichtfelder sind mit * markiert


feedback