Standards in Jira und Confluence – Umsetzungsmöglichkeiten, Nutzung von Templates , Automatisierung

Von Jürgen Dinsing, Benjamin Weinheimer & Guido Wischrop

Standards – die Idee

Nach Einführung der Atlassian-Tools in Firmen oder anderen Organisationseinheiten wächst in der Regel der Wunsch, die Tools auch in eigenen bzw. weiteren Projekten bzw. Arbeitsumfeldern einzusetzen. Die Folge ist dann, dass in den Tools nicht nur neue Nutzer zugelassen werden müssen, sondern in der Regel ein neues Jira-Projekt und/oder Confluence-Bereich angelegt werden muss. Häufig entsteht dann auch der Wunsch nach eigenen Workflows mit eigenen Status, spezifischen Attributen (also Custom-Fields) und anderen Sonderkonfigurationen.

Dies führt nicht nur jeweils zu hohem Aufwand bei der Einrichtung, sondern auch über längere Zeit betrachtet zu unübersichtlicher Konfiguration und dadurch dann zu weiterer Aufwandssteigerung. Zusätzlich besteht aber auch die Gefahr, dass die Stabilität und vor allem die Performanz der Systeme gefährdet wird.

Auch aus prozessualer Sicht spricht einiges dafür, dass in den Projekten ein gleiches oder zumindest ähnliches Vorgehen angewendet wird. Die immer wieder geführte Diskussion über firmeneinheitliche Vorgehensmodelle in der Softwareentwicklung bzw. in der Projektkultur ist ein sicheres Indiz dafür. Diese Argumentation soll daher hier nicht im Detail aufgeführt werden. Nur so weit: Es liegt vermutlich klar auf der Hand, dass Standards den Wechsel von Mitarbeitern zu anderen Projekten vereinfacht, dass die Steuerung der Projekte insgesamt über alle Projekte hinweg einfacher wird usw. Vor allem aber kann so die Qualität in Projekten gesteigert werden, da bei Einhalten des Standards alle wichtigen Prozessschritte und Projektergebnisse sicher beachtet bzw. bearbeitet werden.

Quintessenz ist: Standards einzuführen ist hilfreich und sinnvoll. Es hilft sicher bei der Vereinheitlichung, verringert aber per se nicht den Aufwand bei der Einrichtung von Jira-Projekten und Confluence-Bereichen. Denn die neuen Jira-Projekte und Confluence-Bereiche müssen ja weiterhin angelegt werden. Der Aufwand wird also nur ein wenig eingeschränkt, da die Neukonfiguration von Workflows, Custom-Fields etc. entfällt.

Daher sollen hier zwei Aspekte beleuchtet werden:

  • die Einführung der Standards – aus Sicht des Betriebs und der Konfiguration von Jira und Confluence
  • Möglichkeiten der Automatisierung der Anlage von Standard-Jira-Projekten und Confluence-Bereichen

Einführung der Standards

Auch ohne Automatisierung kann durch die Verwendung von Standards bei der Neuanlage von Projekten und Bereichen vor allem bzgl. Aufwand und Geschwindigkeit einiges gewonnen werden. Die Abstimmung mit den für das neue Projekt zuständigen Kollegen/Kolleginnen kann einfacher erfolgen, es muss keine Analyse der Anforderungen mit erneuter Definition der zu konfigurierenden Artefakte erfolgen. Auch das Wissen über die Jira-/Confluence-Administration kann einfacher geteilt werden.

Dennoch bleibt aber der Aufwand für die Einrichtung der neuen Artefakte erhalten. Aufgrund der wiederholten Durchführung mag es schneller gehen, aber es bleibt eben ein Aufwand erhalten.

Wie aber führt man solche Standards ein? Man wird hier vermutlich auf die gleichen Herausforderungen treffen, die auch bei der Einführung von Standardvorgehensmodellen auftreten, auch wenn es nicht um toolbasiertes Vorgehen geht.

Es geht also darum, die Anforderungen einzusammeln, diese abzustimmen und daraus dann einen gemeinsamen Standard abzuleiten. Dabei ist es sicher sinnvoll, wenn die Anwender und Verantwortlichen für den Prozess den Standard gemeinsam definieren und mittragen. Auch die Weiterentwicklung eines Standards sollte zwischen allen Verantwortlichen diskutiert werden. Auch kann es schon zu Beginn förderlich sein, zumindest teilweise die technischen Möglichkeiten von Atlassian-Spezialisten miteinzubringen.

Standards sollten nicht in Stein gemeißelt sein, sondern müssen leben und sich weiterentwickeln können. Bei neuen Anforderungen, neuen Funktionen im System, z. B. auch neuen Plugins, bei neuen Projektarten im Unternehmen, die standardisiert werden sollen, etc. ist es notwendig, diese Vorgaben anzupassen.

Aber was ist ein Standard? Völlig identisch konfigurierte Projekte und Bereiche? Je nach Projekttyp angepasste Konfiguration? Welche Projekttypen gibt es im Unternehmen? Welche davon sind so unterschiedlich, dass in den Tools darauf Rücksicht genommen werden muss? Wie weit dürfen einzelne Projekte von den Standards abweichen?

Auch wenn das alles entschieden ist, muss es sicher erneut abgestimmt werden, spätestens, wenn die dafür vorgesehene Konfigurationen vorliegt und man den Standard im Tool “anfassen” kann. Hier sind solche Projekte nicht anders als andere Projekte bzgl. Einführung oder Entwicklung von Systemen.

Nach Abschluss dieser Phasen sind dann sicher auch Schulungen und Ähnliches notwendig. Denn nur so können die Standards zu gelebten Standards werden, die auch verwendet werden. Sonst werden die oben beschriebenen Effekte nicht eintreten.

Exkurs: Keine Einführung von Standards ohne Change Management

Ilona Hannemann, Julia Zydorek; mgm consulting partners gmbh

Unsere Erfahrungen zeigen, dass Veränderungen – egal, ob neue Organisationsstrukturen, neue Vorgehensweisen oder neue IT-Systeme – bei den Betroffenen oft auf Widerstände stoßen: „Keine Zeit und Lust, mich mit neuen Abläufen zu beschäftigen“, „Das alte Vorgehen tat es doch auch“, „Die Anwendung soll einfach nur funktionieren“. Solche und ähnliche Sätze hören wir recht häufig – insbesondere bei Veränderungen mit IT-Bezug.

Als Folge fehlender Akzeptanz kann es passieren, dass Mitarbeiter neue Arbeitsweisen gar nicht oder fehlerhaft umsetzen. Für Unternehmen kann das schnell ins Geld gehen: Investierte Kosten zahlen sich nicht aus, erhoffte Benefits, wie z.B. im Fall von Standards die Qualitätssteigerung, bleiben aus. Stattdessen entstehen ungeplante zusätzliche Kosten, z.B. weil aufgrund von Anwenderfehlern kritische Geschäftsabläufe plötzlich länger dauern oder gar nicht mehr funktionieren. Zusätzlich kann sich in der Belegschaft ein Gefühl von Frust und Hilflosigkeit breitmachen, weil Mitarbeiter mit den neuen Abläufen nicht zurechtkommen.

