3 Minuten
Kürzlich wurden wir mit folgendem Problem konfrontiert: Der Großteil der Arbeit eines Teams fließt in Bugfixes und das Beheben von Problemen. Fast nichts anderes geht mehr voran.
Lösungen, die in solchen Situationen diskutiert werden, sind meist:
- Fester Prozentsatz der Zeit des Teams wird zum Fixen der Bugs verwendet
- No Fix without a test - Für jeden Fix muss ein Test geschrieben werden
- Bug Bash, ein oder mehrere Sprints in denen nur Bugs behoben werden, um sich wieder Luft zu verschaffen
- Eine Fastlane für Bugs
- …
Also irgendetwas, das die Symptome lindert und den aktuellen Schmerz behebt.
All das ist legitim und richtig. Nur wenn ein Team so viel Zeit mit Bugs verbringt, dass fast nichts anderes mehr vorangeht, ist es egal wie man die Arbeit verteilt, sie wird das Team immer massiv ausbremsen. Zu viel ist einfach zu viel. Die Lösung liegt also an anderer Stelle.
Treten wir einen Schritt zurück.
Fragt man einen Entwickler: “Wie lange brauchst du um einen Bug zu fixen, wenn du das Feature gerade entwickelst und gedanklich genau an der Stelle bist?” ist die Antwort meist: “Je nachdem, aber meist nur ein paar Minuten. Maximal eine Stunde, wenn es etwas Größeres ist.”
“Wie sieht es aus, wenn der Code schon zwei bis drei Monate liegt und du gerade völlig woanders unterwegs bist?”
“Naja, ich muss mich wieder in das Thema eindenken, vielleicht noch etwas nachlesen. Mindestens eine Stunde eher ein halber Tag. Ein Tag oder mehr, wenn es etwas Größeres ist. Außerdem muss ich ja noch meine aktuelle Arbeit sichern und dort auch wieder den Faden aufnehmen.”
Der Aufwand einen Bug zu fixen steigt, mit der Zeit, die der Code liegt. Oder andersherum: Je früher ein Bug gefunden wird, desto leichter (und günstiger) ist es ihn zu fixen.
Abbildung 1: Zusammenhang zwischen Kosten für Bugfix und Entdeckungszeitpunkt.
Abbildung 1 illustriert den Zusammenhang. Der Zusammenhang ist vielen intuitiv klar. Aber was ist die Konsequenz für das oben genannte Team?
Wenn ein Team nur noch mit Fixen von Bugs beschäftigt ist, dann deshalb, weil Bugs zu spät gefunden werden.
That’s it. Das ist der Grund warum manche Teams in Bugfixing ertrinken und andere nicht.
Achtung! Eine Annahme steckt in der Aussage: Die Codebasis ist nicht so fragil, dass jede kleine Änderung zu jeder Menge Bugs führt. Dann hat man noch ein ganz anderes Problem. Aber zurück zum Thema 🙂
Es gibt jetzt im Wesentlichen zwei Hebel, um Bugs schneller zu finden: Bessere automatisierte Tests und kürzere Lead Times (also die Zeit zwischen ‘der Code wird geschrieben’ bis ‘der Code läuft in Produktion’).
In unserem Fall ist die Lead Time ein Jahr und mehr. Bugs, die nicht durch Tests gefunden worden sind, werden frühestens ein Jahr nach Entwicklung gemeldet. Natürlich ist der Aufwand, diese Bugs zu fixen, gigantisch. Die einzige Lösung, das Team langfristig von der Last durch die Bugs zu befreien, besteht daher darin, die Lead Time drastisch zu verkürzen.
