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 info@bfischer-consulting.de