Um derartigen Risiken entgegenzuwirken, ist auch für die Einführung neuer Standards ein begleitendes Change-Management-Programm sinnvoll. Aus vergleichbaren Change-Projekten haben wir im Folgenden einige Kernelemente zusammengefasst, die unserer Erfahrung nach die Wahrscheinlichkeit erhöhen, dass ein neuer Standard nachhaltig im Alltag genutzt wird und die erhofften Benefits auch tatsächlich eintreten. Wir orientieren uns dabei an fünf typischen Hebeln des Change Managements, wie sie auch in diversen gängigen Change-Management-Modellen vorkommen (z.B. Transtheoretisches Modell, ADKAR, 8-Stufen-Modell von Kotter).

  1. Problembewusstsein schaffen
    Welche Probleme sollen mit der Einführung von Standards gelöst werden? Und was wird nach der Einführung von Standards besser sein als vorher? Nur, wenn diese Fragen hinreichend beantwortet werden können, werden Anwender bereit sein, Unbequemlichkeiten in Kauf zu nehmen, Skepsis zu überdenken oder sich überhaupt mit einer Neuerung zu beschäftigen. Mit Methoden des Storytellings lässt sich eine konsistente, überzeugende Argumentationskette entwickeln. Visuelle Kommunikation wie z.B. Bilder oder Filme helfen dabei, eine möglichst anschauliche Vorstellung vom Arbeiten mit Standards zu vermitteln. Dabei sollte darauf geachtet werden, keine überzogenen Erwartungen zu erzeugen, sondern offen und ehrlich zu kommunizieren und auch mögliche Nachteile des neuen Standards nicht zu verschweigen. Wichtig ist, bei der Nutzenargumentation die Anwender-Brille aufzusetzen und den Nutzen aus ihrer Sicht zu beschreiben, z.B. wie helfen die Standards dem Projektleiter beim Erreichen seiner Projektziele, was wird für Projektmitarbeiter durch die Einführung des Standards einfacher sein etc. Dafür hilft es, für jede Anwendergruppe eine anschauliche Persona, d.h. ein möglichst konkretes Profil eines Prototypen der jeweiligen Benutzergruppe zu beschreiben, um sich umfassend in ihre spezifische Situation und Bedarfe hineinversetzen zu können.
  2. Persönliches Commitment fördern
    „Generell halte ich die Einführung von Standards für sinnvoll. Aber ich habe es noch nicht geschafft, mich damit zu beschäftigen.“ Neben einer positiven Haltung gegenüber einer Neuerung bedarf es auch der Motivation, ein persönliches Invest aufzubringen, z. B. in Form von Zeit und Unbequemlichkeiten. Um diese Motivation zu fördern, sollte die Hemmschwelle für die Nutzung der Standards so niedrig wie möglich gehalten werden. Hier spielt die anwenderorientierte Ausgestaltung des Standards eine entscheidende Rolle: Bereits bei der Entwicklung des Standards sollten die verschiedenen Anwendergruppen systematisch eingebunden werden. In Workshops mit den Anwendern wird gemeinsam das bisherige Projektvorgehen reflektiert: Worauf kommt es in dem jeweiligen Projekttyp an? Wie wurden Projekte bisher in der Praxis bearbeitet? Was am bisherigen Projektvorgehen lief gut, was weniger? Welche Elemente sind für zukünftige Projekte unverzichtbar? Gemeinsam mit den Anwendern wird dann ein für alle Projekttypen passender Standard definiert.
    Neben dem Einbezug der Anwender spielen die Führungskräfte eine zentrale Rolle für die Motivation der Anwender. Führungskräfte sollten deshalb frühzeitig in die Entscheidung für die Entwicklung von Standards eingebunden, gezielt als Sponsoren gewonnen sowie in die Lage versetzt werden, den neuen Standard in ihren Teams zu promoten und ihn selbst anzuwenden. Nur dann können sie ihrer wichtigen Vorbildfunktion in Veränderungsprozessen gerecht werden.
  3. Wissen vermitteln
    Damit eine Neuerung nachhaltig umgesetzt werden kann, benötigen die Anwender das nötige Wissen. Hier hat sich der Einsatz von Key Usern aus den Fachabteilungen als Trainer bewährt. Als interne Experten können Key User ihren Kollegen den neuen Standard am besten im jeweiligen Kontext ihrer Fachabteilung erklären, praxistaugliche Tipps und Tricks vermitteln und die Trainingsinhalte gezielt auf die Bedarfe ihrer Kollegen zuschneiden.
    Ergänzend zu den Trainings werden kurze, knackige Quick Guides oder Erklärvideos zur Verfügung gestellt. Indem diese sich auf die wichtigsten Funktionen beschränken, sind sie besser als die alles umfassende Bedienungsanleitung geeignet, einen niedrigschwelligen Einstieg in den neuen Standard zu bieten.
    Wichtig ist, dass Trainings und Anleitungen am Kenntnisstand der Anwender anknüpfen, die Anwender also idealerweise in die Erstellung der Unterlagen eingebunden sind oder sie zumindest redigieren. Je nach tatsächlichem Kenntnisstand der Anwender kann es nötig sein, nicht nur die Standards an sich, sondern auch die nötigen Confluence-Anwenderkenntnisse zu vermitteln.
  4. Wissen in Handeln übersetzen
    Damit das Trainingswissen anschließend in der Praxis auch richtig und konsequent umgesetzt wird, ist eine enge persönliche Begleitung der Nutzer im Projektalltag wichtig. Hier bietet sich der Aufbau eines Botschafter-Netzwerks an. Je Projekt wird ein Botschafter ernannt, der die konsequente Anwendung der Standards im Projektalltag im Blick behält, bei Bedarf helfend eingreift und den Kollegen im Projektalltag mit Tipps und Tricks beiseitesteht.
    Hilfreich ist außerdem auch hier, die Nutzung des Standards so bequem wie möglich zu gestalten, z.B. die Erstellung der Standardstruktur in Confluence und Jira zu automatisieren.
  5. Nachhaltig verankern
    Damit sich neue Standards langfristig im Projektalltag etablieren können, müssen sie stetig an die sich ändernden Anforderungen der Nutzer angepasst werden. Hierfür empfiehlt es sich, regelmäßige Retrospektiven mit Botschaftern, Key Usern und Projektleitern durchzuführen, und den Standard auf Basis ihres Feedbacks kontinuierlich weiterzuentwickeln.

 

Standards in Jira und in Confluence

Bevor nun in Jira und Confluence Standards eingeführt werden können, muss definiert werden, inwieweit die ja meist aus organisatorischen Vorgaben bestehenden Standards in den Systemen umgesetzt werden.

Ein Standard kann in den Systemen ja unterschiedliche Ausprägungen haben, d.h. er kann in unterschiedlicher Abstufung umgesetzt werden, mit nur einzelnen Elementen, mehreren Elementen bis hin zu allen Elementen, die in Jira und Confluence konfiguriert werden können. Auch der Zusammenhang zwischen einzelnen Elementen kann Teil des Standards sein. Wie das genau erfolgen soll, hängt auch stark vom Detaillierungsgrad der organisatorischen Beschreibung ab. Sind nur Abläufe und andere rein organisatorische Dinge (Meetings, Rollen etc.) geregelt, gibt es auch Vorgaben zu Tasks und Tickets, inkl. Workflow und Attributen, sind Rollen und Rechte definiert und wie detailliert ist das vorgegeben?

