Continuous Flow vs Timeboxes und der Effekt auf die Qualität der Ergebnisse

Transkript

1 Continuous Flow vs Timeboxes und der Effekt auf die Qualität der Ergebnisse Michael Rumpler 16:15 Conference Room 1 Lean, Agile & Scrum Konferenz 2013

2 Continuous Flow vs Timeboxes und der Effekt auf die Qualität der Ergebnisse 5 th Lean, Agile & Scrum Konferenz

3 Who am I? Michael RUMPLER > 41, Österreicher > Dipl.-Ing. Informatik TU Wien 1996 > CSM, CSPO, Kanban > Diverse Coaching & Moderationsausbildungen > Aktuell Product Owner bei KABA AG Schweiz > 15 Jahre Erfahrung im SW-Engineering und Projektleitung in Flugsicherungs- und Eisenbahnwesen > Agile Methoden seit ca > Beschäftigung mit agilen Methoden in regulierten Umfeldern (Avionik, Eisenbahnsicherungstechnik) seit

4 Qualität der Ergebnisse???? 4

5 Software-Qualität? Leider gibt es immer noch zu wenig Wissen in der klassischen Qualitätssicherung über das komplexe Thema Software Engineering ZITATE Quelle: swisseduc Qualität kommt von Quälen Qualität wird nicht gesichert, Qualität wird produziert Qualität ist ein Prozess Wer 80% anstrebt, bekommt auch nur 80% dieser 80% (das sind dann 64%) Was an Qualität gespart wird, muss an Zeit/Geld investiert werden Man kann Qualität nicht in Software hineintesten 5

6 Software-Qualität in den Normen 6

7 Software-Qualität in verschiedenen Umfeldern > Keine der Normen für safety-kritische Anwendungen referenziert eine der beiden Normen! > Die Normen sind was Methodiken und Vorgehensweisen angeht oft sehr veraltet (agile Methoden werden kaum oder gar nicht erwähnt) > Software ist gerade im Bereich Maschinenbau und ähnlichem oft ein ungeliebter Nebenschauplatz > Sehr oft wird in der modernen Software Entwicklung wesentlich mehr systematische SW-Qualitätssicherung betrieben als im safetykritischen Umfeld. Manuelle Tests dort nach wie vor 1. Wahl. > Viel Legacy Code der schwer zu warten ist sehr hohe Aufwände für Änderungen moch mehr Testaufwand > SW-Qualitätssicherungsmassnahmen sind in vielen agilen Umfeldern im Einsatz, die Indikatoren werden aber wenig zur Steuerung eingesetzt. 7

8 Software-Qualität ist nicht one for all > Viele Qualitätsmanager sehen SW-Qualität wie Produktionsqualität, es gibt einen Satz von Messgrössen anhand derer die SW-Qualität gemessen wird, die Ziele sind immer konstant > Software Qualität versteckt sich aber auch in nicht-funktionalen Anforderungen wie z.b. > Das System kann 4000 Benutzer zugleich bearbeiten > Systemumgebung? Funktionen? Randbedingungen? > Das System hat eine Verfügbarkeit von 99,999% > Welche Funktionen benötigen 99,999%? Randbedingungen? > Das System muss Eingaben mit bis zu 10GB/s verarbeiten können > Woher? Einzelne Datei oder viele Verbindungen? 8

9 Qualitäts-Stories > Oftmals ist es hilfreich Qualitätsziele als Qualitäts-Stories zu beschreiben mit den Fragestellungen > Welches Qualitätsmerkmal wird gefordert Story Titel > Kontext der Qualitätsforderung (Auslöser, Komponente, ) > Minimaler/normaler/maximaler Umfang der Anforderung > Rahmenbedingungen für die Erreichung (Systemumgebung, ) > Wodurch kann ich die Erreichung des Zieles feststellen (messbare Kenngröße) Akzeptanzkriterien SW-Qualität ist keine statische Angelegenheit die in einem QS-Plan allgemeingültig niedergeschrieben werden kann! 9

10 Methoden in der SW-Entwicklung 10

11 Wasserfall Modell Aufwand Mrs. Project Manager Mr. Boss Lieferdatum SPEC IMPLEMENT TEST Zeit 11

12 Wasserfall Modell (Realität) Aufwand Putnam Equation Lieferdatum Risiko SPEC IMPLEMENT TEST Risiko Zeit 12

13 Das magische Dreieck GUT WTF? SCRUM Mr. Boss PROJEKTUMFANG (FIX) SCHNELL GÜNSTIG 13

14 Anatomie eines Scrum Sprints TIMEBOX (FIX) PLANNING DEVELOPMENT TESTING DOCUMENTATION (DEPLOYMENT) REVIEW / RETRO Aufwand Zeit 14

