Water-Scrum-Fall Ein Entwicklungsprozess mit Zukunft?
Bernhard Fischer
Wasserfall vs. Agile: Eine Erfolgsstory
ScrumMed 2013 – 19.02.2013 2
Umsetzung agiler Prinzipien
35.4%
20.6%
30.6%
13.4%
Entwicklungsprozess 2009
Agil
Iterativ
Kein Prozess
Traditionell
Basis: Forrester, 2010
ScrumMed 2013 – 19.02.2013 3
Sprint 1-4 Wochen
Standup Meeting – alle 24 Stunden
In Aufgaben heruntergebrochen
Product Backlog
Sprint Backlog
Potentiell auslieferbares Produkt-Inkrement
SCRUM
ScrumMed 2013 – 19.02.2013 4
• Probleme Projektmanagement: Entwicklungsprojekte können zu Projektbeginn detailliert geplant werden.
• Probleme im Anforderungsmanagement: Anforderungen können und sollen zu Projekt-beginn vollständig erhoben werden
• Probleme bei der Entwicklung und dem Messen des Entwicklungsfortschritts: Phasenweise Entwicklung bereitet Probleme beim Messen des Entwicklungs-fortschritts
• ...
Gründe für den Einsatz agiler Methoden
ScrumMed 2013 – 19.02.2013 5
• Agile Vorgehen wird als Sammlung isolierter
Methoden betrachtet, die konkrete Probleme lösen
• Agile Methoden sollen nur isolierte Schwachstellen
beseitigen, damit werden nur Symptome gelindert
• Agile Methoden werden daher häufig in traditionelle
wasserfallartige Vorgehensmodelle eingearbeitet
• Angst für eine nicht regulatorisch konformen Lösung
schreckt ab
Und das Ergebnis?
ScrumMed 2013 – 19.02.2013 6
• Aus Business Analysten werden Product Owner
• Teammitglieder arbeiten an mehr als einem Projekt
• Team werden nach Projektende auseinandergerissen
• Die Scrum-Rollen werden nicht besetzt
• Done- und Ready-Kriterien für Stories werden nicht
berücksichtigt
• Der Prozess / QM fordert sinnlose Dokumente
... und wir sehen nur ScrumButs ...(1)
ScrumMed 2013 – 19.02.2013 7
Nutzungs-anforderungen
System-anforderungen
Architektur
Design
Implementierung
Validerung / Abnahmetest
System-Test
Integration-Test
Modul-Test
Das V-Modell
Nutzungs-anforderungen
System-anforderungen
Architektur
Validerung / Abnahmetest
System-Test
Integration-Test
Iterative-inkremente Entwicklung
Wasserfallmodell mit agilen Aspekten
ScrumMed 2013 – 19.02.2013 9
• Nutzungsanforderungen werden nicht systematisch erhoben
• Einbeziehen von Anwendern in die Entwicklung erfolgt nicht
• Systemanforderungen werden unnötig detailliert erhoben und dokumentiert
• Die Architektur wird nicht vom Team festgelegt, ist aber festgeschrieben
• Das Entwicklungsteam ist nicht an der Erstellung der Anforderungen beteiligt
Anforderungen u. Architektur im V-Model
ScrumMed 2013 – 19.02.2013 10
• Das Entwicklungsteam ist nicht funktions-übergreifend besetzt, insbesondere fehlen Tester im Team
• Die Entwickler arbeiten nicht als Team und das Entwicklungsteam ist nicht selbst-organisierend
• Scrum-Rollen werden nicht besetzt oder die Rollen sind nicht befähigt
• Mikro-Management, kein Vertrauen in das Team
• Überflüssige Dokumentation und unzureichende Dokumentation
Iterative Entwicklung im unteren V
ScrumMed 2013 – 19.02.2013 11
• Inkremente erfüllen nicht die Done-Kriterien, oder es werden gar keine Done-Kriterien definiert
• Fehler, die im V&V festgestellt werden führen zu Verzögerungen
• Die Entwicklung dauert länger / ist teurer als erwartet.
• Technische Schulden machen Änderungen teuer / schwieriger
Verifizierung und Validierung im V-Modell
ScrumMed 2013 – 19.02.2013 12
Verschenkte Chancen!
Gesamtergebnis:
ScrumMed 2013 – 19.02.2013 13
• Sie können die Vorteile inkrementellen und iterativen Vorgehens konkret belegen.
• Sie haben bewiesen, das der Fokus auf lauffähige Software tragfähig ist
• Sie haben gezeigt, das es sinnvoll die Entwicklung ist die Hände eines entsprechend besetzen Entwicklungsteams zu legen
• Sie haben konkret gezeigt das die Entwicklung medizinischer Software mit agilen Methiden möglich ist!
Was können wir daraus machen?
ScrumMed 2013 – 19.02.2013 14
Nutzen Sie die bisherigen Erfahrungen mit agilen Methoden um bei der Umsetzen eines agilen Vorgehensmodell weiterzukommen!
Konsequenz
ScrumMed 2013 – 19.02.2013 15
• Entwicklung als empirischer Prozess
• Iterative und inkrementelle Entwicklung
• Größen-Schätzungen durch das Team
• Zweistufige Schätzung (Release vs. Iteration)
• Fokus auf Ergebnissen: Überprüfung der Fertigstellung nach jeder Iteration
• Fokus auf Nützlichkeit : Orientierung an der Fertigstellung von Teilfunktionalitäten
Agiles Projektmanagement
ScrumMed 2013 – 19.02.2013 16
• Einbeziehung von Kunden und Anwendern über die gesamte Projektlaufzeit hinweg
• Regelmäßiges Feedback über die erstellten Produktinkremente einholen
• Formulierung der Systemfunktionalität aus Kundensicht unter Berücksichtigung der Nutzungsanforderungen
• Priorisierung der Anforderungen nach Kundenwert
• Unterschiedliche Granularität der Anforderungen und Detaillierung nach Notwendigkeit
Agiles Requirement Engineering
ScrumMed 2013 – 19.02.2013 17
• Iterative und inkrementelle Entwicklung
• Definition Done-Kriterien und Überprüfung der Artefakte auf Einhaltung der Done-Kriterien
• Fokussierung auf die Fertigstellung von Teilfunktionalitäten
• TDD auf Anforderungsebene und Codebene
• Inkrementelles Design
• Testen ist in die Entwicklung integriert
• Funktionsübergreifend besetztes Team
Agiles Entwickeln und Testen
ScrumMed 2013 – 19.02.2013 18
Vom Design-Input zum Design-Output
Design-Input Aktivitäten
Design-Output Aktivitäten
ScrumMed 2013 – 18.02.2013 19
Aufbrechen der Input und Output Aktivitäten
Design
Input
Aktivitäten
Design
Output
Aktivitäten
Design
Input
Aktivitäten
Design
Output
Aktivitäten
Design
Input
Aktivitäten
Design
Output
Aktivitäten
Design
Input
Aktivitäten
Design
Output
Aktivitäten
Design
Input
Aktivitäten
Design
Output
Aktivitäten
Design
Input
Aktivitäten
Design
Output
Aktivitäten
ScrumMed 2013 – 18.02.2013 20
Entwicklung auf dem Story/Item-Level
c
5.1 Planung – der einzelnen Story
5.2 Requirements – Ermittlung der Story Details
5.3 Architektur – Emergent bei der Entwicklung
5.4 Design – inkrementell und iterativ
5.5 Implementierung und Verifikation der SW-Einheiten(n)
5.6 SW-Integration und Integrationstest
5.7 Systemtest
Für jede Story
ScrumMed 2013 – 18.02.2013 21
Für jede Iteration / jedes Inkrement
Entwicklung auf dem Iterations-Level
5.1 Planung 5.2 Requirements
5.3 Architektur 5.4 Design
5.5 Implementierung 5.6 Integrationstest
5.7 Systemtest Für jede Story
5.6 Integration
& Test
5.7 System
Test
ScrumMed 2013 – 18.02.2013 22
Ablauf einer Iteration: Beispiel
Sprint Backlog erstellen
User Stories des Spiint Backlogs präzisiert
Risikoanalyse aktualisiert
SW-Architektur / Design aktualisieren
Detailliertes Design erstellt / aktualisiert
Implementierung
Protokolle für die Verifikation der Story
Testprotokoll(e)
Anforderungen analysieren und Lösung spezifizieren
Story Test durchführen
Retrospektive Iterationsergebnisse prüfen und freigeben
Iteration beendet
Iteration beginnt
Testspezifikation aktualisiert
Storytest spezifizieren und erstellen
Lösung entwerfen implementieren und verifizieren
Iteration planen
Für jede Story der aktuellen Iteration
Design/Code/Test- review pro Story Story Review durchführen
ScrumMed 2013 – 18.02.2013 23
Entwicklung auf dem Release-Level
Für jedes Release
5.1 Planung 5.2 Requirements
5.3 Architektur 5.4 Design
5.5 Implementierung 5.6 Integrationstest
5.7 Systemtest Für jede Story
5.1 Planung
Für jedes Inkrement
5.2 Requirements
5.3 Architektur
5.6 Integrations
test
5.7 Systemtest
5.8 Freigabe
5.6 Integrations
test
5.7 Systemtest
ScrumMed 2013 – 18.02.2013 24
Entwicklung auf dem Produkt-Level
Für jedes Release
5.1 Planung 5.2 Requirements
5.3 Architektur 5.4 Design
5.5 Implementierung 5.6 Integrationstest
5.7 Systemtest Für jede Story
5.1 Planung
Für jedes Inkrement
5.2 Requirements
5.3 Architektur
5.6 Integrations
test
5.7 Systemtest
5.8 Freigabe
5.6 Integrations
test
5.7 Systemtest
5.1 Planung
5.2 Requirements
5.3 Architektur Für das Produkt/Projekt
ScrumMed 2013 – 18.02.2013 25
• Water-Scrum-Fall kann bei der Einführung agiler Methoden ein Zwischenschritt sein, um internen Problemen zu begegnen.
• Häufig führen aber solchen Hybrid-Methoden dazu, das sdie agile Umsetzung unvollständig bleibt
• Die Einführung agiler Methoden und Techniken führt nicht zwangsläufig agilen Denken.
• „Agil“ ist nicht eine Sammlung von Methoden und Techniken, sondern ein Wertesystem. Rechnen Sie mit mehreren Jahren für die Etablierung eines Wertesystems!
Fazit
ScrumMed 2013 – 19.02.2013 26
MedConf 2012 – 25.09.2012 27
Thank you!
Fischer Consulting GmbH Bernhard Fischer
Waldstr. 106 D-44869 Bochum
www.bfischer-consulting.de [email protected]