Die dadurch enstehenden vielfältigen Fragestellungen bzgl. der Standardisierung in den Tools sind an folgendenen Beispielen abzulesen:

  • Welche Ticket-Typen soll es geben und wie sehen dazu die jeweiligen Workflows und Attribute aus?
  • Gibt es einen Workflow für beliebige Ticket-Typen oder hat jeder Ticket-Typ seinen spezifischen Workflow?
  • Sollen die Screens spezifisch zu den Ticket-Typen erstellt werden? Oder ist das projektspezifisch als Sammlung von Standardfeldern zusammenzustellen?
  • Gibt es Standardscreens, die man nicht anpassen darf?
  • Werden umfassende Projekttypen als Zusammenfassung von Ticket-Typen, Attributen und Rollen/Rechten standardisiert?
  • Oder werden nur Ticket-Typen bestehend aus Workflow und Attributen standardisiert (Epic, User Story, Aufgabe, Bug etc.) und dann den jeweils neuen Projekten in unterschiedlicher Zusammenstellung zugeordnet?
  • Wird immer ein Gesamtstandard für Jira mit seinem korrespondierenden Standardbereich in Confluence verwendet?

Dieser folgende nicht vollständige Überblick zu den möglichen konfigurablen Funktionen in Jira und Confluence, die in einem Standard berücksichtigt werden könnten, zeigt auf, wie komplex die Definition dessen, was in den Tools umgesetzt werden soll, ist:

Jira

  • Issue-Types + Issue-Type Schemes
  • Workflows + Workflow Schemes
  • Fields
  • Field Configurations
  • Screen + Screen Schemes + Issue-Type Screen Schemes
  • Agile Boards
  • Dashboards
  • Rollen + Berechtigungen
  • Benachrichtigungen
  • Projekt-Kategorien

Confluence

  • Space-Startseite
  • Seitenstruktur
  • Templates/Blueprints
  • Space-Kategorien

Bei der Umsetzung in den Tools gibt es weitere Aspekte, die betrachtet werden müssen. Ein Beispiel dafür ist:

Wenn ein Standard einen sehr engen Fokus auf den Prozess und seine Nachverfolgbarkeit und Auswertbarkeit erfüllen soll, führt dies häufig dazu, dass die Workflows lang werden, um jeden möglichen Schritt zu erfassen. Die technischen Beschränkungen im Workflow sind dann meist sehr genau definiert und umfassen viele Vorgaben. Beispiel: Der Status darf nur von einem bestimmten Benutzer verändert werden, nur wenn in einem bestimmten Feld oder in bestimmten Feldern vorgegebene Werte stehen oder wenn alle Sub-Tasks mindestens einen bestimmten Status haben. Die Teams müssen sich an den definierten Standard anpassen, aber die Vorgaben des Workflows werden nicht verstanden und es wird für alles ein möglicher Workaround gesucht. Dies führt zu unlogischen Tickets, weil z.B. in einem Feld etwas stehen muss, aber für das Ticket eigentlich kein relevanter Wert für dieses Feld existiert. Dann wird in dem Feld halt sinnloser Inhalt eingetragen. Das Team ist somit eher damit beschäftigt, alle Vorgaben für das Ticket in Jira zu erfüllen, als die Aufgabe zu erledigen, für die das Ticket erstellt wurde. Die Wartbarkeit eines solchen sehr detaillierten und komplexen Standards kann schwierig werden, da bei Änderungen unbeabsichtigt verschiedene Zusammenhänge verloren gehen oder invalide Tickets entstehen, die nicht weiter bearbeitet werden können. Zudem kann bei Updates mit Featureänderungen sehr großer Aufwand entstehen, um den Standard wieder gangbar zu bekommen.

Umso detaillierter und komplexer eine Konfiguration ist, umso schwieriger ist sie über viele oder gar alle Projekte hinweg einsetzbar.

Eine Lösung könnte sein, den Standard nur auf der untersten technischen Ebene (Issue-Types, Status, Felder, Rollen) anzusiedeln. Aus den definierten Vorgaben kann sich jedes Projekt eine eigene Konfiguration erzeugen:

  • Eigene Workflows werden aus den zur Verfügung stehenden Status zusammengestellt. Das kann durch den Projekt-Administrator mit erweiterten Projektrechten erfolgen.
  • Eigene Screens werden aus den gesetzten Feldern erstellt. Auch das kann durch den Projekt-Administrator mit erweiterten Projektrechten erfolgen.
  • Eigene Berechtigungsschemats für die gegebenen Rollen müssen allerdings durch den Jira-Administrator erstellt werden.

Technisch hilft solch ein Standard dabei, Jira performant zu halten. Durch die häufige und nicht bekannte Verwendung dieser Standard-konformen Basiselemente wird die Wartbarkeit von Projektkonfigurationen nicht erhöht. Da diese Konfiguration aber durch den Projekt-Administrator erfolgt, ist es aus der Gesamtsicht des Jira-Administrators kein großes Problem.

