Dies ist ein Gast Blog von Sebastian Höhne. Sebastian ist selbstständiger IT-Berater und Trainer aus Dresden. Er verfügt über mehrjährige Erfahrung in der Beratung von Atlassian Jira und Atlassian Confluence. Seine weiteren Expertisen sind Enterprise 2.0, Social & Online Reputation Management.

 

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:

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:

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:

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!

 

About Sven Peters

I'm a software geek working as an Evangelist for Atlassian. I started with software development in 1998 and have been programming for longer that I'd like to admit. Besides coding my passion is effective software development, keeping developers motivated, and helping them kick-ass. Follow me on twitter @svenpet

View all posts by Sven Peters »