Quellcode altert. Ob neue Anforderungen die ehemals schlanke Anwendung immer weiter aufblähen, ob Bugfixes oder provisorische Umbauten für die neue REST-Schnittstelle das tun, Code von genutzten Anwendungen ist fast nie statisch. Aus Clean-Code-Sicht ist daher kontinuierliches Refactoring nötig, um Lesbarkeit und Wartbarkeit des Codes zu erhalten, doch wie geht man damit im Projektalltag um? Wäre der Quellcode ein Schiff, das man mit dem gesamten Team segelt, so wäre allen klar, dass ständig Reparaturmaßnahmen stattfinden müssen, damit es nicht sinkt.
Mir sind in vielen Projekten im Laufe der Zeit einige Patterns und Antipatterns zum Umgang mit diesen Reparaturmaßnahmen aufgefallen.
- Refactorings als U-Boote: die Entwickler führen nötiges Refactoring „unsichtbar“ für den Product Owner (oder Projektleiter) und nebenbei durch. Das reduziert die sichtbare Produktivität des Teams und bringt „unsichtbares“ Risiko ein, da es an Tests vorbei laufen kann.
- Refactorings als Geldvernichter: Product Owner (oder Projektleiter) definieren Refactorings als unnütz, da nur neue Features einen Mehrwert darstellen. In dieser Sicht sind Refactorings lediglich Belastung des Budgets, weil sie Zeit kosten und keinen Mehrwert schaffen und werden daher nicht (sichtbar) durchgeführt.
- Refactorings als zeitliche Lückenfüller: Im Projekt hat sich die Ansicht durchgesetzt, Refactorings könne man durchführen, „wenn Zeit übrig ist“. Wegen zunehmendem Zeitbedarf für Bugfixes und kritische Fehlerbehebungen durch sich verringernde Qualität bleibt aber niemals Zeit übrig.
- Refactorings als Mahnmale technischer Schulden: Es gab einmal eine Erhebung von Refactoring-Bedarf. Leider ist man im Projekt nie dazu gekommen, ihn abzuarbeiten, aber dafür gibt es uralte Tickets oder Aufgaben.
- Refactorings als PAL: Das Team definiert die technischen Schulden, für die Refactorings durchgeführt werden müssen als „Problem anderer Leute“. Wenn jemand anderes zuständig ist, belastet es das Projekt ja nicht.
Ich empfehle einen transparenteren Umgang mit Refactorings, der darauf basiert, sie als notwendige Wartungsmaßnahmen für den Quellcode zu betrachten:
- Entwickler sollten ein Kanban-Board für „technische Schuld“ einrichten und damit transparent machen, was aus ihrer Sicht an technischer Schuld im Quellcode vorhanden ist.
- Die erfassten Refactoring-Bedarfe müssen mit dem Product Owner (oder Projektleiter) diskutiert und die Bearbeitung geplant werden. Nur dann ist sichergestellt, dass auch die „richtigen“ Refactorings durchgeführt werden und nur dann ist auch die Akzeptanz garantiert.
- Stellt ein Entwickler im Code Refactoring-Bedarf fest, hält er diesen auf einem Ticket fest, was ins Backlog des Boards eingestellt wird. Der Umfang sollte ad-hoc vom Entwickler (idealerweise von 1-2 Entwicklern) geschätzt und im Ticket festgehalten werden
- Gemeinsam mit Team, Product Owner (oder Projektleiter) werden zu jedem Sprint oder in regelmäßigen Intervallen Tickets zur Bearbeitung ausgewählt und eingeplant.
- Entstehen während der Bearbeitung zusätzliche Aufgaben, können diese als neue Tickets auf dem Board erfasst werden.
So kann das Projekt-Schiff in ruhiger See weitersegeln.
Abschließend noch zwei Fragen, die mir die Kollegen im Zusammenhang mit dem Artikel und dem Umgang mit technischer Schuld gestellt haben.
Frage: „Wie geht man mit der Gefahr um, dass das vorgeschlagene Kanban-Board nicht genau dieses Mahnmal technischer Schuld wird?“Antwort: Das ist in der kontinuierlichen Abarbeitung und Berücksichtigung des Boards explizit enthalten. Indem bei jedem Sprint (oder in regelmäßigen Intervallen) auf die technischen Schulden geschaut und – passend zur Projektsituation – einzelne Themen herausgegriffen und bearbeitet werden, passiert eine stetige Beachtung und erneute Diskussion der Refactoringbedarfe. Ich muss allerdings auch einschränken, dass die Abarbeitung von technischen Schulden eine Kulturfrage ist und nur durch die rein technische Erfassung noch lange keine Abarbeitung stattfindet.
Frage: „Was ist zu tun, wenn der Product Owner (PO) in der Diskussion die Refactorings als unnütz klassifiziert und sie nicht eingeplant werden?“
Antwort: Auch hier geht es um eine Mentalitäts- bzw. Kulturfrage und die ist in dieser Situation schwer zu lösen. Es besteht ein Interessenskonflikt zwischen PO und dem Team und aus meiner Sicht hilft in dieser Situation am besten das Sammeln von (beweisbaren) Argumenten für die Notwendigkeit der Reduktion der technischen Schuld. Das könnte beispielsweise durch die Erhebung von passenden Kennzahlen geschehen, etwa „Anzahl der Prio 1 Fehler“, „Anzahl der Fixes und Hotfixes“, „Verwendete Zeit für kritische Fehlerbehebungen“ oder ähnliches.
Diese Kennzahlen müssen regelmäßig erhoben und gemeinsam mit dem PO diskutiert werden. Dadurch erzeugt man Klarheit über die steigenden Aufwände für Beseitigung von technischen Schulden im Team und das kann zu einem Mentalitäts- oder Kulturwandel beitragen.
zurück zur Blogübersicht
Diese Beiträge könnten Sie ebenfalls interessieren
Keinen Beitrag verpassen – viadee Blog abonnieren
