Lean and Agile Coffee Nov. 2015
4 gefällt mir1,248 aufrufe
Das Dokument beschreibt die Implementierung von Kanban und Agile in der Entwicklungsorganisation der PKE Electronics AG, um Abhängigkeiten zu reduzieren und den Ressourcenfluss zu optimieren. Es werden zwei Beispiele dargestellt: eines zur Teamzusammenlegung und Prozessoptimierung sowie eines zur Verbesserung der Release-Politik und Qualitätssicherung. Durch die Einführung von WIP-Limits, Feature-Teams und monatlichen Portfolio-Meetings konnten die Effizienz gesteigert und Qualitätsprobleme adressiert werden.
Lean and Agile Coffee Nov. 2015
- 1. Lean & Agile Coffee Vienna Anwenderbeispiel Kanban Flight Levels Michael Rumpler Leiter Entwicklung PKE Electronics AG
- 3. KABA MIC AWM Rümlang, Wetzikon (CH) Leonberg, Villingen-Schwenningen (DE) Entwicklung (HW, SW, Produktion) Produktion (Mechanik, Mechatronik, Elektronik) Beispiel 1
- 5. Beispiel Kaba MIC AWM 5 Produktmanagement Produktmanagement Produktmanagement Quality Assurance Project Management / Requirements Eng. Die Entwicklungsorganisation (vereinfacht)
- 6. Ausgangslage 6 • 2 Scrum Teams für das größte Produkt • Scrum (but) Prozess • Viele Abhängigkeiten (die zu Waste führten) • Ineffiziente Resourcennutzung • Nicht auf Optimierung des Flow ausgerichtet
- 7. Schritt 1: Team-Zusammenlegung 7 12 Entwickler 4 Tester 2 Techn. Redakteure 3 POs 3 PMs
- 8. Team Level 8
- 9. Prozessdetails Team Level 9 • 4 unabhängige «Feature Trains» • Das Team stellt feste Kapazität pro Feature Train zur Verfügung • Das Team entscheidet wer an welchem Feature arbeitet • 2 wöchige Iterationen mit queue replenishment, iteration review und Retrospektive • Definition of Done (DoD) für jeden Übergabepunkt • Koordinierter Input vom Release - Management • WIP limits pro Person (2 Magnete pro Person) • WIP limits pro Swimlane (Limit pro Arbeitstyp) • Express Lane um auf dringende Probleme reagieren zu können • Externe Supportanfragen oder Fehler, die das LC Team nicht alleine lösen kann • Teaminterne Probleme/Deadlines
- 10. Team Board Elemente 10 WIP Limits pro Person Commited Backlog (nahe Zukunft) Feature Train (swimlane) DoD Express Lane WIP Limits pro Feature Train und Arbeitstyp
- 11. Level UP - Value Stream Board (FL3) 11 Projekt / Initiative Level
- 12. Prozessdetails Projekt-Level 12 • Value-driven Process • Verschiedene Phasen entlang der Kette werden von unterschiedlichen Teams bearbeitet • Übergabepunkte mit DoD „qualitätsgesichert“ um waste zu vermeiden • Ausrichtung am sensibelsten Teil der Kette • In diesem Fall die Entwicklung und Akzeptanzphase, da hier immer deutlich weniger Kapazität als Nachfrage
- 13. Projektboard Elemente 13 Input Queue Arbeitstypen Definition of Done Phasen Team(s) die an Aufgabe arbeiten werden mit Magnet dargestellt (rot – extern) VALUE STREAM
- 14. Level UP – Portfolio Level 14
- 15. Prozessdetails Portfolio 15 • Zeigt Art der Ressourcen (SW, HW, Prod, ...) • Zuordnung von Initiativen (Projekten) zu Ressourcen • Bietet Übersicht über aktuelle und zukünftig zugesagte Arbeiten • Alles was nicht auf der Darstellung ist, ist nicht zugesagt • Hat implizite WIP Limits • Nicht mehr als 2 Initiativen/Projekte pro Ressource pro Monat • Mehr als 1 nur in Übergangsphasen • Kommunikationsinstrument zu allen Stakeholdern der Entwicklung • Kein physikalisches Board (mehrere Standorte, mehrere Organisationen) • Monatliches Portfolio Meeting (15-20 Personen) • Strenge Ablaufregeln, Moderation
- 16. Portfolio Board Elemente 16 Site/Team/Kapazität Capabilities Freie Kapazität VerfügbareKapazitätEntwicklung Zeitraum Zukünftiges Commitment Nicht verfügbar
- 17. Vorher 17
- 18. Priorisierung per Cost of Delay 18 Auswahl, was als nächstes kommt...
- 19. PKE Electronics AG PM, Entwicklung, Support, Techniker Beispiel 2
- 20. PKE Produkte 20
- 21. • Entwicklung ca. 40 Mitarbeiter • Entwickler, 2 Technische Redakteurinnen • Test getrennt von Entwicklung, 2 Personen im Support • 2 Große “Teams” • Arbeit nur im Push Verfahren (via Tool) • Big Picture oft nicht bekannt • Single Person Code “Ownership” • Keine Automatisierten Tests, keine Unit Tests • In einem Excel Sheet definierter “Regressionstest” Ausgangslage 21
- 22. • Test in Entwicklung integriert • Aufgestockt auf 6 Personen • Davon 3 Automatisierungsexperten • Personen auf “Fachteams” aufgesplittet • Freispielen der bisherigen Teamleads • Eigentliche Aufgabe: Spezifikation und Kommunikation mit PM • Stabilisierungsphase und erste grundlegende Refactorings um gröbste Qualitätsprobleme einzudämmen Grundlegende Änderungen 22
- 23. • Release immer vom “Development Main” • In jedem Release unfertige Teile enthalten • Qualität unklar (Test erst nach “Freigabe” an den Support) • Releasezyklen nicht vorhanden • “On-Demand” für Projekterfordernisse • “Quick Fixes” • Viele “Bastelinstallationen” • Viele Störungen durch Feldprobleme und ungeplante dringende Projekterfordernisse • 2 Monate “Sprints” • Selten mehr als 50% des geplanten Umfanges umgesetzt, Kommunikation erst bei Release Release Politik “alt” 23
- 24. Release Politik “neu” 24 • Einführung Feature-Branches und Feature-Teams • “Virtual Main” für Test und Integration • Release immer von “Stable Branch” • Service Releases enthalten nur Bugfixes, keine neuen Funktionalitäten • Qualität vorab prüfen (mit internem Test) • Testautomatisierung einführen (Aufholbedarf!) • Feste Releasezyklen eingeführt • Alle 6 Monate ein Major Feature Release • Jedes Monat ein Service Release für die letzten beiden Major Releases • Kapazität für Lifecycle und Projekterfordernisse reserviert, ansonsten feste Roadmap auf Saga Ebene • Development Slots pro Saga, mindestens MVP wird geliefert, nice-to-haves nach Kapazität
- 26. Value Stream Toolkette 26
- 27. Release Politik “neu” graphisch 27
- 28. Gesamte Entwicklung Ein Board 28
- 29. Slot Abschätzung 29 • Magic Estimation • MVP + Nice-To Haves • Die Erfahrung wird den “Scotty Factor” zeigen
- 31. • Messungen von Beginn an mit in/out • Einfach durchzuführen • Datumsstempel • Einmal pro Woche in Excel übertragen • Trend erkennbar • Migration auf Tool im Laufen, Metriken kommen danach mit mehr Detail von dort • Excel-Tools von Troy Magennis • https://github.com/FocusedObjective/FocusedObjective.Resources/tree/master/Spreadsheets Messungen 31
- 32. Messungen (1) 32 0 20 40 60 80 100 120 140 5/16/2015 6/5/2015 6/25/2015 7/15/2015 8/4/2015 8/24/2015 9/13/2015 10/3/2015 10/23/2015 11/12/2015 CycleTimeinDays Date item was completed ITEM CYCLE TIME (IN CALENDAR DAYS)
- 33. Messungen (2) 33 Year-Week Number Avg WIP Throughput Avg Cycle Time WIP Trend Throughput Trend Avg. Cycle Time Trend
- 34. Messungen (3) 34 28 68 86 136 146 170 177 174 175 189 166 141 137 124 108 112 87 74 32 32 18 2 1 28 68 86 136 147 168 156 158 154 137 136 124 105 97 83 69 28 23 15 2 0 0 20 40 60 80 100 120 140 160 180 200 Numberofin-progressitemsbyweek Year-Week Number Max WIP Avg WIP Min WIP Linear (Avg WIP)
- 36. Messungen (5) 36 -28 -40 -18 -50 -10 -24 -3 12 -14 16 22 0 13 19 -2 24 12 43 -4 14 16 Year-Week Number More started than completed More completed than started
- 37. Messungen (6) 37 28 216 103 64 57 33 39 22 25 14 12 16 2 8 8 5 3 1 0 1 0.5 7 14 21 28 35 42 49 56 63 70 77 84 91 98 105 112 119 126 133 Countofitemswiththiscycletime Cycle Time value (calendar days from start to complete) CYCLE TIME HISTOGRAM
- 38. Messungen (7) 38 1.5 8 8 22 12 22 28 34 23 16 40 18 25 7 8 12 12 8 6.5 3 8.5 0 20 40 60 80 100 120 140 2015- 23 2015- 24 2015- 25 2015- 26 2015- 27 2015- 28 2015- 29 2015- 30 2015- 31 2015- 32 2015- 33 2015- 34 2015- 35 2015- 36 2015- 37 2015- 38 2015- 39 2015- 40 2015- 41 2015- 42 2015- 43 75th Percentile 5.75 10 14.5 26 28 29.5 39.5 37.5 41.5 42.75 53 50.5 48 21 15.5 42 34 20.75 17 5 9.75 Highest 7 15 19 27 29 41 49 54 64 70 75 77 93 91 94 105 114 97 129 58 11 Median 1.5 8 8 22 12 22 28 34 23 16 40 18 25 7 8 12 12 8 6.5 3 8.5 Lowest 1 0.5 0.5 1 0.5 3 2 6 1 1 0.5 0.5 0.5 0.5 0.5 0.5 1 0.5 0.5 0.5 6 25th Percentile 1 2 1 21 6 18 25 26.25 7 8.25 11 8.25 7.75 4 3.5 2 6 3.25 2.75 1 7.25 Cycletimeindays Cycle time range for items completed within each week (year-week number) Days to complete items (cycle time) by week
- 39. Messungen - Datenvalidierung 39 0 20 40 60 80 100 120 140 5% 10% 15% 20% 25% 30% 35% 40% 45% 50% 55% 60% 65% 70% 75% 80% 85% 90% 95% 100% Cycletimevalueindays Percentile Cycle time Actual vs Estimate Weibull Curve Fit Estimated parameters - shape:0,79 scale:22,13 actual estimated
- 41. Best Practices / Eindrücke 41
- 42. Best Practices / Eindrücke 42
- 43. Best Practices / Eindrücke 43
- 44. Best Practices / Eindrücke 44 • Immer Low- Tech starten • Pen&Paper • Für ein Tool entscheiden wenn Prozess im Wesentlichen gefestigt
- 45. Best Practices / Eindrücke 45
- 46. Best Practices / Eindrücke 46
- 47. PKE Electronics AG Computerstraße 6 1100 Wien T +43 (0) 50150-1021 pke.electronics@pke.at www.pke.at www.pke-de.com www.pke-electronics.ch www.tb-traxler.at