Die Top 5 der gefragtesten JIRA-Workflow-Erweiterungen

4 Kommentare

JIRA hat sich zum Softwaresteuerungstool Nr. 1 für agile Teams entwickelt. Insbesondere die flexible Workflow-Engine hat dazu beigetragen. Doch immer häufiger werden insbesondere in Business-Workflows Erweiterungen der Workflow-Funktionalität benötigt. Diese Erweiterungen können durch Plugins (auch Add-Ons genannt) bereitgestellt werden. In diesem Blog-Beitrag stelle ich die Top 5 der meist gefragtesten Funktionalitäten und deren Lösungsmöglichkeiten vor.

Als Atlassian Partner / Expert trifft die codecentric in vielen Kundenprojekten immer wieder auf Anforderungen, die sich mit den Standardfunktionen von JIRA nicht abbilden lassen. Die Atlassian-Tools bieten allerdings mit ihrem Plugin-Konzept eine sehr gute Möglichkeit die gewünschten Anforderungen mit Add-Ons umzusetzen. Es hat sich daraus eine Plattform (Atlassian-Marketplace) mit über 2.000 Add-Ons entwickelt, auf der diese Plugins kostenlos oder kommerziell bereitgestellt werden können.

Mit unserem Plugin-Team hat die codecentric bereits eine Vielzahl individueller Plugins für Kunden entwickelt. Aus der Rubrik Workflow-Erweiterungen haben wir die wichtigsten Funktionen zu einem Plugin gebündelt, „Workflow-Essentials for JIRA“ genannt und im Atlassian Marketplace zur Verfügung gestellt.
Das Plugin wird kontinuierlich mit weiteren interessanten Funktionen angereichert und unterstützt natürlich auch die Weiterentwicklungen / neuen Versionen von JIRA selbst.
Die Top 5 Use Cases und deren Lösungsmöglichkeiten mit diesem Plugin sind hier beschrieben:

Use Case 1 – Default Values for Create Screen

Das Erzeugen eines neuen Vorgangs in JIRA wird über den sogenannten „Create Screen“ umgesetzt. Auf dieser Bildschirmmaske lassen sich Systemfelder (von JIRA out of the box bereitgestellte Felder) und beliebige „Benutzerdefinierte Felder“ konfigurieren. JIRA bietet für benutzerdefinierte Felder die Möglichkeit Standard-Werte festzulegen – entweder global für alle JIRA-Projekte oder im Kontext eines jeden Projekts individuell. Für Systemfelder gibt es keine Möglichkeit Standard-Werte zu definieren.
Derartige Templates werden aber immer wieder von vielen JIRA-Nutzern gewünscht, um entweder den Benutzern zu verdeutlichen welche Informationen man in einem Feld erwartet oder um die Benutzerfreundlichkeit bei der Erstellung neuer Vorgänge zu verbessern.
Mit Workflow-Essentials for JIRA haben wir eine einfach zu bedienende Konfigurationsmaske bereitgestellt, um Systemfelder und benutzerdefinierte Felder pro JIRA-Projekt und pro Vorgangs-Typ mit Standard-Werten belegen zu können.

Default value for create screen Screenshot

Der Screenshot zeigt ein Beispiel, bei dem ein neuer Vorgang vom Typ Bug für das Projekt „Use Case Demo“ die oben gezeigten Inhalte in den Systemfeldern „Summary“ und „Description“ vorbelegt.

Wer sich jetzt fragen sollte warum Atlassian diese Funktionalität nicht selber in JIRA zur Verfügung stellt, kann das in dem Portal von Atlassian hier nachlesen.

Atlassian Suggestion Portal

In dem Portal-Ticket JRA-4812 ist auch erkennbar, dass diese Erweiterung bereits seit 2004 gewünscht wird und inzwischen > 1.000 Votes erhalten hat.

Use Case 2 – Mandatory fields

