Offene Tickets, noch nicht bearbeitete Bug Reports, oder Pull Requests, die auf eine Sichtung warten – dies alles sind Beispiele für Work in Process (WIP). Im Projektgeschäft verwalten wir diese halbfertige Arbeit mit schönen Tools, wie Issue Tracker, Trello oder GitHub. Das ist bequem, verstellt aber oft den Blick auf die Folgekosten:
Die Maxime aus dem Lean Thinking lautet daher: WIP begrenzen, um die Durchlaufzeiten zu verringern und die o.g. Folgekosten zu vermeiden.
Für die Beobachtung von WIP bzw. allgemein Warteschlangen hat sich ein einfaches Diagramm bewährt: Das Cumulative Flow Diagram. Hier ist ein schönes Beispiel aus einem Open Source Projekt (cucumber-jvm):
Das Diagramm zeigt, wie sich die Zahl der offenen Github-Issues (=Bug Reports, Wünsche, Pull Requests u.ä.) und die Zahl der abgearbeiteten Issues (Status “closed”) verändern. Es heißt “kumulativ”, weil beide Anzahlen übereinander gestapelt werden, d.h. der obere Rand der blauen Fläche zeigt die insgesamt vorhandenen Issues (offene + fertige). Die Höhe des blauen Bereiches zeigt, wieviele Issues noch offen sind, das ist also die Länge der Warteschlange. Ende 2017 haben wir insgesamt 1228 Issues, davon sind noch 46 offen.
Ich sehe in diesem Diagramm drei Phasen:
Etliche Projekte stecken in einer Situation, die Phase B ähnelt: Warteschlangen und folglich Durchlaufzeiten wachsen einfach immer weiter. Da rauszukommen, macht natürlich Arbeit. Cumulative Flow Diagrams können dabei helfen, Problembewusstsein zu schaffen und die Motivation zur Verbesserung hoch zu halten.
Die Zusammenfassung für alle Cucumber-Teilprojekte (Stand: Ende 2017) gibt’s bei Cucumber Issue Stats, ebenso den Code, um ähnliche Diagramme für eigene Github-Projekte zu erstellen.
Matthias Berth