Frankfurter Entwicklertag 2018, Frankfurt am Main: Vortrag von Michael Rohleder (@Rohleder10, Bereichsleiter bei QAware) Abstract: Agile Vorgehensmodelle funktionieren weitgehend reibungslos für kleine IT-Projekte. Eine Herausforderung stellen agile Großprojekte dar, vor allem dann, wenn der Auftragnehmer ein agiles Festpreisgewerk verantwortet und die Schnittstellenpartner im Projektumfeld noch nicht auf agil getrimmt sind. Der Vortrag beschreibt u.a. folgende Erfolgsfaktoren für solche Projekte: 1. Mut zur Planung trotz Agilität, im Idealfall auf den Planungsebenen Sprint, Release, Roadmap und Produktvision 2. Frontrunning, Mini-Specs und Definition of Ready (DOR), um die Baubarkeit von User Stories im Sprint sicherzustellen 3. Effiziente Meeting-Strukturen und unterbrechungsarmes Arbeiten, um die Produktivität im Team sicherzustellen 4. Einen Gegenpol zur Feature-Gier etablieren, um Qualitätsschulden zu vermeiden 5. Open-Source-Software professionell als Software-OEM einsetzen, um schnell in der Entwicklung zu sein 6. Testautomatisierung zur Qualitätssicherung einsetzen, auch für Akzeptanztests, um Produktqualität sicherzustellen 7. Dem Projektteam das Mandat zu Lösung geben und Projekterfolge feiern Klassische agile Vorgehensweisen wie Scrum liefern keine angemessene Antwort auf die Frage, wie man in Großprojekten agil sein kann. Die Kernkritik in manch agilem Abgesang dieser Tage ist, dass die klassischen agilen Vorgehensmodelle die Dinge über-simplifizieren, also unterhalb der für viele Projekte notwendigen Komplexität ansetzen. Ein paar Kniffe muss man sich also überlegen, um die Erfolgsrezepte von agilen Vorgehensweisen übertragen zu können auf große und komplexe Projektorganisationen. Genau diese Kniffe soll dieser Vortrag liefern.

1. Michael Rohleder
michael.rohleder@qaware.de
@Rohleder10
Agil zum Ziel: Erfolgsfaktoren
für agile IT-Großprojekte
Frankfurt, 21. Februar 2018

2. Unsere Erfahrungen stammen aus langlaufenden agilen
IT-Großprojekten bei unseren Kunden.
QAware 2
Teamgröße > 25 in Spitze
(Entwicklung + Konzeption)
Gesamt-Programm
> 150 Mitarbeiter
Umfeld / Schnittstellenpartner
noch nicht auf agil umgestellt
Agiles Festpreisgewerk
(pro Jahr / pro Quartal)
Entwicklung über
mehrere Jahre

3. Ein Fallstrick in agilen Projekten: Fehlende Sichtweite
bei der Planung.
QAware 3
Sprint 1 Sprint 2 Sprint 3 Sprint …
…? …? …?
User Stories pro Sprint:

4. Planungsebenen oberhalb des Sprints sind essenziell für
den langfristigen Projekterfolg in Großprojekten.
QAware 4
Sprint Sprint SprintSprint Sprint
Release Release Release
Jahresumfang Jahresumfang
ProjektProduktvision
Jahres-Roadmap
Sprint-Plan
(Teamplan, Aufgaben)
Release-Plan
Jahre
12 Monate
3-4 Monate
2-5 Wochen
Konkretisierung
Sichtweite
Sprint
Continuous Planning

5. Der Weg vom fachlichen Problem zur technischen
Lösung ist für komplexe Systeme lang und steinig.
QAware 5
„Als Servicemitarbeiter möchte ich
die Servicehistorie für ein Fahrzeug
einsehen können um einen besseren
Kundenservice bei der
Kundenberatung bieten zu können“
Akzeptanzkriterien:
• …
User Story
Lösung /
Umsetzung?

6. Frontrunner-Teams machen auf zwei zeitlichen Ebenen
den Weg für das Entwickler-Team frei.
QAware 6
Exploration
Konzeption
Realisierung
Sprint 2 Sprint 3 …
Release
Klärung Fachlichkeit.
Erstellung grobes Lösungskonzept.
Prüfung technische Machbarkeit
über Proof of Concepts.
Abstimmung mit
Schnittstellenpartnern.
Release - 1
Konzeption
Realisierung
Sprint 1
Empfehlung:
Frontrunner sollten die Umsetzung eng
begleiten, oder sogar selbst tun.

7. Die Mini-Spec erfüllt die Definition of Ready und
ermöglicht einen reibungslosen Start der Entwicklung.
QAware 7
Mini-Spec
Beispiele für mögliche Inhalte:
Funktionale Anforderungen
Nicht-funktionale Anforderungen
Akzeptanzkriterien
Anwendungsarchitektur
Mockups
Schnittstellensysteme
Fehlerbehandlung
PO
IT/Architekt DevOps / Betrieb
Dev

