Diese Seite setzt Cookies ein, um das Nutzerlebnis zu verbessern. Durch Klick auf "OK" erklärst Du Dich damit einverstanden. Mehr dazu gibt es unter Datenschutz.

OK

Die Koffer sind gepackt – Umzug auf ein neues JIRA

Wir benutzen JIRA schon eine ganze Weile – mit gutem Ergebnis. Nun steht der Umzug auf eine neuere Version an. Dabei gibt es das ein oder andere zu beachten.

Karte Reiseroute Umzug JIRA Confluence

Die Koffer sind gepackt, der Umzug auf ein neues JIRA kann starten! Den Weg sollte man sich vorher gut überlegen – damit steht und fällt die ganze Reise.

So ein Umzug bietet immer die Gelegenheit auszumisten – die sollte man immer nutzen. Damit meine ich nicht nur die offensichtlichen Dinge, wie zum Beispiel alte Issues aus dem Backlog rausschmeißen (selbst wenn man regelmäßiges Backlog Refinement betreibt, es bleibt immer was liegen), alte Projekte archivieren etc.

Ich meine auch so Sachen wie Projektkonfigurationen, etwa Workflows, Permissions, Notifications, Custom Fields und dergleichen. Aber auch Plugins und Add ons – mitunter lässt sich da je nach Lizenz auch etwas Geld sparen.

Was ich da alles gemacht habe und wie ich dabei vorgegangen bin und warum das Kennzeichen und Wesensmerkmal agilen Arbeitens ist, darum soll es in diesem und den nächsten paar Artikeln gehen.

Aufräumaktion #1:

Was soll überhaupt migriert werden?

Jeder der jetzt sagt: „ja alles halt!“ hat die Chance zum Aufräumen soeben verspielt. Denn in der Regel gilt: so viel wie nötig, so wenig wie möglich migrieren. Es geht – wieder einmal – ums Priorisieren: was ist wirklich wichtig?

Bei unserem Setup wird die alte JIRA Instanz noch weiter laufen und die Projekte und Issues darin verfügbar sein. Zwar nur read only, aber das reicht vollkommen aus. Für mich heißt das: alle geschlossenen Issues werden nicht umgezogen, ebenso alle fix versions die bereits ausgerollt wurden.
Auch Issues die sehr alt sind sollten hinterfragt werden – wenn es seit einem Jahr nicht zur Priorisierung und Einplanung gereicht hat, wie wahrscheinlich ist es, dass die Themen noch angegangen werden? Und – das kommt noch oben drauf – sind die Informationen in den Issues nach über einem Jahr noch aktuell und nutzbar? Wahrscheinlich nicht … also auch hier: nur Mut zur Entscheidung!

Das reduziert den Umfang des Umzugs enorm! Netter Nebeneffekt: alte User – vielleicht von Kollegen die gar nicht mehr mit dabei sind – werden nicht mit umgezogen. Die werden also auch nicht mehr in die Lizenz mit eingerechnet.

Als nächstes habe ich geprüft welche Projekte ich umziehen werde und wie diese konfiguriert sind. Sprich: Welche Projekte kann ich „stilllegen“ und welche werden tatsächlich noch gebraucht? Daran küpft die Frage an: Was kann ich zusammen mit den nicht gebrauchten Projekten abschalten? Workflows und Workflow Schemes? Oder vielleicht auch – *trommelwirbel* – Custom Fields? Hier muss man sich ehrlich die Frage stellen welche Custom Fields denn wirklich verwendet werden und ob die in der Form notwendig sind. Oft genug hat man sich am Anfang gedacht „wir tragen da diese und jene Information ein, dann können wir dies und das auswerten“ – macht man zu Beginn vielleicht sogar. Oftmals ebbt das leider ab. Also hier die Säge ansetzen und raus damit!

Das gilt im Übrigen für alle Sonderfälle die man irgendwo eingebaut hat. Am Anfang so eines Umzugs steht also die Vereinheitlichung dessen was umgezogen werden soll, getreu dem Motto:

[…] make the change easy (warning: this may be hard), then make the easy change

Und entsprechend hard war das auch – puh! Mitunter blockieren sich da Änderungen gegenseitig: Ein Screen Scheme kann nicht umgestellt werden, weil Informationen in Projekt 1 in Feld a stehen, in Projekt 2 jedoch in Feld b. Also erstmal beide verfügbar machen, alles ins gleiche Feld schreiben und dann das alte Feld wieder raus nehmen.

Oder die Workflows können nicht ohne Weiteres vereinheitlicht werden, weil sich die Status (ja, das ist der korrekte Plural von Status) nicht aufeinander mappen lassen. Hier musste ich sogar die ein oder andere Runde im Unternehmen drehen bevor ich die Workflows ändern konnte.

Auch ein beliebter Blocker: Die Personen die als reporter eingetragen sind, sind nicht mehr im Unternehmen. JIRA braucht aber immer einen validen reporter, sonst lassen sich die Issues nicht einfach so anpassen (bspw. per bulk change).

… es fällt nicht schwer sich vorzustellen, dass die Vereinheitlichung der Projekte eine kniffelige Arbeit sein kann, wenn JIRA seit vier bis fünf Jahren verwendet wird.

Aber es hat sich gelohnt. Die sieben JIRA Projekte die migriert werden sollen, sind vereinheitlicht. Alle Schemes und Konfigurationen sind gleich. Ausnahme sind die Workflow Schemes – die unterscheiden sich, abhängig davon ob es ein Projekt des Bereichs a oder b ist. Aber mit zwei verschiedenen Workflow Schemes lässt es sich gut leben – zumal die in den jeweiligen Bereichen konsequent für alle Projekte verwendet werden. Da gibt es keine Ausnahmen mehr.

Long story short: ich habe nun genau definiert was – welche Issues und welche Projektkonfigurationen – in Zukunft verfügbar sein sollen bzw. müssen. Und ich kann mich nun daran machen das Zielbild zu entwerfen – brauche ich Änderungen im Workflow? Im Notification Scheme? In den Project Roles? Jetzt ist der Zeitpunkt die vorzunehmen, aber dazu im nächsten Artikel mehr!

Verwandte Artikel

Schönen Samstag!