Das ist der letzte Teil aus der zweiteiligen Serie über Workflows in Jira-Software. Wenn Sie den ersten Post über die Jira-Workflows noch nicht gelesen haben, empfehle ich Ihnen sich zuerst den ersten Teil durchzulesen und anschließend wiederzukommen. Für alle, die den ersten Teil bereits gelesen haben, wird dieser zweite Teil aufgekommene Fragen beantworten. Mithilfe von Anwendungsfällen aus der Praxis werden wir Ihr Wissen über die Workflowkonfiguration festigen und Ihnen Tipps für den effektiven Einsatz in Ihrem Unternehmen mitgeben.

Unsere täglichen Aufgaben haben meist einen festen Ablauf, der mit einem Workflow abgebildet werden kann. Zum Beispiel werden in einer Bibliothek Bücher ausgeliehen und wieder zurückgebracht, bis die Bücher am Ende ihrer Nutzungsdauer angelangt sind und aussortiert werden müssen. In einem Softwareprojekt werden die Bugs in Form von Issues erfasst, geprüft, behoben, verifiziert und geschlossen. Eine Frage, die wir uns dabei stellen müssen ist, welche Informationen wir aus unserem Workflow gewinnen möchten. Es gibt 4 Hauptfragen, die Workflows beantworten:

• Status: Wo?
• Bearbeiter: Wer?
• Lösung: Warum?
• Transitionen: Wie?

Neue Workflowstatus kreieren

Jeder Status eines Workflows repräsentiert eine Phase im Lebenszyklus, das ein Issue durchläuft. Mit Jira-Software erstellt man ein sogenanntes Board, das die Lebenszyklen aller Issues abbildet. Ein aktives Board sieht zum Beispiel so aus:

Jede Phase eines Lebenszyklus wird abgebildet und die Issues des Boards werden entsprechend einsortiert. Teams, die ihren Arbeitsfluss verbessern möchten, können die Anzahl der Issues in Status wie "Code Review" limitieren, um lange Warteschlangen mit zu prüfenden Issues nicht ausarten zu lassen. Einer der vielen Vorteile von agilen Boards ist der Workflow. Es können mehrere, unterschiedliche Status in einer Spalte bzw. Phase enthalten sein, wenn die Zielgruppe des Boards externe Stakeholder sind. Für diese Zielgruppe sind die Issues nämlich in Bearbeitung, auch wenn die Status tatsächlich "in progress" und "code review" sind.

Wenn Sie einen Gesamtüberblick über die Arbeitspakete eines Releases sehen möchten, ist das zweidimensionale Filterstatistik-Gadget eine gute Möglichkeit dies zu tun. Definieren Sie den Status auf der X-Achse, die Version auf der Y-Achse und wählen Sie "Total" aus. Als Resultat erhalten Sie eine übersichtliche Matrix Ihres Projektes. Beim Klick auf eine Nummer gelangen Sie zum entsprechenden Issue.

Konfiguration

Das zweidimensionale Filterstatistik-Gadget in Aktion

Das Bearbeiter-Feld konfigurieren und nutzen

Das Ziel von Workflows ist es Teams dabei zu unterstützen effizienter zusammen zu arbeiten.

Nebenbei erwähnt ist es ratsam Profilbilder in Jira zu hinterlegen, falls Sie das noch nicht getan haben. Enorm wichtig ist es auch den geleisteten Beitrag eines Teams öffentlich zu präsentieren. Um nun aber nicht alle Punkte des Artikels aufzuzählen verlinke ich ihn hier, er ist auf jeden Fall lesenswert.

Das zweidimensionale Filterstatistik-Gadget kann auch so konfiguriert werden, dass die Arbeitsteilung eines Teams sichtbar wird und man die Bearbeiter einzelner Issues sieht. Es ist hilfreich die Bearbeiter und die Prioritäten von Issues auf einen Blick sehen zu können, weil dadurch sichergestellt werden kann, dass kein Teammitglied zu viele kritische Issues zugewiesen bekommt und überlastet wird.

Wann ist ein Issue resolved?

Jeder Workflow hat einen Wendepunkt bzw. einen Höhepunkt. Im Beispiel mit der Bibliothek befindet sich das Buch im Status "done" wenn es aussortiert wurde und somit der Lebenszyklus beendet ist. Beim Softwareentwicklungs-Workflow beginnt ein Issue die Verifizierungsphase, wenn ein Entwickler eine Änderung vornimmt und das Issue auf gelöst setzt. Aber nur weil ein Issue auf gelöst gesetzt wurde, bedeutet das nicht, dass das Issue geschlossen ist. Ein gelöstes Issue unterscheidet sich von einem geschlossenen Issue. In unserem Beispiel bedeutet das, dass ein Buch aussortiert wurde, weil es stark abgenutzt ist. Dafür könnte man eine Transition mit dem Titel "Bestellung unterwegs" hinzufügen, die dann bedeutet, dass wir auf das Ersatzbuch warten.

Durch die blau hervorgehobenen Transitionen  ändert sich der Status von "gelöst" zu "Bestellung unterwegs". Sobald das neue Buch angekommt, eröffnet die Bibliothek ein neues Issue für dieses Buch. In Software-Teams sollte der Workflowstatus für gelöste Issues in "fixed" umbenannt werden. Das Issue wandert dann in die Verifizierungsphase über um von einer anderen Person geprüft zu werden. Das Issue ist dabei immer noch offen, aber es wurde "gefixed". Sobald das Issue von einer anderen Person verifiziert wurde, wird es geschlossen.

Mit dem zweidimensionalen Filterstatistik-Gadget können wir alle gelösten Issues nachverfolgen. Oft sehen Entwickler ihre Arbeit als erledigt, wenn sie Issues auf gelöst setzen. Mit dieser Statistik können genau diese gelösten, aber noch nicht geschlossenen Issues angezeigt werden um schließlich geprüft und geschlossen zu werden.

Transitionen erstellen und nachverfolgen

Wie im letzten Absatz bereits angedeutet, sind die Transitionen entscheidend. Wenn Sie verstehen möchten wie die Arbeitsprozesse in Ihrem Unternehmen sind, sehen Sie sich Ihre Issues mithilfe von JQL, der Jira-Software Query Language, an. Mit JQL können Sie die Arbeitsabläufe Ihres Unternehmens genauer unter die Lupe nehmen. Fixes, die nicht über den Verifizierungsstatus hinaus gehen konnten, sind die Kennzahlen für Softwareteams. Wenn wir die nicht verifizierten Issues des letzten Monats sehen möchten, geben wir den folgenden Code ein: