Hauke Wollentin

Ziele des Kunden: Nach einem Merger von vier Firmen sollten diverse kleinere Atlassian Data Center und Cloud Instanzen in eine große Instanz je Tool konsolidiert werden

Auswirkung des Projekts: Senkung der Lizenzkosten um ~50% sowie einheitliches und kollaboratives Arbeiten aller Mitarbeitenden in einem einzigen Toolstack.

Für jede kleinere Jira und Confluence Instanz wurde initial eine Inventarisierung durchgeführt. Es wurden Project- und Space-Verantwortliche benannt und auf dem Papier eine Vorausgewahl getroffen welche Inhalte migriert werden müssen und welche archiviert.

Neben den eigentlichen Inhalten wurde analysiert welche Workflows, Screens, Issue Types usw. im Zuge der Migration konsolidiert werden konnten. So sollte "duplicate code" vermieden werden.

Es wurden Skripte in SkriptRunner erstellt um unter Anderem durch die Migration kaputt gegangene Hardlinks oder auch User Referenzen zu reparieren.

Die Migrationen waren primär Data Center zu Data Center, je Tool wurde eine Migration von Cloud zu Data Center durchgeführt.

Um den Impact auf die Mitarbeitenden so gering wie möglich zu halten, wurden die meisten Inhalte kleinteilig (auf Project- oder Space-Ebene) in enger Abstimmung mit den Stakeholdern migriert.

Ziele des Kunden: Im Rahmen eines Pilotprojekts für agile Arbeitsmethoden sollten zwei Teams von der grünen Wiese hin zu einem Scrum Prozess unter Zuhilfenahme von Jira Cloud geführt werden. Weiterhin sollte während der Transformation eine auf Excel basierte "Ticketliste" mit mehreren zehntausend Zeilen in ein Jira Project überführt werden, um einen Showcase für Jira im Unternehmen darzustellen.

Auswirkung des Projekts: Awareness für agile Arbeitsmethoden wurde geschaffen, was zu mehr Transparenz in den Teams aber auch im Upper Management geführt hat wodurch Fehlervektoren in der Projektplanung minimiert und die allgemeine Effizienz der Planung gesteigert werden konnte.

Nach der Benennung zweier Teams aus der Produktentwicklung für das Pilotprojekt "Scrum einführen" wurde anhand von Keyuser Gesprächen eine Anforderungsliste an Jira erstellt und etwaig zu benutzende Plugins eruiert.

Jira Cloud wurde für den Grossteil des Unternehmens geplant und aufgesetzt.

Ein Gruppen- bzw. Berechtigungskonzept wurde direkt mit entwickelt und implementiert.

Parallel zum Scrum Enablement wurden die Projektteams sowie weitere Stakeholder individuell in Jira geschult.

Screens, Workflows, Issue Types usw. wurden an die jeweiligen Team Anforderungen angepasst bzw. erstellt. Mittels Jira Automation wurden einfache Regeln erstellt, die den Teams bei der täglichen Arbeit helfen sollten.

Als Side-Quest wurde ein PoC erstellt um eine historisch gewachsene Excel-Liste in Jira abzubilden, damit die Mitarbeitenden kollaborativ daran arbeiten können und jedes Listen Element ein eigenständiges Objekt wird (statt die komplette Excel Liste als Entität zu verwenden und damit Kolleginnen zu "blocken").

Ziele des Kunden: Der bislang in Confluence gepflege Servicekatalog sollte in Jira mit Assets als Datenbasis implementiert werden.

Auswirkung des Projekts: Die Datenintegrität und - qualität wurde gesteigert. Service Daten konnten maschinell eingelesen werden, was anderen Projekten und vor allem technischen Deployments zu Gute kam. Ein Lifecycle Management sowie ein ans Unternehmen angepasster Approval Prozess konnten sauber im UI abgebildet werden.

Initial wurden alle Services und deren Bausteine zur Erbringung in eine neue Datenstruktur innerhalb Jira Assets übertragen.

In einem dedizierten Jira Project wurde dann das "UI" für das Management der Services angelegt. Services sollten nicht im wenig intuitiven Assets Backend sondern in einem Ticket bearbeitet werden.

Es wurden ScriptRunner Behaviours entwickelt, die Daten aus Assets direkt in Screens nachladen und auch wieder speichern konnten.

Ein eigens angepasster Approval Prozess wurde entwickelt und implementiert. So konnte eine Auswahl an Einzelpersonen aber auch kompletten Teams (mit der Möglichkeit, dass eine beliebige Anzahl an Personen des Teams approven können) getroffen werden, um einen Service z.B. im Lifecycle Prozess zu approven oder nicht.

Um die Approvals grafisch sichtbar zu machen, wurde mit ScriptRunner ein Custom Panel in die Ticketansicht gebaut auf dem zu erkennen war, wer bereits approved hat und wieviele sowie welche Approvals noch fehlen (in der Optik eines Ampelsystems).

Ein REST Endpoint wurde erstellt um Services programmatisch verfügbar zu machen. Dies wurde u.A. im HTTP Provider von Terraform benutzt, um Deployments für Monitoring und Billing zu taggen.