8. QAware 8

9. Erarbeiten von Lösungen in Kleingruppen
Daily timeboxed im gesamten Team Flexible Sprintdauer im Release
Meetings ohne Augenmaß sind Zeitfresser im agilen
Vorgehen.
QAware 9
S2 S6S4S3 S5 S7S12 wöchig
2-5 wöchig
vs.
Nur relevante Vertreter des Projekts für
Backlog-Grooming
Sprint-Planning
Sprint Review
Definition of Done
Release Retrospektive
S2 S4S3S1

10. Entwicklungskosten
+ Qualitätsschulden
= Arbeitszeit
x Arbeitszeit-Kosten

11. Gegenpol zur Feature-Gier des Product-Owners
aufbauen um Qualitätsschulden zu vermeiden.
QAware 11
Systeme benötigen Phasen, in denen vermindert neue Features entwickelt und das System gehärtet wird.
Lösungen:
Qualitäts-Backlog mit ca. 20% der Sprint-Kapazität.
Härtungs-Sprints.
Bug Hunting Days / Quality Days.
Vertraglich vereinbarter Qualitätskontrakt auf Basis
messbarer KPIs.
Umfassende Definition of Done, zu der auch der
Qualitätskontrakt gehört.
Foto: QAware Quality Day

12. Omnipräsenz von Kennzahlen zur Produktqualität trägt
maßgeblich zur Softwarequalität und Produktivität bei.
QAware 12

13. Wie groß ist die Fertigungstiefe
in Ihrem Projekt?
Fertigungstiefe := Anteil selbst geschriebener Code zu Code aus
verwendeten Open Source Komponenten

14. Maximale Geschwindigkeit in der Entwicklung durch den
Software-OEM Ansatz.
QAware 14
Software-OEM bedeutet: Software mit geringer Fertigungstiefe auf Basis von Open-Source-Komponenten
entwickeln.
Der Umgang mit Open Source muss professionell erfolgen, folgende Fragen muss man sich stellen:
… bei der Integration und Pflege:… bei der Recherche und Auswahl:
Enge Bindung oder lose Kopplung?
Ist der Nachweis der Compliance vollständig?
Sind die Lizenztexte lizenzgemäß hinterlegt?
Sollte auf eine aktuellere Version migriert werden?
…
Ist ein Open-Source-Baustein notwendig?
Ist eine Blueprint-Freigabe möglich?
Fordert die Lizenz Inakzeptables?
Gibt es bekannte Sicherheitsprobleme?
…

15. QAware 15
Erfolgsfaktor: Testautomatisierung

16. Große agile Projekte benötigen für eine hohe
Produktqualität automatisierte Tests auf allen Ebenen.
QAware 16
UI-
Tests
Typischerweise guteTestautomatisierung
auf den unteren Ebenen mit allenVorteilen.
PostulierteAusführungskosten
AnzahlTests
Akzeptanz-Tests
Exploratives manuelles Testen
Automatisches Testen
Testautomatisierung auf diesen Ebenen:
sehr gut geeignet für Regressionstests und
reduziert Aufwände für manuelles Testen.
entbindet nicht von der Pflicht für
manuelles explorativesTesten.
Integrations-Tests
Unit-Tests

17. QAware 17

18. Firmengrenzen sind in der Teamzusammenarbeit absolut
sekundär. Was zählt ist der gemeinsame Projekterfolg.
QAware 18
Retrospektive
„Inspect and adapt“
Konstruktive Lösungsfindung,
Mut zur offenen Reibung
Politics
Enge Zusammenarbeit,
Partnerschaft,
nah am Auftraggeber (Co-Location)
Erfolge gemeinsam feiern
Team
Experts

19. Michael Rohleder
michael.rohleder@qaware.de
@Rohleder10 github.com/qaware
linkedin.com/qaware slideshare.net/qaware
twitter.com/qaware xing.com/qaware

20. Zusammenfassung
QAware 20
Mut zur Planung trotz Agilität, im Idealfall auf den Planungsebenen Sprint, Release, Roadmap und
Produktvision.
Frontrunning, MiniSpecs und Definition of Ready (DOR), um die Baubarkeit von User Stories im Sprint
sicherzustellen.
Effiziente Meeting-Strukturen und unterbrechungsarmes Arbeiten, um die Produktivität im Team
sicherzustellen.
Einen Gegenpol zur Feature-Gier etablieren, um Qualitätsschulden zu vermeiden.
Open Source Software professionell als Software-OEM einsetzen, um schnell in der Entwicklung zu sein.
Testautomatisierung zur Qualitätssicherung einsetzen, auch für Akzeptanztest, um Produktqualität
sicherzustellen.
Dem Projektteam das Mandat zu Lösung geben und Projekterfolge feiern.