Jira FAQ: Projekte einrichten

Alle Vorgänge in Jira werden in Projekten verwaltet. Ein solches Projekt kann z.B. die Vorgänge eines Teams, eines Produktes oder eines realen Projektes beinhalten. Dabei kann jedes Jira-Projekt individuelle Vorgangstypen, Berechtigungen, Benachrichtigungen, Bildschirmmasken etc. besitzen. Wie man als Jira-Administrator ein neues Projekt anlegt und richtig konfiguriert, erfahren Sie in diesem Artikel.

Projekt anlegen

Zunächst muss das neue Projekt von einem Administrator angelegt werden. In der zugehörigen Maske muss ein Name, ein Schlüssel und ein Projektleiter eingegeben werden. Der Projektschlüssel wird jedem Vorgangsschlüssel vorangestellt – die Vorgänge im Projekt “MAR” heißen also “MAR-1″, “MAR-2″ usw.

Achtung: der Projektschlüssel kann nachträglich nicht mehr geändert werden!

Jira Projekt anlegen

Neues Projekt in Jira anlegen

Die Rolle des Projektleiters kann in Berechtigungsschemas, Benachrichtigungsschemas, Workflows etc. verwendet werden. Zm Beispiel kann die Berechtigung „Vorgänge schließen“ an die Rolle „Projektleiter“ statt an einen konkreten Benutzer vergeben werden. Weiterhin wird der Projektleiter standardmäßig als Bearbeiter neuer Vorgänge eingesetzt, sofern der Nutzer beim Erstellen des Vorgangs nicht manuell einen anderen Bearbeiter auswählt oder in der „Allgemeinen Konfiguration“ auch nicht-zugewiesene Vorgänge erlaubt sind.

Vorgangstypen auswählen

Jedem Projekt kann ein individuelles Vorgangstypschema zugewiesen werden. Ein solches Schema legt fest, welche Vorgangstypen in einem Projekt zur Verfügung stehen. Prinzipiell rate ich meinen Kunden, in einem Projekt nur diejenigen Vorgangstypen zuzulassen, die auch wirklich benötigt werden. Werden z.B. in einem Marketing-Projekt keine Bugs eingestellt, sollte dieser Vorgangstyp den Benutzern auch nicht zur Verfügung stehen. Zusätzlich kann sowohl die Reihenfolge als auch der standardmäßig vorausgewählte Vorgangstyp eingestellt werden.

