Pecha-Kucha: Stop The Line
•Transferir como PPTX, PDF•
3 gostaram•648 visualizações
Pecha Kucha-Vortrag zu "Stop the Line in der Softwareentwicklung"
Recomendados
Mais conteúdo relacionado
Destaque
Destaque (20)
Mais de Stefan ROOCK
Mais de Stefan ROOCK (20)
Pecha-Kucha: Stop The Line
- 1. Stop the Line in der Softwareentwicklung XP-Days Germany 2009 Stefan.Roock@it-agile.de
- 2. Toyota
- 7. Kein Lager
- 10. Nützlich?
- 11. Tatenlos?
- 12. Warteschlange
- 13. Visualisierung
- 14. Broken Windows
- 15. Verlässlichkeit
- 16. Branches
- 17. Bye bye, Bugs!
- 18. nicht nur Bugs
- 19. Unser Bugtracker
- 20. Don‘t Manage Bugs Fix Them
- 21. Vielen Dank für die Aufmerksamkeit stefan.roock@it-agile.de Twitter: StefanRoock
Notas do Editor
- Mein Name ist Stefan Roock von it-agile und ich möchte etwas zu Stop the Line in der Softwareentwicklung erzählen. Das Stop the Line Prinzip stammt ursprünglich von Toyota und ist Bestandteil des Toyota Production Systems. Es wird in der Fahrzeugproduktion eingesetzt. Es funktioniert wie folgt:
- Bei Toyota gibt es Zugleinen, an denen jeder in der Produktion ziehen kann, wenn er ein Problem entdeckt. So ein Problem kann etwas Triviales sein, wie ein kleiner Kratzer in einem Kotflügel. Hat jemand an der Leine gezogen, ertönt ein Alarmsignal und eine Lampe beginnt zu leuchten. So kann man direkt sehen, wo das Problem entdeckt wurde.
- Wenn so ein Alarm ausgelöst wurde, kommt ein Ingenieur mit weißen Handschuhen angelaufen (ein sogenannter White Glove) und entscheidet: „Liegt wirklich ein Problem vor?“ Wenn ja, stoppt er die Produktionslinie. Vom ersten Alarm bis jetzt darf maximal 1 Takt vergangen sein. Das ist weniger als 1 Minute.
- Jetzt kommt ein Supervisor dazu und entscheidet: Kann das Problem innerhalb von 2 Takten behoben werden? Wenn nein, stoppt der Supervisor die ganze Fabrik. In einer Toyota-Fabrik mit 7 Produktionslinien wird im Schnitt jede Minute einmal Stop-the-Line ausgelöst.
- Toyota verfolgt diesen Ansatz, weil das entdeckte Problem i.d.R. nicht auf einen Zufall zurückgeht. Es gibt stattdessen eine tiefere Problemursache, die beseitigt werden muss, z.B. eine falsch eingestellte Maschine. Sonst tritt das Problem wieder auf.
- Der Grund dafür, dass so kurze Zeitfenster für die Entscheidungen existieren, ist die geringe Menge an Lagerplätzen bei Toyota. Zwischenprodukte der vorgelagerten Arbeitsschritte können nirgends zwischengelagert werden.
- Toyota in Fortune 500 in 2008: Fünftgrößtes Unternehmen der Welt Größtes Autounternehmen der Welt 230 Mrd. USD Umsatz 15 Mrd. USD Gewinn Für Toyota funktioniert der Ansatz also offenbar sehr gut.
- Aber kann man Stop-the-Line sinnvoll auf Softwareentwicklung übertragen? Softwareentwicklung ist schließlich definitiv keine Produktion. Statt sequenzieller immer gleicher Tätigkeiten besteht Softwareentwicklung aus kreativer Tätigkeit und Interaktion zwischen Menschen.
- Was könnte Stop-the-Line in der Softwareentwicklung bringen? Qualitätsdenken wird befördert. Probleme werden früh sichtbar und beseitigt. Man weiß jederzeit genau, wo man steht. Folgefehler werden vermieden.
- Wenn ich Stop-the-Line vorschlage, ist die erste Reaktion immer: Wenn bei jeder Kleinigkeit alle stoppen, dann sitzen die meisten Leute bei einem Problem ja rum. Das ist zu teuer. Wir müssen eine hohe Auslastung haben. Daher mein Tipp: Alle stoppen bis sich Problemlöser gefunden haben. Dann darf der Rest weiterarbeiten.
- Solange das Problem besteht, darf nicht eingecheckt werden. Wer mit seiner aktuellen Aufgabe fertig ist und einchecken müsste, sollte keine neue Aufgabe beginnen. Stattdessen wird er/sie auch zum Problemlöser. So vergrößert sich die Menge der Problemlöser, je länger das Problem andauert.
- Erfahrung: Eine aufdringliche Visualisierung ist nützlich. Wir haben dazu eine Ampel nur mit grün und rot aufgehängt, die im mit dem CI-Server (z.B. Hudson) verbunden ist. Die Ampel wird an einem gut sichtbaren Ort aufgehängt.
- Erfahrung: Wenn die Ampel meistens rot ist, wirkt das sehr demotivierend und sie wird ignoriert. Daher sollte man sich bei dem, was die Ampel visualisiert bewusst auf das beschränken, was man in mind. 50% der Fälle grün hat. Also z.B. erstmal nur die Unittests. Und dann erhöht man schrittweise den Umfang: Integrationstests, Akzeptanztests, Live-Bugs, …
- Erfahrung: Der ganze Ansatz ist nicht durchhaltbar, wenn die Ampel häufig einen falschen Zustand anzeigt. Wenn die Ampel ständig rot ist, weil die Build-Infrastruktur nicht stabil läuft, wird sie nicht mehr beachtet.
- Erfahrung: Bei der Arbeit mit Feature-Branches wird es sehr schwierig. Braucht man eine Ampel je Branch? Oder eine auf allen Branches? Oder nur eine auf dem Trunk? Wahrscheinlich braucht man dann eine kompliziertere Visualisierung wie einen großen Monitor, der dann aber nicht mehr so eindeutig funktioniert.
- Erfahrung: Qualität rückt stärker ins Bewusstsein der Projektbeteiligten. Strikte Trennungen zwischen Qualitätssicherung und Entwicklung verschwinden. Bugrate sinkt
- Welcher Trigger? Wir hatten bereits: CI-Server zeigt Fehler Interne Tests zeigen Fehler Live-Probleme Refactoring-Bedarf Beliebige Hindernisse
- Erfahrung: Wenn man fleißig Stop-the-Line praktiziert, kein elektronisches Tool mehr zur Bugverwaltung notwendig. Die wenigen existenten Bugs können bequem auf Zetteln an der Wand hängen.
- Ich habe gelernt, dass es keine Software ohne Fehler gibt und das man mit Fehlern leben muss. Aber müssen wir das wirklich so hinnehmen? Ich glaube, wir können das besser. Don‘t Manage Bugs, Fix Them!