Natürlich sind das nur Beispiele, es gibt wie immer auch Lösungen zwischen diesen Extrema: Ein Standard wird auf mittlerer technischer Ebene definiert. Er umfasst dann Issue-Types, Screens und Workflows. Aus dieser Definition kann sich jedes Projekt eine eigene Projektkonfiguration erzeugen lassen. Der Aufwand für ein neues Projekt ist überschaubar, da man quasi mit einer Checkliste arbeiten kann. Aber bei Anpassungen an Screens oder Workflows muss immer mit vielen Projekten, die in unterschiedlichen Use Cases denken, diskutiert werden.

Es bleibt also festzuhalten, dass nicht nur die reine organisatorische und prozessuale Definition eines Standards komplex ist, sondern auch die Umsetzung in den Tools Jira und Confluence sehr wohl bedacht werden muss. Darüber hinaus gibt es da auch vielfältige Wechselwirkungen: Werden die Vorgaben sehr detailliert festgelegt, so kann das zu sehr komplexer und in sich abhängiger Konfiguration führen. Andererseits kann eine für die Tools in Hinsicht Wartbarkeit und Performanz/Stabilität optimale Konfiguration zu nicht wünschenswerten Effekten bei der Definition der Standards führen, die die damit eigentlich verbundenen Ziele schwer erreichbar machen.

Automatisierte Einrichtung von Projekten in Jira und Bereichen in Confluence

Um Effizienz zu gewinnen, gehört neben der Definition und der Einführung von Standards die Automatisierung der Anlage von Projekten in Jira und Bereichen in Confluence zu den unumgänglichen Maßnahmen. Das lässt sich zum einen mit Skripten, die man dafür entwickelt, umsetzen. Mittels des Plugin ScriptRunner lassen sich recht einfach Groovy-Skripte für Jira und Confluence erstellen. So lassen sich viele Aufgaben automatisieren. Dafür können auch Dialoge etc. realisiert werden.

Zum anderen kann man auch die als Standard mitgelieferte Funktion “Copy Project” von ScriptRunner nutzen. Dann muss kein Script entwickelt werden. Diese Funktion wird manuell ausgeführt.

Ob man nun eine individuelle Entwicklung durchführt oder den Standard verwendet, hängt von den Anforderungen ab. In einem individuell entwickelten Skript lassen sich natürlich deutlich detailliertere und andersartige Anforderungen umsetzen.

Eine individuelle Lösung für die automatisierte Anlage von Projekten in Jira und Bereichen in Confluence könnte dann folgendermaßen aufgebaut sein:

Es werden Templates für Projekte und Bereiche angelegt. Das sind quasi leere Projekte/Bereiche ohne Inhalt, die aber mit der passenden Konfiguration, also den definierten Workflows, Attributen etc., versehen sind. Ein Skript kopiert diese Vorlagen und legt damit das eigentliche Projekt bzw. den entsprechenden Confluence-Bereich an. In dem Skript werden dann über Dialoge oder Ähnliches die notwendigen individuellen Angaben abgefragt und für den Kopiervorgang verwendet. Auch die notwendigen Berechtigungen können automatisiert vergeben werden. So könnte über ein Namensschema für Gruppen (Schema = Projektschlüssel + Gruppenname) verschiedene Berechtigungsgruppen inkl. der gewollten Berechtigungen angelegt und den neuen Projekten zugeordnet werden, z.B. eine Gruppe für Entwickler, eine für QS-Bearbeiter etc., die dann nach Zuordnung zum jeweiligen Projekt nur noch mit den Teammitgliedern gefüllt werden müssen. Der Einfachheit halber könnte die Anlage und die Verwaltung der Gruppen in Jira bzw. Crowd erfolgen, da der Zugriff auf AD/LDAP die Komplexität des Skripts um einiges erhöht. Das Skript kann bei der Ausführung in Jira bei Bedarf auch einen zugehörigen Bereich in Confluence anlegen oder umgekehrt aus Confluence heraus ein entsprechendes Projekt in Jira erstellen. Man benötigt also nur ein Skript.

Solch ein Skript ist aber auch als Post-Funktion in einem Ticket-Workflow denkbar. Das Szenario könnte dann so aussehen: Neue Projekte und Bereiche werden über Jira-Tickets beantragt. Dort trägt man die notwendigen Angaben ein: welche Art von Projekt, soll es einen zugehörigen Confluence-Bereich geben, soll nur ein Confluence-Bereich angelegt werden, wer ist der Projektleiter, wer der Jira-Projekt-Administrator etc. Aus diesen Daten wird dann nach der Genehmigung durch einen zuständigen und berechtigten Mitarbeiter das neue Projekt und/oder der neue Bereich angelegt. Das heißt, man verbindet die Automatisierung der Anlage mit einer dokumentierten Freigabe.

