Jira Schemata sind ein komplexes und teilweise nur schwer verständliches Aufgabengebiet. Und das nicht nur für frischgebackene Jira-Administratoren, sondern auch für Atlassian-Veteranen. Es kommt nicht selten vor, dass ein Jira-Admin sich durch viele unterschiedliche Schemata mühsam durcharbeiten muss, wenn eine Anpassung vonnöten ist. Bei größeren und historisch gewachsenen Systemen können es sogar hunderte Schemata sein.
Hier ein Beispiel aus einem "Worst Case"-Szenario.
Schemata zu konfigurieren und anzupassen, ist aber ein zentraler Bestandteil der täglichen Aufgaben eines Jira-Admins. In diesem Blog bringen wir Licht ins Dunkel und erklären Ihnen, welche Schemata es gibt, wie diese zusammenspielen und wie Sie dem Schemata-Chaos langfristig Einhalt gebieten.
Was sind Jira Schemata?
Schemata sind eine Möglichkeit, mit der Sie die Konfiguration unterschiedlicher Jira-Komponenten standardisiert für mehrere Projekte einstellen. Elementare Bestandteile eines Jira-Projekts, wie die Status(-übergänge) eines Workflows, die verfügbaren Vorgangstypen und angezeigte Bildschirmmasken, lassen sich mit Schemata konfigurieren.
Folgende Schemata können Sie in Jira konfigurieren:
- Vorgangstypenschema
- Workflow-Schema
- Bildschirmmaskenschema
- Bildschirmmaskenschema für Vorgangstypen
- Feldkonfigurationsschema
- Benachrichtigungsschema
- Berechtigungsschema
Sie ordnen jedem Jira-Projekt eines der obigen Schemata zu. Anschließend konfigurieren Sie selbst, welche dazugehörige Komponente in welchem Fall angezeigt wird. So lässt sich beispielsweise im Bildschirmmaskenschema definieren, welche Bildschirmmasken Jira beim Erstellen, Bearbeiten und Anzeigen von Vorgängen anzeigt. So kann die Software während der Erstellung eines Vorgangs etwa nur ein einzelnes relevantes Pflichtfeld abfragen und alle anderen Felder erst bei der späteren Bearbeitung im Workflow ergänzen.
Standardmäßig legt Jira bei der Erstellung eines Projekts immer ein neues Projekt-spezifisches Vorgangstypenschema, Workflow-Schema, Bildschirmmaskenschema und Bildschirmmaskenschema für Vorgangstypen an und weist dieses dem Projekt zu. Bei den anderen möglichen Schemata wird automatisch das Standard-Schema verwendet, welches out-of-the-box verfügbar ist. Es ist allerdings bei der Erstellung auch möglich, die obengenannten vier projektspezifischen Schemata mit einem anderen Projekt zu teilen.
Wichtiger Hinweis: Legen Sie ein neues Projekt an, können Sie bestehende Schemata aus einem bereits existierenden Projekt wiederverwenden. Das hat jedoch den Nachteil, dass sich Änderungen bei geteilten Schemata in allen betroffenen Projekten vererben. Wollen Sie dies bei bestimmten Projekten verhindern, müssen Sie dort individuelle Schemata anlegen.
Wie spielen Jira Schemata zusammen?
Alle Jira Schemata sind eng miteinander verzahnt und bestimmen in Kombination, was für ein Vorgang angezeigt wird und welche Aktionen möglich sind – zum Beispiel Feldänderungen, Workflow-Schritte, Kommentare etc.
Schauen wir uns das Ganze mal anhand eines Beispiel-Vorgangs an und arbeiten uns anhand dessen Stück für Stück voran: Zuerst erstellen wir einen Vorgang. In der Erstellungsmaske sind auch gleich die ersten Auswirkungen eines Schemas sichtbar. Die hier in der Erstellungsmaske angezeigten Felder werden in einer Bildschirmmaske festgehalten. Jira ordnet diese Bildschirmmaske im Bildschirmmaskenschema für die Vorgangsfunktion „Standard“ zu. Das heißt, dieselbe Bildschirmmaske kommt sowohl bei der Erstellung als auch Bearbeitung und Betrachtung des Vorgangs zum Einsatz.
Von der Ebene des Bildschirmmaskenschemas geht es anschließend auf die nächsthöhere Ebene Bildschirmmaskenschema für Vorgangstypen. Hier bestimmt der Nutzer, welches Bildschirmmaskenschema in Abhängigkeit des Vorgangstyps verwendet wird. So können Bugs und Storys unterschiedliche Bildschirmmasken angezeigt bekommen. Nur das Bildschirmmaskenschema für Vorgangstypen wird dem Projekt zugeordnet. Auf die anderen hier genannten Schemata wird implizit über das Bildschirmmaskenschema für Vorgangstypen zugegriffen.
Neuer Jira Issue – bereit zum Einsatz
Jetzt haben wir unser Issue erstellt, es mit Inhalten gefüllt und können damit arbeiten. Jetzt fällt jedoch auf: Technische Redakteure pflegen das Komponenten-Feld oftmals gar nicht! So passiert es, dass Scrum Master manche Vorgänge dem falschen Entwickler zuweisen. Diesen Fehler können wir mit dem Feldkonfigurationsschema präventiv vermeiden. Im Feldkonfigurationsschema lassen sich einzelne Feldkonfigurationen einem Vorgangstyp zuordnen. In der Feldkonfiguration selbst können Sie Felder komplett ausblenden, je nach Projekt unterschiedlich beschriften und als Pflichtfeld markieren. Auch hier wird nur das Feldkonfigurationsschema einem Projekt zugeordnet und damit implizit auf die vorgangstypabhängigen Feldkonfigurationen zugegriffen.
Für die Zukunft ist unser Projekt nun gewappnet und es sollte keine Missverständnisse bezüglich falscher Komponenten geben. Jetzt können die Entwickler loslegen und den Vorgang durch den Workflow schleusen. Welche Workflow-Schritte möglich sind, hängt vom im Projekt eingestellten Workflow-Schema ab. Workflow-Schemata regeln, man kann es sich fast schon denken, welcher Workflow bei welchem Vorgangstyp zum Einsatz kommt. Damit können etwa im gleichen Projekt Storys und Bugs zwei separate Workflows durchlaufen.
Wie Sie vielleicht schon bemerkt haben, hängen fast alle der bis jetzt besprochene Schemata in irgendeiner Art und Weise mit Vorgangstypen zusammen. Daher gehen wir noch kurz auf die letzte Schema-Art ein, die bei der Projekterstellung automatisch erzeugt wird: das Vorgangstypenschema. Diesem können beliebig viele Vorgangstypen zugeordnet werden. Ein Vorgangstypenschema wird anschließend mit einem Projekt verknüpft. Im Projekt ist es dann nur möglich, die im Vorgangstypenschema definierten Vorgangstypen zu erstellen.
Die zwei wichtigsten Jira Schemata
Last but not least haben wir noch zwei wichtige Schemata: das Berechtigungsschema und das Benachrichtigungsschema. Beide sind nicht an Vorgangstypen, sondern an Personen geknüpft. Berechtigungsschemata steuern, wer in einem Projekt Aktivitäten wie „Vorgänge zuweisen“, „Kommentare hinzufügen“ oder „Sprints verwalten“ durchführen kann. Benachrichtigungsschemata hingegen bestimmen, wer bei solchen Aktivitäten eine E-Mail-Benachrichtigung erhält. Beide Schema-Arten haben jedoch eines gemeinsam: die Schemata können so verallgemeinert werden, dass sie sich global für alle Projekte verwenden lassen und Sie diese trotzdem noch pro Projekt individualisieren können!
Die Kraft liegt in den vielfältigen Zuweisung-Möglichkeiten, die für die beiden Schemata möglich sind. Es kann bspw. dynamisch der aktuell zugewiesene Benutzer eines Vorgangs, Mitglieder einer bestimmten Projektrolle, der Vorgangsautor oder aber auch Benutzer aus benutzerdefinierten Feldern verwendet werden. Damit ließe sich beispielsweise folgendes Szenario lösen:
- bei neuen Kommentaren und Änderungen am Vorgang selbst à immer den zugewiesenen Benutzer benachrichtigen
- nur der aktuell zugewiesene Benutzer kann Vorgänge im Workflow weiterbewegen
- bei Fertigstellung eines Vorgangs à Projektleiter, Autor und einen benutzerdefinierten Kontakt per E-Mail benachrichtigen
- Mitglieder der Projektrolle „Stakeholder“ dürfen Vorgänge zuweisen, aber nur Mitgliedern der Projektrolle „Entwickler“ können diese Vorgänge zugewiesen werden
Best Practices: wiederverwendbare Projektstrukturen
Sie sollten Projekte möglichst immer mit demselben Ablauf abwickeln. Dieser Ansatz müssen auch außerhalb von Jira (beim eigentlichen Projektmanagement) einhalten. Das heißt zum Beispiel, dass Sie Entwicklungsprojekte agil nach Scrum oder klassisch nach Wasserfallmodell durchführen. Es sollte nicht vorkommen, dass Projekte eine Mischung aus beiden Methoden enthalten oder stark vom Standard abweichen. Das ermöglicht dem Jira-Administrator, einige wenige allgemeingültige Schemata zu erstellen, welche die Beteiligten dann bei allen Projekten anwenden können.
In der Praxis ist es häufig der Fall, dass zwar viele unterschiedliche Projekte mit ähnlichen Schemata erstellt wurden, man diese aber nicht konsolidiert hat. Ein typischer Fall von „historisch gewachsen“. Die Konsolidierung fällt allerdings nicht leicht, da Sie sich stets mit dnegativen Projektleitern abstimmen müssen, wie die Schemata (und damit auch Workflows, Vorgangstypen, Bildschirmmasken und Feldkonfigurationen!) zukünftig aufgebaut sein sollen. Je nach Projekt haben Sie womöglich auch eine individuelle Vereinbarung zu treffen. Ihr Ziel sollte es sein, möglichst viel zu standardisieren. So ist die Navigation sowohl für Administratoren als auch für die Endanwender einfacher und zielgerichteter.
In diesem Zuge empfehlen wir Ihnen, sämtliche Schemata und deren dazugehörige Funktionalität einheitlich zu benennen. Bei unzähligen Schemata mit vielfältigen Namen verlieren Sie schnell den Überblick. Namen wie „BM_Scrum_Story“ für „Bildschirmmaskenschemata, Projektstil „Scrum“ und Vorgangstyp „Story“ machen sofort klar, welchem Zweck das jeweilige Schema dient.
Unser letzter Tipp funktioniert am besten, wenn Sie ihn mit unserem ersten Tipp dieses Blog-Beitrags kombinieren: Setzen Sie soweit wie möglich auf Projektrollen. Der Projektadministrator verwaltet die Projektrollen selbst und ermöglichen so größtmögliche Flexibilität, ohne einen Jira-Administrator einschalten zu müssen. Wenn in den allgemeingültigen Schemata Projektrollen zum Einsatz kommen, dann hat der Projektadministrator eine gewisse Autonomie über sein Projekt und dessen Mitglieder. Szenarien wie projektrollenabhängige Benachrichtigungen (wie oben beschrieben) können somit selbst vom Projektadministrator verwaltet werden, ohne dass der Jira-Administrator Änderungen an den Schemata oder dem Projekt vornehmen muss.
Wir hoffen, ein wenig Licht ins Dunkel gebracht zu haben. Sollten Sie aber weiterhin im Dunkel tappen, nehmen Sie einfach Kontakt zu uns auf und wir stehen Ihnen gern mit Rat und Tat zur Seite.
