Pros und Contras der Next-Gen-Projekte in Jira Cloud

Ein Kritikpunkt an Jira war lange Zeit die etwas umständliche Nutzererfahrung. Die Lernkurve, um auch simple Projekte effizient zu administrieren, war deutlich höher als zum Beispiel in Trello. Mit den Next-Gen-Projekten ist Atlassian 2018 angetreten, um dies in der Cloud zu ändern. Im Fokus standen mehr Kontrolle für Projektadministratoren und eine bessere Benutzererfahrung für alle. Heute, zwei Jahre später, werden Next-Gen-Projekte immer ausgereifter und auch die Unterstützung dieser neuen Projektart seitens der Add-on-Entwickler steigt kontinuierlich. Trotzdem ist zu bedenken, dass es sich hierbei immer noch um einen „Work in Progress“ handelt. Im Folgenden schauen wir uns an, was Next-Gen-Projekte von ihrer klassischen Variante unterscheidet.

Next-Gen-Projekte in Jira bieten eine schnelle und simple Lösung für kleine Teams mit einfachen Anforderungen. Ein Board, ein Workflow, ein paar benutzerdefinierte Felder – das sind die häufigsten Anforderungen für Jira-Administratoren. Inklusive Abstimmung und Anpassung kann das schon ein paar Stunden Aufwand bedeuten. Das Set-up eines Next-Gen-Projektes hingegen ist von jedem Benutzer selbst zu stemmen und dabei erfrischend einfach.

Um ein Next-Gen-Projekt anzulegen, wählst du „Next-Gen“ als Projekttyp und entscheidest dich dann für eine der beiden Projektvorlagen: Scrum oder Kanban. Scrum bietet Backlogs und Einteilungen in Sprints, während Kanban das traditionelle Board abbildet und dir die Freiheit lässt, wann du welche Aufgaben beginnst oder beendest. Mit diesen zwei Schritten hast du bereits ein Projekt mit einem Board und Standardworkflow und könntest sofort mit der Projektarbeit loslegen oder mit der weiteren Konfiguration fortfahren. Hier zeigt sich eines der großen Unterscheidungsmerkmale der Next-Gen-Projekte: Einstellungen können fast vollständig vom Projektadministrator konfiguriert werden, ohne dass ein Jira-Administrator eingreifen muss. So wird die Verantwortung an die Projektadmins delegiert – damit geht verständlicherweise eine gewisse Simplifizierung einher.

Jede Spalte im Board entspricht dem jeweiligen Status im Workflow. Durch das Hinzufügen einer neuen Spalte wird automatisch ein entsprechender Workflow-Schritt ergänzt. Allerdings müssen wir in Next-Gen-Workflows auf Validatoren und Post-Functions, wie wir sie aus traditionellen Workflows kennen, aktuell noch verzichten. Jedes Projekt hat nur ein Board und einen Workflow für alle Vorgangstypen. Bis zu 30 neue Vorgangstypen können hinzugefügt werden, allerdings nur auf der mittleren Ebene: Es lassen sich keine weiteren Vorgangstypen auf der Ebene der Epics oder der Unteraufgaben hinzufügen. Jeder dieser Vorgangstypen kann direkt vom Projektadministrator mit benutzerdefinierten Feldern bestückt werden. Diese sind auf das eigene Projekt begrenzt und können nicht mit anderen Projekten geteilt werden. Sie tauchen auch nicht in der Konfiguration der klassischen Projekte auf, sodass unabhängig von der Anzahl an Next-Gen-Projekten die Übersicht über globale Felder gewahrt bleibt.

Es gibt auch keine komplexen Berechtigungsschemata über Benutzergruppen und Projektrollen. Next-Gen-Projekte haben drei feste Benutzerrollen und der Projekt-Administrator legt für jeden Benutzer fest, ob dieser im Projekt nur mitliest (Viewer), mitarbeitet (Member) oder administriert (Administrator). Feinanpassungen, also wer was tun oder sehen darf, sind hier nicht vorgesehen. Next-Gen-Projekte sind grundsätzlich offen: Das heißt, jeder Benutzer der entsprechenden Jira-Instanz kann jedes Next-Gen-Projekt als Member einsehen und bearbeiten. Das entspricht der allgemeinen Atlassian Philosophie von „open collaboration“. Allerdings kann es Probleme bereiten, wenn beispielsweise Worklogs nicht für alle einsehbar sein sollen. Zusammengefasst: Das Konzept der Schemata, um bestimmte Konfigurationseinstellungen abzuspeichern, wurde für Next-Gen-Projekte über Bord geworfen. Jeder Projektadministrator legt für sein Projekt Berechtigungen, Vorgangstypen und benutzerdefinierte Felder individuell fest. Diese Einstellungen lassen sich nicht mit anderen Projekten teilen. Das erlaubt wiederum jedem Projektadmin, sein Projekt nach Wunsch anzupassen – ohne die Sorge, dass über das Schema andere Projekte in Mitleidenschaft gezogen werden.

Alles in allem bringen Next-Gen-Projekte einige langgewünschte Features. Das Interface und die generelle User-Experience wurden weiter verbessert. Die Delegierung der Projektadministration in die Hände der Projektleiter reduziert den Betreuungsaufwand signifikant. Und wie eingangs erwähnt, sind die Next-Gen-Projekte noch nicht „done“ – es gibt einige spannende Dinge, auf die wir uns in Zukunft freuen können.

Habt ihr Fragen zum Thema Next-Gen-Projekte? Schreibt uns gerne einen Kommentar.