Weitere Vorteile solcher individuellen Skripte sind: Es werden alle Projekte wirklich detailliert nur den Vorlagen gemäß angelegt, egal wer es durchführt. Es entsteht somit auch gleich eine Dokumentation, einerseits weil es im Skript steht, andererseits weil ein Skript natürlich so etwas auch protokollieren könnte.

Diese Vorteile muss man mit dem entstehenden Aufwand abwägen. Ein wichtiges Kriterium ist da sicher die Häufigkeit, in der neue Projekte und Bereiche angelegt werden müssen.

Automatisierung mit Plugins

Auf der andere Seite gibt es aber auch eine Anzahl von Plugins, die in dem Umfeld unterstützen. Daher ist hier eine Liste von infrage kommenden Plugins aufgeführt. Diese Liste hat keinen Anspruch auf Vollständigkeit. Es gibt sehr viele Plugins. Nicht alle kennen wir. Mit diesen hier haben wir zumindest erste Erfahrungen.

Wichtig ist hier zu beachten, dass nicht alle Plugins eine (vollständige) Automatisierung der Anlage von Projekten in Jira und Bereichen in Confluence unterstützen. Es sind auch Plugins aufgeführt, die nur Teilaspekte abdecken. Daher ist anhand der gewählten Einsatzszenarien genau zu prüfen, welches Plugin bzw. welche Plugins zum Einsatz kommen sollen.

Bzgl. Auswahl von Plugins verweisen wir auf unseren Artikel “Auswahl und Entwicklung von Apps für Jira und Confluence” unter https://live.mgm-tp.com/de/auswahl-und-entwicklung-von-apps-fuer-jira-und-confluence/

Der Name des Plugins in der Tabelle ist auch der passende Link in der Market Place.

Plugin Beschreibung Bemerkung
Configuration Manager for Jira
  • Konfigurationen auf Test-Instanzen vorbereiten und auf Live-Instanzen kopieren
  • Impaktanalysen für Änderungen
  • Fehler in der Konfiguration finden
  • Exportieren und Importieren ganzer Projekte und Anhänge
Das Plugin hat sehr große Ähnlichkeit zum Wettbewerber “Project Configurator for Jira”.

Hier muss man sich beide Plugins im Detail anschauen, um herauszufinden, welches für den gedachten Einsatzzweck besser geeignet ist. Beide Plugins haben die gleichen Basisfunktionen, unterscheiden sich aber im Detail.

Project Configurator for Jira
  • Konfigurationen auf Test-Instanzen vorbereiten und auf Live-Instanzen kopieren
  • Impaktanalysen für Änderungen
  • Fehler in der Konfiguration finden
  • Exportieren und Importieren ganzer Projekte und Anhänge
Das ist der Wettbewerber zu “Configuration Manager for Jira”.
Power Admin
  • Verwendungs und Abhängigkeitsanalyse für Konfigurationen
  • Automatisierung von Aufräumarbeiten (Löschen unnötiger Konfigurationsartefakte etc.)
  • Integritätschecker
  • Finden von ähnlicher Konfiguration, daher bessere Wiederverwendung
Schafft eine gute Übersicht über alle Konfigurationsartefakte und gibt wertvolle Informationen, wo was verwendet wird.

Da hier allerdings die komplette Jira-Administrationsoberfläche umgangen wird, trägt das Plugin nicht dazu bei, dass man als Admin die native Admin-Umgebung kennen lernt. Dies birgt die Gefahr, dass man zum einen nie die Zusammenhänge der einzelnen Artefakte lernt und zum anderen nie mehr ohne dieses Plugin arbeiten kann.

Daher ist der Einsatz diese Plugins genau zu überlegen.

Integrity Check for Jira
  • Integritätsprüfung für Filter, Agile Boards und Dashboards
Verfügt über einzelne Funktion aus dem “Power Admin” (siehe oben).

Recht hilfreich, um Konfigurationsfehler zu finden, allerdings nur für Filter, Agile Boards und Dashboards.

Also nur gut zum “Aufräumen” von Nutzerartefakten, aber nicht für administrative Artefakte.

Admin Toolbox for Jira
  • Kopieren von Workflowkonfigurationen zwischen Workflows
  • Workflowreports:  zeigt welche Pluginfunktionen werden in welchem Workflow verwendet
Sehr gutes Tool, um seine Workflows aufzuräumen.

Hier sieht man, welches Plugin in welchem Workflow verwendet wurde. Dies kann helfen, unnötige Plugins zu entfernen oder Funktionen zu ersetzen.

Eine weitere Funktion ist die Möglichkeit, ganze Transitionen mit allen Validierungen, Beschränkungen und Folgefunktionen zu kopieren. Dies erscheint weniger nützlich in einem Umfeld, in dem man Standards nutzt.

Aber zum Aufräumen einer alten Instanz ist das temporär sicher ein gutes Plugin.

Config Insights for Jira
  • Verbesserung der Übersicht von Konfigurationszusammenhängen, z.B. in welchen Projekten ein Feld, ein Screen, ein Workflow etc. verwendet wird
