| Nr. |
Aufgabe |
Kurzbeschreibung |
| 1 |
Design Thinking durchführen |
Mit seiner offenen, kreativen aber gleichzeitig systematischen Herangehensweise bietet
Design Thinking ein strukturiertes Vorgehensmodell für unterschiedliche Fragestellungen und Problembereiche. Die Design Thinking Methode durchläuft interativ folgende Schritte:
Verstehen – Das Problem definieren
Beobachten – Kundenbedürfnisse verstehen
Standpunkt definieren – Was haben wir gelernt?
Ideen entwickeln – Lösungen skizzieren und priorisieren Prototyping – Modellierung der besten Ideen
Testen – Was sagt der Kunde? |
| 2 |
Produkt Vision Workshop durchführen |
In der Sichtweise der Projektdurchführung beinhaltet die erste Frage die Ausformulierung und Konkretisierung der Projektidee sowie das Verfassen der Produkt Vision. (MS10). |
| 3 |
Scope festlegen |
Bei der Definition des Projekt-Scopes, insbesondere des System-Scopes, geht es um eine inhaltliche Abgrenzung des Vorhabens (was ist "In Scope", was "Out of Scope"?). Dies geschieht unter Anleitung des designierten Product Owners in folgenden Schritten:
Produktbezogene Einflussgrössen und Schnittstellen werden bestimmt
Produktziele werden messbar und quantifizierbar formuliert
Die Rahmenbedingungen und Restriktionen, welche als Einflussgrösse auf das Projekt
eine entsprechende Wirkung verursachen ermitteln und festhalten. |
| 4 |
Story Map definieren sowie Epics & User Stories aufnehmen |
Die Projektvision wird konkretisiert und entsprechende Lösungsansätze werden gesucht
Daran abgeleitet wird eine Impact Map und eine Story Map grob abgeleitet.
Basierend der Story Map werden die Epics und User Stories abgeleitet.
Die User Stories und Epics werden mit den Stakeholdern gespiegelt und im Product
Backlog festgehalten |
| 5 |
Product Backlog Erstpriorisierung |
Wurden die Epics und User Stories erfasst gilt es dies in der Tiefe aus Business Sicht entsprechend zu spezifizieren.
Pro User Stories wird der Business Value definiert
Pro User Stories werden Akzeptanzkriterien definiert
Der gesamte Product Backlog wird vom Product Owner als Grundlage für den
Releaseplan priorisiert |
| 6 |
Estimation Meeting |
Der Product Owner, der Kunde, das Team und der Agil Master schätzen an einem Estimation Meeting die User Stories.
SCRUM-Vereinbarungen treffen: Sprintdauer, Definition „Done“, Besetzung der Rollen, etc. IT-Security und Betriebsaspekte klären.
Soweit wie möglich businessbezogene Unklarheiten beseitigen
Soweit möglich strukturelle Logik des Backlogs prüfen
Erste grobe Schätzung vornehmen, dass ein grober Releaseplan erstellt werden kann
Vorbereitungen für Sprint Planning vornehmen
Aufgrund der Priorisierung werden vom Scrum-Team die für den nächsten anstehenden Sprint (2-4 Wochen) die umzusetzenden User Stories bzw. Ergebnisse definiert. |
| 11 |
Produkt Workshop / Konfiguration |
In einem oder sogar mehreren Projektkonfigurationsworkshops wird festgelegt, welche
Vorbedingungen (z.B. Architektur, Konfiguration etc.) vorhanden sein müssen, damit die Sprints möglichst effizient durchgeführt werden können. Allenfalls wird hier auch entschieden, dass man nicht alle Tätigkeiten agil umsetzen kann und deshalb auf ein hybrides Modell wechselt.
Proof of Concept
Bei erhöhten Sicherheitsbedarf gilt es Informationssicherheits- und Datenschutzkonzept
(ISDS-Konzept) erstellen
Test- und Integrationsstrategie festlegen
Projektinfrastruktur respektive Entwicklungsumgebung aufbauen |
| 12 |
Sprint Planen (Planning Meeting 1 und 2) |
Basierend auf dem Product Backlog und aufgrund der Priorisierung werden die für die nächste anstehende Iteration (Sprint) umzusetzenden User Stories bzw. Ergebnisse definiert. Dazu gehören die saubere Sprint-Planung.
Im Sprint Planning Meeting (Teil 1) stellt der Product Owner die User Stories vor. Zusammen mit dem Team wird das Ziel und der Inhalt «WASdes nächsten Sprints bestimmt. In diesem Schritt wird auch über die qualitative Beschreibung der User Stories mittels dem DoR-Prinzip entschieden.
Im Sprint Planning Meeting (Teil 2) erarbeitet das Team gemeinsam die für die Erreichung der Sprintziele notwendigen Tätigkeiten und koordinieren die notwendige Architektur und/oder das Design (WIE). Dabei werden die User Stories in einzelne Tasks heruntergebrochen und als Backlog Tasks festgehalten.
In der Folge läuft jede User Stories, welche in Tasks unterteilt wurden, die Arbeitsschritte 13 – 16 in einem iterativen Prozess ab. Bis das gesamte geplante Inkrement erstellt wurde. |
| 13 |
Analysieren & Spezifizieren |
User Stories müssen bezüglich deren Anforderungen in diesem Arbeitsschritt so spezifiziert werden, dass anschliessend ein lückenloses Verständnis beim Entwickler oder Entwicklungsteams vorliegt. Wie wird im Detail nun die Anforderung respektive Stories umgesetzt, so dass die definierten Akzeptanzkriterien erfüllt werden können. |
| 14 |
Architektur anpassen |
Basierend auf den Anforderungen der neuen User Stories wird die Systemarchitektur
geprüft und allenfalls angepasst, Zusätzlich werden - sofern nicht vorhanden - Architektur- Entscheidungen, Design-Regeln und Umsetzungsrichtlinien definiert oder angepasst. |
| 15 |
Inkrement / Produkt erstellen |
Während einem Sprint wird das System auf Grundlage der vorgegebenen Architektur und der für diesen Sprint ausgewählten User Stories gebaut. In jedem Sprint werden die definierten Anforderungen so umgesetzt, dass dieser End-To-End (GUI bis Datenbank) überprüft werden kann. |
| 16 |
Inkrement testen |
Gleichzeitig zur Entwicklung wird das Inkrement laufend getestet, so dass am Ende jedes Sprints ein fertiges Stück der benötigten Software bereit steht. |
| 17 |
Sprint Review |
Nach dem Realisieren und allfälligen Anpassen wird das erstellte Projektprodukt anhand der User Stories verifiziert und auf seine zielbezogene und fehlerfreie Anwendbarkeit geprüft (Validation).
Die Ergebnisse des Sprints werden dem Product Owinder und allen interessierten Stakeholdern live am System präsentieren. Dieser nimmt die umgesetzten User Stories in Form des DoD-Prinzips ab.
Verbesserungsvorschläge, Lob und Kritik werden entgegen genommen und allenfalls werden neue Task und User Stories für das Product Backlog definiert. |
| 18 |
Retrospektive |
Beim/nach Abschluss eines Sprints, führt das Entwicklungsteam unter der Leitung des Scrum Master eine „Retrospective“ durch: Das heisst, es macht ein Lessons-learned- Meeting (pro Sprint), mit dem Ziel, das Gelernte sofort für die kommenden Sprints zu verwenden.
Im Rahmen der Retrospektive werden diejenigen Punkte im Impediment Backlog aufgenommen, welche das Team daran hindern maximal effizient zu sein. |
| 19 |
Backlog Grooming |
Das Backlog Grooming oder auch Backlog Refinement genannt ist ein Tref-fen des
Entwicklungsteams mit dem Product Owner, in welchem sie die Product Backlog Items diskutieren und das nächste Sprint Planning vorberei-ten. Das heisst, es geht darum zu klären ob das Backlog Item klar genug formuliert und tief genug aufgesplittet (lässt es ihr Umfang zu) sind, um sie zu schätzen und innerhalb eines Sprints zu implementieren?
Aufnahme von neuen User Storys, Features und Epics in das Backlog
Verfeinerung von vorhandenen Epics, Features und User Storys und gegebenenfalls
Aufteilung in mehrere kleine Backlog Items Zusammenfassen von User Storys |
| 21 |
Integrations- & Systemtests durchführen |
Beim Integrations- & Systemtest wird das erstellte Inkremente mit dem gesamten System gegen die gesamten Anforderungen (funktionale und nicht funktionale Anforderungen) getestet.
Last- & Performancetest Mobile Tests
Etc. |
| 22 |
Produkt ausliefern |
Die realisierte Lösung wird in das reale Umfeld integriert und ihre optimale Handhabung sichergestellt. Evtl. muss eine Schulung durchgeführt werden. Die Verantwortlichkeiten werden endgültig geregelt bzw. übergeben.
Einführungsplan erstellen
Bereitschaft für Inbetriebnahme/Ausbreitung erstellen Produkt/Inkrement in Betrieb setzen
Definitive Freigabe |
