Die Top 5 der gefragtesten JIRA-Workflow-Erweiterungen

10 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.

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

  • Bernd Korthaus

    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.

  • Ingo Elias

    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

  • Constance

    14. Februar 2017 von Constance

    Hallo Jörg, das Tool wäre extrem nützlich. Wann kommt es auch für die Cloud-Variante? Viele Grüße

    • Jörg Spiegelhoff

      Hallo Constance, gerne würden wir das Plugin auch in der Cloud bereitstellen. Die Entwicklung einiger Funktionen sind in der Cloud recht schwierig bis gar nicht nicht umsetzbar. Es gibt deshalb noch keinen konkreten Plan für die Cloud. Welche Funktionen sind für dich nützlich? Vielleicht haben wir dafür eine Lösung.
      Viele Grüße
      Jörg

  • Constance

    15. Februar 2017 von Constance

    Hallo Jörg, danke für deine Antwort. Mein Use Case ist Case 1 für Standardfelder im Allgemeinen bzw. das Description Feld im Speziellen. Momentan behelfe ich mir mit einem Messagingfeld über dem Descriptionfeld, so dass sich alle die Infos in die Description reinkopieren müssen. Schöner wäre natürlich, wenn alle direkt in die Vorlage reinschreiben könnten.

    Viele Grüße

  • Thomas

    21. März 2017 von Thomas

    Hallo Jörg,

    vielen Dank für diesen hilfreichen Beitrag. Ich habe aber mal noch eine ganz spezifische Anfrage:
    Wie kann ich einstellen, dass bei einem bestimmten Stausübergang eine Mail an einen bestimmten Nutzer geschickt wird? Diese Einstellung würde ich ganz gerne auch nicht in jedem Workflow separat eintragen müssen, sondern einfach an einer „zentralen“ Stelle pflegen können.
    Gibt es hier eine einfache Lösung?

    Gruß
    Thomas

    • Jörg Spiegelhoff

      Hallo Thomas,

      mit Workflow Essentials können leider keine Mails auf Basis eines Statusübergangs versendet werden.
      Für den Mailversand bieten aber eine Reihe anderer Plugins vielfältige Möglichkeiten. Wir können uns gerne dazu austauschen. Dann könnten wir auch besprechen, was genau du mit „zentraler Stelle“ meinst. Evt. zentral pro Projekt? Da gibt es im Standard z.B. den Project Lead.
      Schreibe mir gerne eine Mail. Dann diskutieren wir Lösungsmöglichkeiten für dein Anliegen.
      Gruß
      Jörg

Kommentieren

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