Jira Cloud Next-Gen Software Projekte - 5 Unterschiede, die Sie kennen sollten

1. Boards

Grundsätzlich gibt es nicht mehr das Kanban- oder das Scrum-Board. In der nächs­ten Generation gibt es nur noch das Board. So ist es auch nicht mög­lich, meh­rere ver­schie­dene Boards in einem Next-Gen Projekt zu hin­ter­le­gen. Das ein­zige Projekt-Board ist statt­des­sen enger mit dem Projekt selbst ver­knüpft und kann in den Projekteinstellungen mit ver­schie­de­nen Features auf­ge­bohrt oder eben genau um diese redu­ziert wer­den.

Wird so zum Beispiel die Funktion "Sprints" akti­viert, wird das Board zum Scrum Board. Dies ist nur ein Klick in den Projekteinstellungen. Genau so ein­fach kann aber auch ein Kanban Board mit einem Backlog aus­ge­stat­tet wer­den oder Berichte akti­viert oder deak­ti­viert wer­den. Wird eine Funktion akti­viert, taucht diese in der lin­ken Menüleiste des Projektes auf und ist ver­füg­bar.

Die Konfiguration des Boards wurde auch deut­lich ein­fa­cher gestal­tet. Spalten sind fest mit gleich­na­mi­gen Workflow-Status ver­knüpft und kön­nen direkt im Board erstellt, bear­bei­tet und ent­fernt wer­den. Ebenso Schwimmbahnen und Quick Filter. Dabei fällt auf, dass die Einstellungen an sich, im Vergleich zu klas­si­schen Board, teils stark ver­än­dert wur­den. Beispielsweise fal­len die bekann­ten JQL-Quickfilter weg, dafür gibt es eine Volltextsuche direkt unter dem Boardnamen und vor­ge­fer­tigte Out-of-the-box Filter. In ein Board ohne Sprintfunktion kann auch direkt aus der pas­sen­den Spalte her­aus ein neuer Vorgang erstellt wer­den. Dieser hat dann direkt den Status der Spalte, aus der er erstellt wird, und muss nicht durch den Workflow geführt wer­den.

Die Möglichkeit das Kartenlayout anzu­pas­sen fällt hin­ge­gen ganz weg. Ebenso ver­hält es sich mit der Grundlage klas­si­scher Jira-Boards, den Filtern. So fällt die Funktion, durch den hin­ter­leg­ten JQL-Filter grund­sätz­lich nur bestimme Vorgänge auf dem Board anzei­gen zu las­sen, ganz weg. Alle Vorgangstypen und Workflow-Status, die im Projekt ein­ge­rich­tet sind, wer­den auch auf dem Board dar­ge­stellt, sofern Vorgänge dazu exis­tie­ren.

Neu sind die soge­nann­ten Regeln. Sie bie­ten die Möglichkeit klei­nere Automatismen zum Board hin­zu­zu­fü­gen, die beim Statusübergang eines Vorgangs aus­ge­führt wer­den. Aktuell sind dort nur 2 Regeln aus­wähl­bar, "Einer Person einen Vorgang zuwei­sen" und "Vorgangsfeld aktua­li­sie­ren", laut Atlassian kom­men jedoch bald mehr.

2. Die Projektadministration

Auf den ers­ten Blick erkenn­bar ist, dass sich die Anzahl der Menüpunkte am lin­ken Rand deut­lich ver­rin­gert hat. Von klas­sisch circa 16 auf 5. Dies liegt unter ande­rem daran, dass sich die Menüführung inner­halb der Projektadministration leicht geän­dert hat. So sind weni­ger rele­vante und zum Teil kri­ti­sche Punkte, wie zum Beispiel "Projekt löschen", in Untermenüs gewan­dert. Andererseits wurde die Administration des Projektes selbst deut­lich ver­än­dert und zum Teil anders gelöst (oder fal­len für die­sen Projekttyp ein­fach weg). So wurde zum Beispiel die Art der Nutzerberechtigung über Projekt-Rollen und Permission Scheme stark ver­ein­facht und auf die 3 Projektrollen "Administrator", "Member" und "Viewer" redu­ziert und das klas­si­sche Berechtigungsschema abge­schafft.

