Strategische Weiterentwicklung von Coscine
Das Coscine Entwicklungsteam folgt den Prinzipien und Praktiken von Scrum, um effektiv an der Aufrechterhaltung und Weiterentwicklung von Coscine zu arbeiten. Das Team besteht aus verschiedenen Rollen wie Product Owner*in, der/die für die Priorisierung des Product Backlogs verantwortlich ist, Scrum Master*in, die/der den Prozess unterstützt und Hindernisse beseitigt, sowie den Entwickler*innen, die die Tickets (sogenannte Issues) umsetzen. Wie bei jedem Scrum Team werden die Sprints geplant, tägliche Stand-ups gehalten und regelmäßige Reviews und Retrospektiven durchgeführt, um kontinuierliche Verbesserungen zu gewährleisten. Die Issues, welche in den zweiwöchigen Sprints bearbeitet werden, werden durch den/die Product Owner*in ausgewählt. Ein entscheidender Anteil der Issues ist Teil von größeren geplanten strategischen Weiterentwicklungen, den sogenannten Epics. Anforderungen für Verbesserungen werden durch das Service Management z.B. in Form von Service-Anfragen via E-Mail oder bei der monatlichen Sprechstunde für den 1st-Level-Support aufgenommen. Darüber hinaus können Verbesserungswünsche auch direkt vom Scrum Team oder vom Service Management Team in den Prozess einfließen.
Abbildung 1 zeigt den Prozess der strategischen Weiterentwicklung von Coscine in vereinfachter Form.
Epics
Zur Verwaltung neuer strategischer Weiterentwicklungen von Coscine verwenden wir Epics. In Scrum sind Epics große, übergeordnete Benutzeranforderungen oder Funktionalitäten für eine Software, die in kleinere, handhabbare Teile (User Stories / Issues) unterteilt werden können und mehrere Sprints zur Entwicklung in Anspruch nehmen. Um einen guten Überblick und eine FAIRe Entwicklung für unsere Stakeholder zu gewährleisten, handhaben wir Coscine-Epics in einem transparenten Prozess, der auf Elemente des Scaled Agile Framework (SAFe) zurückgreift. Für das Projektmanagement der strategischen Entwicklung verwenden wir den Bereich der Epics in unserem Coscine-GitLab.
Epic Lifecycle
Es gibt sechs offizielle Phasen, die ein Epic durchläuft. Diese sind auf dem Coscine SAFe EPIC Board sichtbar. Jedes Epic ist mit einem GitLab-Label gekennzeichnet, das die aktuelle Stufe im Lifecycle anzeigt. Für jedes Epic muss ein vordefiniertes Epic Template ausgefüllt werden. Die Verwendung des Templates ist verpflichtend und gewährleistet eine gleichbleibende Qualität hinsichtlich der Informationstiefe. Am Anfang der Vorlage wird der Status des Epics gekennzeichnet. Dies geschieht je nach Phase durch den/die Epic-Initiator*in, den/die Epic-Owner*in oder den/die SAFe-Koordinator*in. Eine Beschreibung der einzelnen Rollen findet sich im Folgenden.
| Wer? | Was? | Wie? |
|---|---|---|
| Epic Initiator*in | Erstellt Epic | Verwendung des Epic Template und Ausfüllen der Punkte von Description bis Nonfunctional Requirements |
| Wer? | Was? | Wie? |
|---|---|---|
| Epic-Initiator*in | Informiert SAFE-Koordinator*in über den Abschluss des Reviews | Status des Epics auf Bereit zum Review und Label EPIC:Ready for Review |
| SAFE-Koordinator*in | Lädt zum Steering Board Meeting ein | Per E-Mail an alle Teilnehmenden |
| Epic Initiator*in | Stellt das Epic im Steering Board Meeting vor | Max. 5 Minuten, Fokus auf "Elevator Pitch", Folien nicht nötig |
| Steering Board Teilnehmende | Abstimmung und Entscheidung über das EPIC | - Epic kommt ins _Analyse Backlog_ (Stimmenzahl größer oder gleich 3, siehe Abstimmungen) - Epic muss überarbeitet werden --> bleibt im Review; Label EPIC:Ready for Reviewwird entfernt - Epic wird zurück nach Open verschoben (Label geändert) |
| Wer? | Was? | Wie? |
|---|---|---|
| Steering Board Teilnehmende | Bewertet die Priorisierung aller Epics im _Analyzing Backlog_ |
Die Reihenfolge wird mit Labels und der Position auf dem Board (oben = höchste Priorität) markiert |
| Wer? | Was? | Wie? |
|---|---|---|
| Product Owner*in | Bestimmt die Person für die Rolle "Epic Owner*in" und zieht das nächste Epic in _Analyzing_ sobald genügend Kapazität für die Anaylse bei der entsprechenden Person vorhanden ist |
Epic Owner*in analysiert gemeinsam mit dem Coscine-Entwicklungsteam das Epic und erstellt die zugehörigen Issues |
| Wer? | Was? | Wie? |
|---|---|---|
| Product Owner*in | Verschiebt das Epic von _Analyzing_ nach _In Progress_, sobald genügend Entwicklungskapazität vorhanden ist |
Das Epic und alle damit verbundenen Themen werden entwickelt und umgesetzt |
| Wer? | Was? | Wie? |
|---|---|---|
| Epic Owner*in | Stellt den Abschluss im Steering Board Meeting vor | Kurze Präsentation der Ergebnisse |
| SAFE-Koordinator*in | Abschluss des Epics | Schließen des Epics auf dem Board |
Relevante Rollen
| Wer? | Was? | Wie? |
|---|---|---|
| Eine Person aus der Coscine-Gruppe | Planung, Bereitstellung und Überwachung von Dienstleistungen, um sicherzustellen, dass die Bedürfnisse der Kunden erfüllt und gleichzeitig effizient und kostengünstig betrieben werden | Überwachung der wichtigen KPIs, Austausch mit relevanten Stakeholdern |
| Wer? | Was? | Wie? |
|---|---|---|
| Eine Person aus dem Coscine-Entwicklungsteam | Koordiniert die Scrum-Entwicklung und die nächsten Sprints | - Übernimmt Epic ab Analyzing Backlog und plant Analyse & Umsetzung - Koordiniert die Entwicklung von Epic-bezogenen Issues: ca. 50% Epic-Issues & 50% kleinere Änderungen und Wartungsaufgaben pro Sprint - Informiert SAFe-Koordinator*in und das Steering Board, wenn für ein Epic relevante Issues aufgrund von dringenden Fehlern/Wartungsfragen verschoben werden müssen |
| Wer? | Was? | Wie? |
|---|---|---|
| Eine Person aus der Coscine-Gruppe | Koordiniert den Ablauf der Epics & moderiert das Steering Board Meeting | - Überwachung des SAFe Epic Boards - Aktualisieren des Status von Epics - Verschiebt Epics bis zum Analysing Backlog - Ergänzt Labels zu den Epics (Stufe, Priorisierung, Stakeholder etc.) - Planung, Vorbereitung & Moderation des Steering Board Meetings - Entscheidet über die nächsten Epics - Lädt Epic-Initiatoren/Owner ein - Bereitet die Abstimmungen vor - Koordiniert die Prioritätensetzung - Behält die Zeit im Auge (z. B. verschiebt lange Diskussionen auf separate Sitzungen) |
| Wer? | Was? | Wie? |
|---|---|---|
| Jede(r) aus der RPDM-Abteilung am IT Center der RWTH Aachen University (Kann von einem externen Stakeholder beauftragt werden) | Initiiert eine neue strategische Entwicklung | - Füllt das Epic Template aus - Informiert SAFe-Koordinator*in - Stellt die Idee im Steering Board Meeting vor - Informiert Epic Owner*in und übergibt das Epic für die Analyse |
| Wer? | Was? | Wie? |
|---|---|---|
| Person aus dem Coscine-Entwicklungsteam | Analysiert das Epic und bereitet die Umsetzung vor | - Informiert Product Owner*in bei Fertigstellung/Änderungen etc. - Präsentiert nach Abschluss des Epics die Ergbnisse im Steering Board Meeting |
| Wer? | Was? | Wie? |
|---|---|---|
| Person aus dem Coscine-Entwicklungsteam | Unterstützt das Team bei der Einhaltung der Scrum-Prinzipien | - Organisiert Scrum-Meetings und moderieret die Retrospektive - Fördert offene Kommunikation und kontinuierliche Verbesserung |
| Wer? | Was? | Wie? |
|---|---|---|
| Product Owner*in, Scrum Master*in, Entwickler*innen aus dem Coscine-Team | Selbstorganisiertes und interdisziplinäres Team, welches nach Scrum-Framework arbeitet | - Planung (2-wöchige Sprints) - Review (Vorstellung der Ergebnisse des letzten Sprints für die Stakeholder) - Retrospektive (Refelxion der Zusammenarbeit und Prozesse im letzten Sprint) |
| Wer? | Was? | Wie? |
|---|---|---|
| Product Owner*in, Service Manager*in, Scrum Master*in, RPDM-Gruppenleitende, RPDM-Abteilungsleitung, optional: für das Epic relevante Stakeholder als Gast | - Go-/No-Go-Entscheidung über neue Entwicklungen & Prioritätensetzung - Stellt Fragen zu den strategischen Zielen von Epics - Fokus auf Übereinstimmung mit der langfristigen Coscine-Strategie - Abstimmung über Epics und deren Priorisierung - Steering Board Mitglieder können ein Epic durch niedrige Stimmenzahl blockieren (mit Erklärung des Votums) - Steering Board Mitglieder können eine Runde in der Bewertung überspringen (bei nicht ausreichender Expertise) |
Treffen im Rahmen des Steering Board Meetings (Spontantreffen spätestens zwei Wochen, bevor das nächste Epic in die Analyse gehen soll) |
Abstimmungen
Jedes Steering-Board-Mitglied stimmt auf der Grundlage der "fist of five" mit einer der folgenden Zahlen für die Verschiebung vom _Review_ zum _Analyzing Backlog_ ab:
0 = Auf keinen Fall! Das wird nicht funktionieren. Ich bin nicht an Board.
1 = Ich sehe GROßE Probleme, die wir lösen müssen.
2 = Ich sehe Moderate Probleme, die wir jetzt lösen müssen.
3 = Ich sehe kleinere Probleme, die wir später lösen können.
4 = Ich finde den Plan gut, so wie er ist.
5 = Ich liebe ihn! Ich werde ihn unterstützen. Der beste Plan aller Zeiten.
Priorisierung
Die _Analyzing Backlog_ Priorisierung erfolgt in einer Excel-Tabelle. Für die Backlog-Priorisierung einigen sich die Steering Board Teilnehmenden jeweils per Teil der Priorisierungsformel (User-Business value + Time Criticality + Risk Reduction) auf eine der Bewertungszahlen: 1, 2, 3, 5, 8, 13, 20.
Die RPDM-Abteilungsleitung kann sich dafür entscheiden, das Ergebnis mit einer strategischen Anpassung zu multiplizieren (Strategischer Faktor 0,8, 1 oder 1,5).