Bei der Konfiguration von Pflichtfeldern ist immer die Abwägung zwischen Notwendigkeit einer Information und der Usability gefordert.
In JIRA können Systemfelder und benutzerdefinierte Felder individuell für JIRA-Projekte über sogenannte Feld-Konfigurationen als „Erforderlich“ konfiguriert werden. Diese Felder bekommen dann auf dem „Create Screen“ einen roten Asterisk (Stern), so dass erkennbar ist, das dieses Feld zwingend auszufüllen ist, um den Vorgang zu erstellen.
In vielen Fällen liegen dem Benutzer bei der Erstellung des Tickets noch nicht alle Informationen vor, so dass der Vorgang nicht angelegt werden kann oder (wie es auch häufig passiert) mit falschen Daten befüllt wird, damit dem Zwang der Eingabe genüge getan wird.
Von den Benutzern wird deshalb gewünscht, bestimmte Felder erst zu einem späteren Zeitpunkt im Workflow als obligatorisch festzulegen.
In JIRA lässt sich das über Validatoren (Bestätigungen) in den Workflow-Übergängen konfigurieren. Dabei werden die Übergänge von einem Status zum nächsten nur bei positivem Ergebnis des konfigurierten Validator ermöglicht.
Um den Benutzern das Pflichtfeld anzuzeigen und eventuelle Fehlermeldungen bei falscher oder fehlender Information anzeigen zu können, sollte zusätzlich eine Bildschirmmaske für den Workflow-Übergang konfiguriert werden.

Pflichtfelder in JIRA

Das Feld „Fix Version“ wurde als Pflichtfeld im Übergang zum Status „Review“ konfiguriert und gleichzeitig durch einen roten Asterisk kenntlich gemacht.

Im Marketplace werden verschiedene Plugins angeboten, um Felder in Workflow-Übergängen validieren zu können.
Jedoch fehlt in diesen Plugins die Möglichkeit dem Benutzer durch den roten Asterisk erkennbar zu machen, dass es sich um ein Pflichtfeld handelt. Das führt dazu, dass der Nutzer immer erst durch eine Fehlermeldung darauf aufmerksam gemacht wird, dass es sich um ein Pflichtfeld handelt. Von so manchem Kunden haben wir als Feedback bekommen, dass dieses Verhalten ein Showstopper bzw. ein klarer Bug ist.

Auch bei dieser Anforderung ist keine kurzfristige Umsetzung durch Atlassian zu erwarten. Der Featurewunsch existiert seit 2005 und hat inzwischen >750 Votes.

Im Plugin “Workflow Essentials” haben wir diese Anforderung inklusive dem gewünschten Asterisk umgesetzt. Zudem lassen sich individuelle Hinweise / Fehlermeldungen konfigurieren, so dass der Benutzer bei fehlender Eingabe eine angepasste Meldung bekommt.

Use Case 3 – Add Watcher

Benachrichtigungen in JIRA lassen sich in erster Linie über Benachrichtigungs-Schema für jedes JIRA-Projekt individuell steuern. In dem Schema können für verschiedenste Ereignisse (Vorgangserzeugung, Vorgangsaktualisierung, beim Zuweisen, Löschen etc.) Benachrichtigungen ausgelöst werden. Diese Benachrichtigungen können pro Ereignis für Rollen, Gruppen, dem aktuellen Bearbeiter, einzelnen JIRA-Benutzern oder auch an den Watchern / Beobachtern konfiguriert werden.
Durch dieses Benachrichtigungskonzept erhält man als JIRA-Administrator bereits sehr viel Flexibilität. Dennoch gehen häufig die Anforderungen über die bestehende Funktionalität hinaus. Es existiert z.B. keine Möglichkeit die Benachrichtigungen pro Vorgangstyp im Projekt unterschiedlich zu handhaben. So werden z.B. bei der Vorgangserstellung unabhängig von einem Bug, einer Story oder einem Epic immer an alle hinterlegten Benutzer Benachrichtigungen erzeugt.

Durch die Einführung der Watchlist (Beobachterliste) wurde eine weitere Individualisierung für die Benachrichtigung pro Vorgang möglich.
Als Benutzer kann ich mich selber der Beobachterliste hinzufügen oder mit der Berechtigung „Manage Watcher list“ andere Benutzer zu einem Beobachter machen.
Ein mit mehr als 600 Votes gefordertes Feature ist die Möglichkeit Watcher während der Erstellung neuer Vorgänge automatisch hinzufügen zu können. Genauer gesagt, soll es im „Create Screen“ möglich sein per default Benutzer (z.B. ein Team) als Watcher hinzuzufügen, sobald ein Projekt-Vorgang erstellt wird.
Mit dem Plugin „Workflow Essentials“ können Benutzer die in einem Multi-User-Picker-Field ausgewählt wurden über eine PostFunction der Beobachtungsliste hinzugefügt werden.