Ähnlich sieht es auch mit den Schemata für Vorgangstypen, Workflows, Bilschirmmasken und Feldern aus. Vorgangstypen und Felder kön­nen im Punkt "Vorgangstypen" unkom­pli­ziert mit weni­gen Klicks ange­passt, neu hin­zu­ge­fügt oder ent­fernt wer­den, ganz ohne die Mitwirkung eines Jira-Admins. Workflows sind aus der Projektadministration ver­schwun­den. Felder wer­den dabei für jeden Vorgangstyp indi­vi­du­ell bestimmt und admi­nis­triert. Ein gemein­sa­mes Schema kann nicht genutzt wer­den.

Neu ist der Menüpunkt "Funktionen" in dem ein­ge­stellt wer­den kann, wel­che Features im Projekt benutzt wer­den kön­nen.

3. Bildschirmmasken

Wie bereits ange­deu­tet, ver­folgt Atlassian hier auch bei den Bildschirmmasken ein ande­res Konzept. Die Schemata sind ver­schwun­den, sowie auch die Trennung in "Vorgang erstel­len", "Vorgang bear­bei­ten" und "Vorgang anzei­gen". Ist ein Feld für einen Vorgangstyp ein­ge­rich­tet, ist die­ses auch immer zu sehen und kann bear­bei­tet wer­den.

Welche Felder benutzt wer­den kön­nen, wird für jeden Vorgangstyp ein­zeln fest­ge­legt. Ebenso wie even­tu­elle Standardwerte, kön­nen auch neue Felder mit weni­gen Klicks erstellt wer­den.

4. Workflows

Der klas­si­sche Workflow eines Vorganges mit gra­fi­scher Darstellung am Vorgang, fest­ge­leg­ten Statusübergängen, Folgefunktionen, Bestätigungen und Bedingungen ist ver­schwun­den. Stattdessen wer­den Status über die gleich­na­mi­gen Spalten des Projekt-Boards bestimmt und die im Board hin­ter­leg­ten Regeln erset­zen man­che Folgefunktionen. Statusübergänge sind prin­zi­pi­ell von allen Status zu jedem ande­ren mög­lich.

Wie bei den Feldern und Bildschirmmasken, sind auch hier Schemata ver­schwun­den. Alle Vorgangstypen eines Projektes nut­zen das­selbe Board und somit auch den­sel­ben Workflow.

Workflows und Boards kön­nen nicht ein­fach mit einem ande­ren Next-Gen Projekt geteilt wer­den.

5. Die Roadmap

Die Roadmap ist eine über­sicht­li­che gra­fi­sche Darstellung von Epics auf einer Zeitachse, die zugleich die Möglichkeit bie­tet, diese direkt dort anzu­pas­sen.

Der Gedanke dahin­ter ist, dass es für moderne Software Teams immer sel­te­ner klas­sisch große, gemein­same und feste Veröffentlichungsdaten gibt. Stattdessen ent­wi­ckeln, tes­ten und ver­öf­fent­li­chen meh­rere klei­nere Teams kon­ti­nu­ier­lich Teile der Gesamtlösung. So ist quasi jeden Tag Release Tag.

Das Roadmap-Feature soll es genau für diese Teams ein­fa­cher machen, eine indi­vi­du­elle über­ge­ord­nete Strategie zu visua­li­sie­ren und diese mit weni­gen Klicks zu tei­len. So soll jedem Teammitglied ermög­licht wer­den ein kla­res Bild der über­ge­ord­ne­ten Strategie zu bekom­men und zu sehen, wie die ein­zel­nen Teilaufgaben in die­ses hin­ein­pas­sen.