Ein gutes Tool, um sich eine Übersicht zu verschaffen, welche Artefakte wo verwendet werden.

Es gibt auch die Möglichkeit eines “Bulk Delete” für Artefakte, die nicht verwendet werden. Dies halten wir allerdings für gefährlich, da man so auch “versteckte Felder” aus Versehen löschen kann. Versteckte Felder nutzen wir, um z.B. am Ticket technische Informationen zu hinterlegen, mit denen dann Workflows gesteuert werden können.

Optimizer for Jira (Cleaner for Jira)
  • Analyse der Verwendung und Konfiguration von
    • Projekten
    • Issue-Types
    • Filtern
    • Status
    • Resolutions
    • Agile Boards
  • Übersicht, welche Projekte wie oft und wann zuletzt verwendet wurden
  • Automatische Optimierung der Jira-Konfiguration
Der Optimizer bietet sehr viele Funktionen in einem Plugin, die man sonst in vielen der kleineren Plugins nur einzeln bekommt. Neben einer umfangreichen Analyse der Jira-Konfiguration bietet er auch gleich die passenden Funktionen, um vorhandene Probleme aufzuräumen und zu beheben.

Neben administrativen Artefakten kann man hier auch Nutzerartefakte wie z.B. Dashboards und Agile Boards aufräumen.

Zudem gibt es noch Reports, die einem erlauben, die “Sauberkeit” seiner Jira-Instanz regelmäßig zu überprüfen.

Delegated Project Admin Pro for Jira Delegation von Projektanpassungsmöglichkeiten an den Projekt-Administrator:

  • Issue-Type Schemes
  • Field Configuration Schemes
  • Workflows Schemes
  • Notification Schemes
  • Permission Schemes
Vom gleichen Hersteller gibt es noch weitere Plugins im gleichen Einsatzumfeld:

·       Delegated Group Management in Jira

·       Delegated Project Creator for Jira

·       Delegated Project Creator for Jira Agile

·       und einige mehr

Die Ideen hierbei sind oft, dass man bestimmte Aufgaben des Jira-Admins an Projekt-Admins delegieren kann.

Wir empfehlen dieses Plugins nur für Instanzen, die keinen engen Standard haben und bei denen die Projekt-Admins größtmögliche Freiheit in der Konfiguration ihrer Projekte erhalten sollen.

Auto Project Creator for Jira
  • Durch eine Transition in einem Workflow wird ein entsprechendes Projekt erstellt
Hiermit kann man in einem Workflow eine Definition hinterlegen, die ein neues Projekt erstellt, sobald die Transition durchgeführt wird.

Sprich, man erstellt ein Ticket mit allen nötigen Informationen (Project Name, Key etc.) und wenn das Ticket auf “Done” geht, wird das Projekt erstellt.

Das kann sehr nützlich sein, um z.B. den Erstellprozess zu automatisieren. Also der Kunde erstellt ein Ticket für ein neues Projekt mit entsprechenden Informationen. Der Admin muss nur noch prüfen, ob das so in Ordnung ist, und dann kann die Erstellung angestoßen werden.

Hier kann man allerdings nur auf Atlassian-Projekt-Templates zurückgreifen oder eine geteilte Konfiguration eines bestehenden Projektes nutzen.

Wenn aber der ScriptRunner schon im Einsatz ist, wird dieses Plugin eigentlich nicht mehr benötigt.

Admin Tools for Jira
  • Admin-Tools zur Nutzerverwaltung
  • Erstellen von temporären Nutzern (Nutzer mit Auslaufdatum)
  • Aufräumen von Nutzern, die sich lange nicht mehr eingelogged haben
  • Berechtigungen von einem Nutzer auf einen anderen kopieren
 

Die Funktionalität rund um die Nutzerverwaltung erscheint uns sehr hilfreich zu sein, wenn man die Nutzerverwaltung in Jira durchführt. Bei einem angebundenen AD ist diese App weniger hilfreich.

 

Man kann hiermit Nutzerzulassungen mit einem Verfallsdatum erstellen, was vor allem für externe Nutzer sinnvoll sein kann. Zudem kann man automatisch alle Nutzer deaktivieren, die sich seit einem bestimmten Zeitraum (der zeitraum ist konfigurierbar) nicht mehr angemeldet haben.

 

In einem lokalen Nutzermanagement sind diese Funktionen sehr hilfreich.

Teamworkx Configuration Publisher
  • Exportieren ganze Projektkonfigurationen in Dateien oder nach Confluence zur Dokumentation
  • Diese Dateien können dann archiviert werden oder als Vorlage genutzt werden
Dieses Plugin ermöglicht es, die Konfiguration in allen Details automatisch nach Confluence oder in eine Tabelle (Excel, CSV, HTML) zu exportieren. Hiermit wird mit einem Knopfdruck eine umfangreiche technische Dokumentation erstellt. Bei Änderungen an der Konfiguration kann auf Knopfdruck die vorhandene Dokumentation angepasst werden. Wenn das nun in Confluence durchgeführt wird, kann über den Versionsvergleich alles angeschaut werden, was sich geändert hat.

