Stop the Line in der Softwareentwicklung
XP-Days Germany 2009
Stefan.Roock@it-agile.de
Toyota
Problem? Alarm!
Stop the Plant
Problemursachen
Kein Lager
Wir sind anders!
Nützlich?
Tatenlos?
Warteschlange
Visualisierung
Broken Windows
Verlässlichkeit
Branches
Bye bye, Bugs!
nicht
nur
Bugs
Unser Bugtracker
Don‘t Manage Bugs
Fix Them
Vielen Dank für die Aufmerksamkeit
stefan.roock@it-agile.de
Twitter: StefanRoock
Pecha-Kucha: Stop The Line
Pecha-Kucha: Stop The Line
Nächste SlideShare
Wird geladen in …5
×

Pecha-Kucha: Stop The Line

1.309 Aufrufe

Veröffentlicht am

Pecha Kucha-Vortrag zu "Stop the Line in der Softwareentwicklung"

Veröffentlicht in: Technologie
0 Kommentare
3 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
1.309
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
8
Aktionen
Geteilt
0
Downloads
14
Kommentare
0
Gefällt mir
3
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie
  • 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!
  • Pecha-Kucha: Stop The Line

    1. 1. Stop the Line in der Softwareentwicklung XP-Days Germany 2009 Stefan.Roock@it-agile.de
    2. 2. Toyota
    3. 3. Problem? Alarm!
    4. 4. Stop the Plant
    5. 5. Problemursachen
    6. 6. Kein Lager
    7. 7. Wir sind anders!
    8. 8. Nützlich?
    9. 9. Tatenlos?
    10. 10. Warteschlange
    11. 11. Visualisierung
    12. 12. Broken Windows
    13. 13. Verlässlichkeit
    14. 14. Branches
    15. 15. Bye bye, Bugs!
    16. 16. nicht nur Bugs
    17. 17. Unser Bugtracker
    18. 18. Don‘t Manage Bugs Fix Them
    19. 19. Vielen Dank für die Aufmerksamkeit stefan.roock@it-agile.de Twitter: StefanRoock

    ×