Add Watcher

Konfiguration zur Festlegung von Beobachtern eines Vorgangs über ein Multi-User-Picker-Feld

Damit die User im „Create Screen“ erscheinen, legt man wie in Use Case 1 beschrieben die Default Benutzer in einem benutzerdefinierten Multi-User-Picker-Field fest. Die Post-Function „Add Watcher“ wird dann in der „Create Transition“ konfiguriert und so lässt sich die gewünschte Funktionalität abbilden.

Use Case 4 – Update / Set Value

JIRA bietet im Standard die Möglichkeit Werte von Systemfeldern über die vorhandene Post-Function „Update Value“ zu verändern. So lässt sich z.B. die Lösung / Resolution eines Vorgangs durch einen Workflowübergang auf einen festgelegten Wert setzen.
Allerdings bietet JIRA diese Möglichkeit für benutzerdefinierte Felder nicht an. Auch hier existiert ein Featurewunsch seit 2005 der bisher nicht umgesetzt worden ist.
Ein Beispiel für einen Anwendungsfall lautet: „Das Feld „Verantwortlicher Mitarbeiter“ soll im Status „Ready for Approval“ 
mit „Max Müller“ gefüllt werden.“

Feldwerte in JIRA über Post-Functions ändern

Das Workflow Essentials Plugin unterstützt viele unterschiedlich benutzerdefinierte Feldtypen, mit dem also Datumsfelder, Textfelder oder numerische Felder über Postfunctions mit Werten belegt werden können.

Use Case 5 – Validate Parent Issue Type for Subtasks

Mit dem Issue Type wird in JIRA zwischen unterschiedlichen Vorgängen differenziert, um darüber im gleichen Projekt z.B. einen Fehler oder einer Anforderung unterscheiden zu können.
Diese Vorgangstypen können sich durch Felder auf den Bildschirmmasken oder auch den Arbeitsabläufen unterscheiden. Auf JIRA Projektebene kann also festgelegt werden welche Vorgangstypen für ein Projekt angelegt werden dürfen.
Eine Hierarchie Ebene tiefer – also bei den Unteraufgaben – gibt es keine Möglichkeit den Vorgangstyp der Unteraufgabe pro übergeordneten Vorgang festzulegen.
In verschiedensten Business Use Cases wird allerdings genau das zu einer Notwendigkeit.

Ein Beispiel: Dem Vorgang BANF (Bestellanforderung) dürfen nur zwei Unteraufgaben vom Typ Material oder Dienstleistung zugeordnet werden. Alle anderen Unteraufgaben in diesem Projekt sind nicht erlaubt.

Mit dem Workflow Essentials Plugin wird der benötigte Validator mitgeliefert. Legt man den Validator „Parent issue type validator“ in der „Create Transition“ der Unteraufgabe an, kann damit genau diese Überprüfung gewährleistet werden.

Validate Parent Issue Type

Mit der Auswahl des Parent Issue Type kann im Sub-Task Workflow die zugehörige Unteraufgabe festgelegt werden

Wir haben auch dieses gewünschte Feature im Atlassian Suggestion-Portal gefunden. Es wurde in 2005 erstellt und hat inzwischen nahezu 400 Votes. In dem Ticket ist nachzulesen, dass es auch hier keine Pläne gibt diesen Featurewunsch in absehbarer Zeit umzusetzen.

Fazit

Mit JIRA lassen sich sehr viele Use Cases out of the box umsetzen. Allerdings fehlen insbesondere in Business Workflows an der ein oder anderen Stelle kleine Erweiterungen, um Kundenanforderungen vollständig umsetzen zu können.
Mit dem Workflow Essentials Plugin haben wir immer „ein Ohr auf der Strasse“ und ermöglichen die fehlenden Features konfigurativ – also ohne diese eigenständig implementieren zu müssen – nutzen zu können.
Wir würden uns freuen, wenn ihr das Plugin ausprobiert (30 Tage kostenlos) und uns Feedback geben würdet. Es interessiert uns auch welche Workflow Features von euch benutzt werden und welche Features euch fehlen. Vielleicht haben wir eure fehlenden Features bereits auf unserer Roadmap. Kommentiert doch gerne Eure Ideen und Erweiterungswünsche oder schreibt mir eine Mail.