15 Realität in vielen Scrum Einführungen TIMEBOX (FIX) PLANNING DEVELOPMENT TESTING DOCUMENTATION (DEPLOYMENT) REVIEW / RETRO Aufwand Zeit Mr. Boss 15

16 Realität in vielen Scrum Einführungen (Variante 1) Aufwand TIMEBOX (FIX) 1 PLANNING 2 3 TECHNISCHE SCHULD 4 5 REVIEW / RETRO 6 Zeit Mr. Boss 16

17 Realität in vielen Scrum Einführungen (Variante 2) Aufwand TIMEBOX (FIX) 1 PLANNING REVIEW / RETRO TECHNISCHE SCHULD 6 Zeit Mr. Boss 17

18 Beobachtungen bei Projekten der letzten Jahre > Viele Projekte sind immer noch Festpreisprojekte > Gefühlte Tendenz sogar wieder steigend > Wunsch nach Kostensicherheit durch Wirtschaftskrise > In vielen Wirtschaftszweigen wird nach wie vor Software-Qualität nicht ernst genommen > Abstürze sind für Benutzer normal Danke Microsoft > Bananen-Software oft an der Tagesordnung > Markt erzeugt zusätzlichen Druck > Geringere Investitionsvolumen, immer mehr Features > An schwammigen Teilen wie Software kann man leicht sparen, wird vom Kunden bestenfalls als sekundäres Qualitätsmerkmal angesehen 18

19 Probleme mit Scrum (1) > Scrum ist ein radikales Umdenken auf allen Ebenen > Management oftmals nicht bereit mitzugehen > Support seitens Management oft mangelhaft > Mindset nicht in allen Köpfen auf allen Ebenen > Oftmals größtes Problem: Auch die Kunden müssen so denken!! > Durch die oftmals falschen Hoffnungen wird zu viel Druck aufgebaut > Der J-Kurven Effekt bei der Scrum Einführung wird vergessen > Oftmals wird Scrum falsch eingeführt > Scrum in einer Matrixorganisation > Scrum mit oftmals wechselnden Teams > Ein bisschen Scrum unter einem Wasserfall-Prozess > Scrum als Allheilmittel 19

20 Probleme mit Scrum (2) > Da ein Sprint nach aussen wie ein Miniprojekt aussieht, wird vom Management oft erhöhter Druck ausgeübt > Das Commitment ist unter allen Umständen zu halten > Weil Scrum die Performance verbessert muss immer mehr in einen Sprint passen > Es entsteht oftmals eine nicht unerhebliche technische Schuld, die gegen Projektende immer dramatischere Probleme verursacht > Es wird zugunsten der Menge gelieferter Storypoints oftmals die Qualität beschnitten (Definition of Done gelockert) > Scrum ist ein sensibles Ökosystem, das oftmals durch falsches Verständnis des Mangements massiv gestört wird > Ein Großteil der traditionellen Firmen ist nicht bereit für Scrum 20

21 Wo viel Schatten, da auch Lichter SCRUM Variante Implementiert bei Thales Deutschland für RBC Development Probleme: Großprojekte, Multi-Site Development, Geringe Testautomatisierung Ergebnisse: Fehlerrate: -26%, Budgetüberzug: -37%, Terminverzug: -44% 21

22 Alternative: Kanban kombiniert mit <whatever> > Beginne wo du dich gerade befindest > Einfacheres Buy-In durch das Management > Vorgaben durch Normen, Prozesse können beibehalten werden > Erleichtert Einführung, auch in reguliertem Umfeld möglich > Kombinationsmöglichkeit mit jedem Prozess möglich > Kanban dient der Prozessoptimierung > Das Basisgerüst um Probleme zu erkennen und Anpassungen zu bewerten existiert, darüber hinaus wird keine Vorgabe gemacht > Feste Iterationen sind optional, dadurch der Effekt und Gefahr des Mini-Wasserfall nicht gegeben > Kontinuierlicher Fluss wird durch Limits sichergestellt, ist nicht von der Disziplin des Teams abhängig 22

23 Fallstudie: Avionics Software Entwicklung > Probleme aus dem klassischen Prozess > kostenintensive Safety-Aktivitäten (spät im Projekt, grosser Umfang & Komplexität) > Big Bang Integration > Zuverlässigkeit der Aktivitäten durch hohe Komplexität oft kompromittiert wird umso schlimmer je später im Projekt > Probleme aus Lieferantensicht > Ineffiziente Aktivitäten > Sehr spätes Feedback, teilweise massives Rework > Probleme aus Sicht des Kunden > Lieferung zum vereinbarten Termin nur in den seltensten Fällen > Verlust des Vertrauens (Fehlerrate, Rework) 23