Achtung: die projektbezogene Berechtigung „Vorgänge erstellen“ bezieht sich auf alle in einem Projekt verfügbaren Vorgangstypen. Eine Einschränkung bestimmter Vorgangstypen auf einzelne Gruppen oder Projektrollen ist nicht möglich (siehe https://jira.atlassian.com/browse/JRA-5865).

Jira Vorgangstypen

Auswahl der Vorgangstypen in Jira

Benutzerdefinierte Felder anlegen

Jeder Vorgang in Jira besitzt verschiedene Attribute, z.B. Name, Typ, Status, Priorität. Diese standardmäßigen Attribute können durch benutzerdefinierte Felder projekt- und vorgangstypabhängig erweitert werden. Bsp.: möchte man den Vorgangstyp “Support-Ticket” im Projekt “Support” um ein zusätzliches Feld “Name des Kunden” erweitern, legt man ein gleichnamiges benutzerdefiniertes Feld an und weist diesem im “Kontext” das entsprechende Projekt und den gewünschten Vorgangstyp zu. Im nächsten Schritt wählt man nur noch aus, in welchen Bildschirmmasken das neue Feld bearbeitet werden kann, und hat damit erfolgreich ein neues benutzerdefiniertes Feld angelegt.

Auch bei benutzerdefinierten Feldern rate ich meinen Kunden zu Sparsamkeit. Ein neues Feld kann zwar prinzipiell für alle Projekte, Vorgangstypen und Bildschirmmasken gleichzeitig freigegeben werden – ratsam ist aber, nur diejenigen Kontexte auszuwählen, in denen das Feld tatsächlich benötigt wird. Andernfalls überfüllt man die vorhandenen Bildschirmmasken mit unnützen und damit irreführenden Feldern.

Weitere Informationen zu benutzerdefinierten Felder unter Jira: Benutzerdefinierte Felder.

Workflows einrichten

Nachdem die Vorgangstypen für das neue Projekt ausgewählt wurden, muss nun entschieden werden, welche Arbeitsabläufe diese Vorgangstypen in diesem Projekt verwenden sollen. Dabei muss fachlich geprüft werden, ob die bereits vorhandenen Arbeitsabläufe für das neue Projekt verwendet werden können:

  • Verwenden alle Projekte für diesen Vorgangstyp die gleichen Schritte und Übergänge?
  • Werden unterschiedliche Workflowberechtigungen benötigt?
  • Ist absehbar, dass sich die Anforderungen eines der Projekte bald ändern werden?

Abhängig von diesen Kriterien können nun entweder bestehende Arbeitsabläufe zu einem neuen Arbeitsablaufschema zusammengefasst und dem neuen Projekt zugewiesen werden, oder neue Arbeitsabläufe angelegt werden.

Jira Standardworkflow

Jira Standardworkflow

Näheres zum Anlegen von Arbeitsabläufen unter Jira FAQ: Workflows sowie Jira Workflows: Best Practices und typische Fehler.

Projektrollen einrichten

In jedem Projekt sollten fachliche Projektrollen definiert und die Nutzer in Jira entsprechend zugeordnet werden. Die Arbeit mit Projektrollen (statt mit konkreten Nutzern) erleichtert u.a. die Zuordnung von Berechtigungen und Benachrichtigungen. Achtung: Projektrollen werden global angelegt – das bedeutet, dass in allen Projekten alle Projektrollen zur Verfügung stehen.

Näheres zur Arbeit mit Projektrollen unter Jira FAQ: Projekte und Projektrollen und Jira: Plädoyer für Projektrollen.

Berechtigungsschema anlegen

Beinahe jedes Projekt im produktiven Einsatz benötigt ein individuelles Berechtigungsschema. Das Berechtigungsschema legt fest, welche Projektrollen über welche Berechtigungen in diesem Projekt verfügen. Hier wird z.B. gesteuert, wer das Projekt und die darin enthaltenen Vorgänge sehen darf , wer neue Vorgänge erstellen oder bestehende Vorgänge in diesem Projekt löschen darf. Bei der Arbeit mit Berechtigungen in Jira gibt es 2 mögliche Ansätze:

  • Autonom: einer Berechtigung werden alle Projektrollen zugeteilt, die diese Berechtigung besitzen sollen. Bsp.: Administratoren, Entwickler und Nutzer sollen Vorgänge löschen dürfen. Demzufolge erhalten die Projektrollen  “Administrator”, “Developer” und “User” die Berechtigung “Vorgang löschen”.
    • Vorteil: jedem Nutzer muss nur eine Rolle zugewiesen werden und er erhält damit automatisch alle ihm zustehenden Berechtigungen.
    • Nachteil: das Berechtigungsschema kann unübersichtlich werden.
  • Hierarchisch: die Projektrollen werden als Hierarchie aufgefasst und einer Berechtigung wird nur die “niedrigste” Projektrolle zugewiesen. Bsp.: die Berechtigung “Vorgang löschen” erhält nur die Projektrolle “User”.
    • Vorteil: kleinere und übersichtliche Berechtigungsschemas.
    • Nachteil: ein Nutzer muss seine “höchste” Projektrolle und auch alle niedrigeren Rollen erhalten. Bsp: ein Nutzer der Projektrolle “Administrator” muss gleichzeitig die Rollen “Developer” und “User” erhalten, damit er alle notwendigen Berechtigungen erhält.

Ich rate meinen Kunden stets, die Projektrollen autonom zu behandeln und sich damit für Variante 1 zu entscheiden. Der ausschlaggebende Vorteil dieser Variante ist die niedrigere Fehleranfälligkeit. Die Komplexität liegt hier bei den Administratoren, nicht bei den Projektleitern. Ein Projektleiter muss damit jedem Teammitglied nur eine einzige Rolle zuweisen, statt z.B. zu überlegen, welche Rollen einem neuen “Developer” nun zugewiesen werden müssen, damit er in Jira arbeiten kann. Leider verwendet das Standardberechtigungsschema in Jira Variante 2 – hier sollte man als Admin also Vorarbeit leisten und seine Berechtigunggschemas entsprechend anpassen.

Weitere Informationen zu Berechtigungen unter Jira: Berechtigungen, Berechtigungsschemas und Sicherheitslevels.

Bildschirmmasken anlegen

In Jira ist jedem Projekt ein “Bildschirmmaskenschema für Vorgangstypen” zugeordnet. Darin wird festgelegt, welcher Vorgangstyp welches Bildschirmmaskenschema verwenden soll. So kann z.B. für den Vorgangstyp „Aufgabe“ ein anderes Bildschirmmaskenschema verwendet werden als für den Vorgangstyp „Softwarefehler“. Werden für ein Projekt individuelle Bildschirmmasken benötigt (z.B. weil neue benutzerdefinierte Felder angelegt wurden, die nur in diesem Projekt angezeigt werden sollen), müssen entsprechende Bildschirmmasken und Bildschirmmaskenschemas angelegt und einem Bildschirmmaskenschema für Vorgangstypen zugeordnet werden.

Näheres zu Bildschirmmasken unter Jira: Bildschirmmasken und Bildschirmmaskenschemata.

Benachrichtigungen definieren

Für jedes Projekt in Jira kann ein Benachrichtigungsschema definiert werden. Ein solches Schema legt fest, bei welchen Ereignissen an welche Benutzer eine Benachrichtigung per E-Mail versendet werden soll. Bsp.: in einem Projekt „Support“ erhält der Projektleiter eine Benachrichtigung per E-Mail, wenn ein Vorgang erstellt wird oder in den Status „eskaliert“ übergeht. Als Empfänger einer Benachrichtigung können u.a. einzelne Nutzer, Gruppen, Rollen, Mailadressen, der Autor, der aktuelle Bearbeiter, der Projektleiter sowie Benutzer in benutzerdefinierten Feldern angegeben werden.

Achtung: Benachrichtigungen sind unabhängig vom Vorgangstyp – in einem Projekt werden für alle Vorgangstypen die gleichen Benachrichtigungen versendet.

Einrichten eines Benachrichtigungsschemas in Jira

Einrichten eines Benachrichtigungsschemas in Jira

Sicherheitsschema einrichten

Innerhalb eines Projektes kann es notwendig sein, die Sichtbarkeit einzelner Vorgänge auf bestimmte Nutzerkreise zu beschränken. Jira setzt diese Anforderung durch Sicherheitsschemata um.  Innerhalb eines Sicherheitsschemas werden Sicherheitsstufen definiert und mit einzelnen Benutzern, Benutzergruppen oder Projekt- bzw. Vorgangsrollen verknüpft. Vorgänge, für die eine Sicherheitsstufe ausgewählt wurde, sind ausschließlich für die mit dieser Stufe verknüpften Nutzerkreise sichtbar. Im einfachsten Fall kann z.B. eine Sicherheitsstufe “Administratoren” angelegt und der Benutzergruppe “jira-administrators” zugeordnet werden. Alle Vorgänge, für die diese Sicherheitsstufe ausgewählt wird, sind dann ausschließlich für Mitglieder der Gruppe “jira-administrators” sichtbar.

Einrichten von Sicherheitsstufen in Jira

Einrichten von Sicherheitsstufen in Jira

Achtung: beim Erstellen eines Sicherheitsschemas sollte eine Standardstufe festgelegt werden, die alle neu erstellte Vorgänge automatisch erhalten. Das ist besonders dann wichtig, wenn nicht alle Projektmitglieder die Berechtigung zum Auswählen einer Sicherheitsstufe besitzen oder die entsprechenden Felder über die Feldkonfiguration ausgeblendet wurden. Andernfalls kann es schnell passieren, dass unbewusst Vorgänge  ohne Sicherheitsstufe erstellt werden.

Komponenten und Versionen anlegen

Falls notwendig, können für ein Projekt Komponenten und Versionen angelegt werden. Komponenten stellen eine zusätzliche Gliederungsmöglichkeit für Vorgänge dar: in einem Softwareentwicklungsprojekt können z.B. Komponenten für GUI, Datenbank und Anwendungslogik angelegt werden. Vorgänge können dann einer oder mehreren Komponenten zugeordnet werden. Zusätzlich kann für jede Komponente ein Komponentenleiter bestimmt und als standardmäßiger Bearbeiter für neue Vorgänge ausgewählt werden.

Versionen können für verschiedene Lebenszyklen von Projekten verwendet werden. Im Beispiel des Softwareentwicklungsprojektes können verschiedene Versionen für Alpha-, Beta- und Releaseversionen angelegt werden. Sowohl die standardmäßigen Übersichten als auch die Dashboard-Widgets beziehen Versionen in ihre Übersichten mit ein (z.B. Anzeige der noch offenen Vorgänge für eine Version, Anzeige alle gelösten Vorgänge einer Version inkl. automatischer Releasenotes etc.).

Fazit

Beim Einrichten eines neuen Projektes in Jira sollte einige Zeit in die Planung und Konzeption der notwendigen Vorgangstypen, Arbeitsabläufe, Schemas und Einstellungen gesteckt werden. Erstellt man ein Projekt “quick and dirty”, wird es später um so aufwendiger, die durch unsaubere Konfiguration aufgetretenen Probleme zu beheben.

Ein weiterer Punkt, den ich meinen Kunden nur ans Herz legen kann: Dokumentation. Nur wenn den Nutzern einfache Übersichten zur Verfügung stehen, z.B. über die mit einer Projektrolle verbundenen Berechtigungen, kann das System langfristig gut benutzt und akzeptiert werden. Für die Dokumentation solcher Projekte empfehle ich natürlich Atlassian Confluence.

13. Februar 2013 von Sebastian Höhne
Kategorien: Jira | Schlagwörter: | 3 Kommentare

Kommentare (3)

  1. Hallo Herr Höhne,
    lt. Atlassian-Dokumentation kann ein Jira-Projektleiter Komponenten und Versionen anlegen. Obwohl wir das Jira-Standardberechtigungsschema verwenden, hat der Jira-Projektleiter nicht das Recht, Komponenten und Versionen anzulegen.
    Wo kann ich noch suchen? Woran kann das liegen?
    Vielen Dank,
    mit freundlichen Grüssen
    Ulla Schneider

    • Hallo Frau Schneider,

      der Projektleiter hat standardmäßig keine besonderen Rechte, er wird nur bei neu erstellten Tickets automatisch als Bearbeiter ausgewählt. Das Recht, die Komponenten und Versionen eines Projektes zu verwalten, wird im Berechtigungsschema über die Berechtigung “Projekte verwalten” erteilt (siehe “Managing Project Permissions“). Wenn bei Ihnen der Projektleiter die Versionen und Komponeten des Projektes verwalten soll, müssen Sie also noch in das Berechtigungsschema des entsprechenden Projektes gehen und dort bei der Berechtigung “Projekte verwalten” die Einstellung “Projektleitung” hinzufügen. Damit hat dann immer automatisch der Projektleiter das Recht, das Projekt zu verwalten.

      Beste Grüße,
      Sebastian Höhne

Schreibe einen Kommentar

Pflichtfelder sind mit * markiert


feedback