Refactathon
Hau ruck oder x Sprints?
Refactoring & Hackathon
Du hast sicherlich die Überschrift gelesen und dir gedacht, wir haben uns verschrieben.
Da kann ich dir nur sagen, nein, das haben wir nicht. Aber was ist denn nun ein Refactathon?
In meinem letzten Projekt waren wir an einem Punkt, an dem wir eine zugrunde liegende Datenstruktur in einem großen Umfang umbauen mussten, ohne die Funktionalität zu ändern. Ich bin mir sicher, genau das kennst du auch, man nennt dies Refactoring. Nun war es leider so, dass wir für das umfängliche Verbessern sehr, sehr viel Zeit gebraucht hätten, die wir nicht zur Verfügung hatten. Aus diesem Grund habe ich mit dem kompletten Projektteam einen „Refactathon“ gemacht. Wir haben alle gemeinsam an zwei Tagen das Refactoring im Stile eines Hackathons durchgeführt.
Die Stories
Wir arbeiten doch alle agil. User Stories sind klein, unabhängig, testbar und schätzbar. Ganz so wie es die „INVEST“-Kriterien für gute User Stories vorgeben. Eine User Story ist nach dem Prinzip aufgebaut: „User A will Aktion B durchführen und erreicht damit Ziel C“.
Doch was tun wir, wenn große Umbauten hochgradig vernetzt und nun mal voneinander abhängig sind? Unser Kunde hat zwei Geschäftsbereiche zusammengelegt, die bisher mit unterschiedlichen Produktdatenstrukturen arbeiteten und nun zusammengeführt werden sollen. Viele Jahre alte Wahrheiten gelten nicht mehr. Das beeinflusst das ganze System und alle Komponenten, jeweils von der Nutzeroberfläche über den Anwendungskern bis hin zur Datenbank sowie die Schnittstellen zu den Nachbarsystemen. Und auch die Nachbarsysteme haben alle das Problem der Produktdatenumstellung.
Ich beginne eine erste, zweite und dritte User Story. Es wird umfangreich. Die Stories sind entweder voneinander abhängig oder haben eine Schnittmenge. Ich reduziere mich also auf das Wesentliche und beschreibe die Stories sehr grob. Jede dieser vielen Stories soll einen stimmigen, testbaren Stand ergeben. Zwischen den schon umgebauten und noch nicht umgebauten Systemteilen müssen wir Mappings bauen und die bestehenden Daten für jeden Zwischenschritt migrieren.
Wir kommen zu dem Fazit, dass wir die User Stories in dieser Form nicht umsetzen, da der Aufwand hier zu hoch wird.
Was tun, wenn alles zusammenhängt?
Klein, unabhängig, testbar, schätzbar? Hier ist nichts unabhängig.
Die Idee lautet: Wir machen alles auf einmal im Hau-Ruck-Verfahren. Story Nummer 1 ist, die Produktdaten komplett zu migrieren. Eine Akzeptanzbedingung der Story lautet: „Jetzt müsste das ganze System kaputt sein.“ Fehler und Systemabstürze werden wir in den nächsten zwei Wochen akzeptieren müssen. Die Stories geben nun an, welche Komponenten wir der Reihe nach angehen wollen. Erst die Basiskomponente „A“, die überall verwendet wird, parallel dazu die Schnittstellen zu den Nachbarsystemen – sie sind umfangreich und kritisch.
Meine Anforderung als Product Owner ist eigentlich ganz einfach: „Es soll wieder so funktionieren wie bisher, nur mit der neuen Datenstruktur.“ Wie kann man nun dazu „User“ Stories schreiben? An welchen Stellen müssen wir umbauen? Das weiß das Entwicklungsteam nach einem tiefen Blick in den Code viel besser als der Product Owner. Wie können wir dem Team helfen?
Unsere erfahrenste Entwicklerin pilotiert das Vorgehen mit der ersten Komponente. Sie überwindet viele Hindernisse und gibt allen anderen wertvolle Tipps mit:
Sie schreibt es auf und wir verwenden ihre Erfahrung in allen weiteren User Stories.
Jetzt brauchen wir noch einen guten Namen für die Aktion.
Kennt ihr einen Hackathon? Wir erfinden aber keine neue App, sondern haben ein handfestes Refactoring einer Business-Anwendung vor uns. Der Refactathon ist geboren!
Wir verabreden uns, für den Refactathon zwei Arbeitstage im Office zu verbringen.
Der Refactathon
Wir starten vor Ort direkt in den Kickoff:
Ich als Product Owner erzähle dem Team von den Produktdatenstrukturen. Ich zeige den Schnitt der Stories und dass die Stories komplett anders sind als andere Stories, wie wir sie kennen. In jeder Story steckt Analyse, Abstimmung mit den POs, Zusammenarbeit mit den Testern. An dieser Stelle sind wir nahe der agilen Schule.
Wir bearbeiten eine Komponente nach der anderen, Story für Story im Pair-Programming. Für offene Fragen sind die POs und auch die Verantwortlichen der Nachbarstory da. Wir bringen die Stories zum Laufen: Anzeige der Daten in der GUI passt. Ein Aktions-Button liefert Error 500… aha, das passt – weil die Anpassung der Schnittstelle noch fehlt! Das kommt dann in einer anderen Story. Wir nehmen bewusst Fehler im Code in Kauf, um Doppelarbeit zu vermeiden.
Am Abend sehen wir, dass es mehr Arbeit ist, als wir dachten. Ein paar lange Gesichter sind die Folge. Unser Traum war die Hälfte am ersten Tag durchzubringen. Realistisch wären dafür wohl drei Tage statt ein Tag gewesen. Wir machen uns klar, dass das auf konventionelle Weise immer noch ca. den doppelten Aufwand erzeugt hätte. Das muntert uns auf. Unsere Idee ist gut. Die Aufgabe wird dadurch nicht weniger umfangreich, aber leichter zu überblicken.
An Tag zwei waren wir eingespielt, sind aber nicht fertig geworden. Alles weitere erledigen wir im Homeoffice.
Das Fazit
Wir haben viele Zusatzaufwände für Zwischenstände und Datenmigrationen gespart. Wie viel das war, können wir nur schätzen. Aber auch das Refactathon-Vorgehen hatte aufwändige Abhängigkeiten:
Natürlich mussten sich die Änderungen durch alle Komponenten ziehen und auch parallel in den verschiedenen Umgebungen getestet werden. Den Überblick über verschiedene Branches und den Inhalt des Master Branch zu behalten, ist nicht einfach. Deployments auf den Umgebungen müssen gemanagt werden. Vor dem Refactathon mussten so viele User Stories wie möglich abgeschlossen werden und in der Endphase mussten wir weitere Implementierungen im Master Branch und im Refactathon-Master Branch parallel halten und diese später zusammenführen.
Die Refactathon-Aufwände und die Schätzung des konventionellen Wegs:
Wann ist denn nun ein Refactathon sinnvoll?
Und was war das Beste für mich persönlich an unserem Refactathon? Unser Team hat sich persönlich zusammengefunden, um an einem großen Problem zu arbeiten – wir stärken somit das Gruppengefühl und den Zusammenhalt. Jeder ist ein Teil der Lösung und das schweißt zusammen.
Über den Autor
Mathias Pusch arbeitet seit zehn Jahren für BettercallPaul in München. Er hat schon sehr verschiedene agile Projekte mitgemacht und selbst verantwortet. Sein Schwerpunkt liegt im Digital Design für individuelle Softwaresysteme. Er verantwortet Requirements, Priorisierung und Lösungsgestaltung und begleitet den Fortschritt bis zum Live-Gang vieler Sprints. Er hat die Erfahrung gemacht, dass sich die verschiedenen Skills der Projektbeteiligten durch Wertschätzung addieren lassen. Das gilt für die Zusammenarbeit mit dem Kunden, für den wir viele typische PO-Aufgaben übernehmen, wie auch mit dem Realisierungsteam, das seine gestalterische Freiheit nutzt.