24 Ursachen für Probleme > Nicht-zertifizierte Integrationsversionen früh im Prozess > Verifikation & Validierung nur mit der finalen Version > Verwendeter Prozess ist fast immer ein einphasiger V-Zyklus 24

25 Strategie > Reduktion der Cycle-Time um: > Gleichzeitig in Arbeit befindliche Arbeitsmenge reduzieren > Komplexität Stück für Stück zu meistern > Safety, Quality, Verification & Validation Aktivitäten frühzeitig und so oft wie möglich > Feedback an das Entwicklungsteam frühzeitig 25

26 Entwicklungsvorgehensweise Iterationsdauer: 1 Monat anstatt 2-4 Jahre 26

27 Komplexität managen 27

28 Vergleich Versuch Scrum, Kanban > Wahrgenommene Probleme bisher beim Management > Bis zur Integration: Meilensteine & Kosten OK (Qualität????) > Danach Kosten, Qualität und Meilensteine KO > Scrum als mit dem V-Modell in Konflikt stehenden Prozess durch Management und Behörden als sehr problematisch letztlich abgelehnt > Kanban wurde als Prozessoptimierungstool eingeführt > Durch die Kanban Vorgehensweise wurde das Vorgehen nach und nach agiler (Probleme mit CMMI V-Modell waren die Folge) > Pair Programming und (A)TDD wurden zur Qualitätsverbesserung eingeführt > Regelmässige Releases für frühzeitige Safety & VerVal Aktivitäten 28

29 Ablauf auf der Zeitachse (Kanban) Aufwand Nicht in Release 1 Erst in Release 3 Zeit 29

30 Kanban Vorteile gegenüber Scrum > Kein definitives Commitment zu einem Inhalt, nur zu einer gelieferten Kapazität verändert das Planungsverhalten im Management > Releases nicht im festen 2-4 Wochen Raster, Releases können nach Bedarf auf dem Zeitstrahl verteilt werden, Iterationen optional > Stories, die bis zum Releasetermin nicht fertig sind, sind im nächsten Release enthalten > Optional: Hardening Phase vor jedem Release > Hardening Phasen werden nicht als böse gesehen > Die Qualitätskriterien sind unantastbar, mittels Definition of Done nach jeder Stufe im Prozess messbar und überprüfbar > Druck durch Management weniger stark spürbar > Mischung von Kanban mit anderen Methoden problemlos möglich, best practice blend möglich 30

31 Konkreter Einsatz von Kanban > Methode (neu für diesen Wirtschaftszweig) > Value Stream Mapping > Kanban zur Visualisierung, Steuerung und Optimierung > Test Driven Development > Systematische, automatisierte und selbst prüfende Tests > Pair Programming > Continuous Integration (gegen HW-Mockup oder reale HW) > Systematische Coverage Messungen (100% Statement & Branch Coverage) 31

32 Value Stream Mapping (Lean Tool) Abbildung der Stakeholder und deren Abhängigkeiten. Identifikation der nicht wertschöpfenden Prozesse Diese Prozesse sind Angriffspunkt für Waste Elimination 32

33 Kanban Task Boards Testing Team Erstellung System Test dient als Review der Requirements/Stories Ergebnis ist Endkriterium für Entwicklungsteam Abnahme Tests durch PL/PM/QA/SM Reduziert Vergoldungen Development Team Integriert Systemtests Entwickelt gegen Systemtest Entwickelt Low-Level Tests (Coverage) Softwarequalität wird überwacht 33

34 Vergleich Qualität Scrum-Kanban VORHER SCRUM KANBAN Kunde (10+/kLOC) Anteil Integrationsbudget 30% 20% 5% Missed Features 3-5% 1-2% <<1% Overengineered Features 6% 8% 1% Nacharbeiten nicht wertschöpfend bis zu 25% 18-20% 1-4% Project Warm-Up bis zu 6M 1-2M 1-2M Resourcenkonflikte dauernd mittel kaum Konformität zu Normen ++ --/fail /+ Akzeptanz Management /+ Akzeptanz Kunde + --/fail ++ Akzeptanz Qualitätsmanager Qualitätsempfinden Kunde

35 Zusammenfassung > Scrum wird oft als Mini-Wasserfall gesehen > Druck durch Management auf Sprint-Inhalte > Oftmals Fehler durch Maximum Storypoint Vorgaben > Technische Schuld vorprogammiert > Scrum by the book ist ein extrem sensibles Ökosystem > Kanban verursacht weniger Schmerzen in der Einführung > Prozesse können zu Beginn beibehalten werden > Die Prozesse entwickeln sich fast natürlich weiter > Beobachtungen zeigen, dass eine bestehende Organisation mittels Kanban deutlich effektiver und sanfter zur Agilität gebracht werden kann als mit der Scrum-Revolution 35

36 Danke für die Aufmerksamkeit!