Das alles hilft, bei einer freien Konfiguration aller Projekte die Übersicht zu behalten.

Sobald allerdings ein Standard eingesetzt wird, reduziert sich der Nutzen recht schnell, da ja alle Projekte auf derselben Konfiguration basieren, die dann eben nur einmal dokumentiert werden muss.

Secure Admin for Jira
  • Erweiterte Möglichkeiten, einzelne Bereiche der Jira-Administration für einzelne Nutzer oder Gruppen frei zu geben
Dieses Plugin ermöglicht es, Zugriff auf einzelne Admin-Bereiche zu beschränken. So kann man z.B. bestimmten Admins die Nutzerverwaltung erlauben, aber keine Projektkonfiguration. Andere wiederum können die Projektkonfiguation erledigen, aber keine Nutzer anlegen oder verwalten.

Dies kann helfen, die Aufgaben der Administration auf mehrere Personen zu verteilen. Wobei hier immer alle grundsätzlich einen Admin-Account benötigen.

Inwieweit eine Aufteilung einzelner Aufgaben der Administration hilfreich ist, muss man dann natürlich von Unternehmen zu Unternehmen entscheiden.

Auditor for Jira & Auditor for Confluence
  • Auditlog mit ALLEN administrativen Aktionen und Änderungen
  • Nachvollziehbarkeit aller Konfigurationsänderungen in Jira und Confluence
Der native Auditlog von Jira und Confluence zeigt bei weitem nicht alles, was im System passiert. Zudem zeigen sie auch Dinge, die einen System-Administrator eigentlich nicht interessieren. Diese beiden Plugins versprechen, alle administrativen Tätigkeiten zu loggen. Entsprechend kann der System-Admin immer schauen, welcher der Jira-Admins Veränderungen vorgenommen hat.

Außerdem hilft das Plugin bei Themen wie Nachvollziehbarkeit etc. rund um diverse ISO-Normen, die eine Nachverfolgbarkeit von Konfigurationsänderungen verlangen.

ScriptRunner for Jira & ScriptRunner for Confluence
  • Copy Project mit allen erdenklichen Funktionen
  • Scripte für sehr viele Use Cases
  • Zentrale Konfiguration für Feldverhalten in unterschiedlichen Projekten
  • Copy Space mit allen erdenklichen Funktionen
Wie oben beschrieben eignet sich dieses Plugin ausgezeichnet, die Anforderungen zu erfüllen.

Eine weitere in diesem Umfeld interessante Funktion ist Behaviours:

  • Es liegen mehrere Projekte vor, die alle den gleichen Standard verwenden. Mit den Behaviours können dann in einzelnen Projekten dedizierten Feldern ein eigenes “Verhalten” beigebracht werden. Beispiele sind hier:
    • Defaultwerte für bestimmte Felder pro Projekt und Tickettyp – ohne die Field Configuration anpassen zu müssen
    • Pflichtfelder pro Projekt und Tickettyp und Workflowschritt – ohne den Workflow anpassen zu müssen
    • Verstecken von Feldern auf bestimmten Masken und für bestimmte Nutzer
    • weitere gescriptete Verhaltensweisen von Feldern und Masken

Welche Plugins empfehlen wir?

Wie oben beschrieben erfüllen die Plugins aus der Liste nicht alle der hier betrachteten Anforderungen der automatisierten Anlagen von Projekten etc.

Aber dennoch möchten wir eine vorsichtige Empfehlung abgeben. Diese zeigt aber eher ein Gesamtszenario auf, in dem eine Kombination aus einigen Plugins zu einer deutlichen Erleichterung der Administration und damit zu weniger Aufwand führen kann.

Dies erscheint uns als Basis ausreichend. Alle anderen Plugins haben auch ihre guten Funktionen, aber in einem Umfeld, in dem man mit Projektstandards arbeitet, glauben wir, genügen die Plugins in diesem Vorschlag. Das Ganze ist natürlich auch ein Frage der Kosten und muss daher unter Berücksichtigung einer Kosten-Nutzen-Abwägung betrachtet werden.

Zusammenfassung

Es kann also sinnvoll sein, Standards für Projekte und Bereiche einzuführen, nicht nur weil das organisatorische Vorteile bietet, sondern auch weil es die Administration der Atlassian-Tools Jira und Confluence vereinfacht. Es gibt Lösungen, die die damit einhergehenden Anforderungen erfüllen und die mit überschaubarem Aufwand umgesetzt werden können.

Aber die Einführung solcher Standards ist ein Projekt, das wie alle Projekte organisatorische und technische Aspekte umfasst. Daher ist es auch wie ein Projekt durchzuführen, mit allen Facetten eines solchen Vorhabens.