Jörg Spiegelhoff

Jörg Spiegelhoff ist seit 2010 bei der codecentric am Standort Solingen. In seiner 20-jährigen IT-Laufbahn hat er in den Rollen Produkt-/Projektmanager, Agile Coach und IT-Leiter in verschiedenen Branchen und mit unterschiedlichen Technologien Erfahrungen sammeln können. Aktueller Schwerpunkt seiner Arbeit ist es, die Partnerschaft mit Atlassian auszubauen und Unternehmen beim Einsatz des Produktportfolios zu unterstützen.

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Kommentare

  • 16. Oktober 2016 von Bernd Korthaus

    Hallo Jörg,

    sehr verständlich geschrieben und alles sehr nützlich.
    Ich schätze JIRA sehr. Es ist mir aber ein absolutes Rätsel, warum gerade Atlassian solche elementaren und häufig gewünschten Features jahrelang nicht umsetzt. Zumal sie spätestens nach ihrem Börsengang alle Mittel dazu hätten.
    Da fällt mir unwillkürlich der Vergleich ein mit dem Schuster, der barfuß geht.
    Oder hat der Product Manager zu sehr „Never change a running system“ verinnerlicht? 🙂

    • Jörg Spiegelhoff

      Hallo Bernd,

      danke für dein Feedback.
      Ja, aus Benutzer Sicht ist es schwer nachvollziehbar warum diese Features über so langem Zeitpunkt nicht von Atlassian umgesetzt wurden. Häufig bezieht sich Atlassian mit einer Antwort im Ticket auf bereits vorhandenen Plugins.
      Eine etwas detailliertere Erklärung findest du hier.

  • 1. November 2016 von Ingo Elias

    Hallo Jörg,
    gibt es überhaupt eine Möglichkeit die angebotene drop box unter „Issue Type“ zu erweitern? Falls man in einem Ticket ist und dort per „More“ -> „Create Sub Task“ ein untergeordnetes Ticket erstellen will, ist in der dortigen drop box zum „Issue Type“ nur „Sub-Task“ auswählbar (hängt warscheinlich von Projektkonfiguration ab). Falls ihr mit eurem Plugin einen ParentValidator geschrieben habt, müsstet ihr doch auch in der Lage sein, verschiedene andere Typen von Issues dort eintragen zu können, damit ihr auch was zu validieren habt.
    Ich finde nirgends eine Möglichkeit, diese drop box zu erweitern. Ich hätte gern, dass unter einem „Epic“ nur eine „Story“ angelegt werden kann und nichts weiter. Kannst du mir helfen? Wo kann dies konfiguriert werden? Viele Grüße, Ingo

    • Jörg Spiegelhoff

      Hallo Ingo,

      Ja, du kannst in deinem Projekt über das Issue-Type Scheme steuern, welche Subtask-Typen in deinem Projekt auswählbar sind. Vermutlich gibt es in deinem Projekt nur einen Issue Type „Sub-Task“.
      Falls es in einer Konfiguration mehrere gibt, kannst du für jeden Subtask einen eigenen Workflow erstellen und in der jeweiligen „Create Transition“ unseren „Parent Issue Type Validator“ einbinden und damit festlegen welcher Parent erlaubt ist.

      Epics und Stories sind technisch nicht gleich zu setzen mit Issue und Sub-Issue. Epics und Stories besitzen lediglich einen spezifischen Linktype und sind auf der gleichen Hierarchie-Ebene. Du könntest allerdings das Epic-Link field als mandatory für Stories setzen. Das sollte deine Anforderung erfüllen. Zu beachten ist allerdings der Umgang mit geschlossenen Epics.
      Gerne können wir uns dazu im Detail austauschen. Bei Bedarf schicke mir doch eine Mail.
      Viele Grüße

      Jörg

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.