Technische Schulden: Jeder hat sie und jeder Entwickler, der seinen Titel verdient, möchte sie abbezahlen. Aber wie organisieren Sie diesen Prozess?

Wir implementieren Fruchtfolge

In meinem vorherigen Artikel habe ich die Rückzahlung technischer Schulden mit der Bedeutung der Fruchtfolge in der Landwirtschaft verglichen. Wenn Sie ein Feld (Codebasis) Saison für Saison weiter verarbeiten, um eine große Ernte zu erzielen (Projekte abschließen, Funktionen hinzufügen usw.), und diesem Feld keine Saison zur Wiederherstellung geben (Zahlung technischer Schulden), dann ist dies der Fall allmählich beginnt seine Qualität und Produktivität zu verlieren.



Diese Metapher bleibt für die Softwareentwicklung geeignet. Darüber hinaus enthält es Hinweise auf mögliche Strategien, mit denen technische Schulden getilgt werden können.



Es gibt überraschend viele Möglichkeiten, Schulden abzuzahlen. Und das ist sehr nützlich, da es uns viele Planungsmöglichkeiten bietet.



Für die Zwecke dieses Artikels gehen wir davon aus, dass Sie an einer agilen Entwicklungsmethode arbeiten. Viele der Prinzipien gelten jedoch, wenn sie kreativ verfeinert werden, für andere Methoden.

Engagierte Sprints zur Tilgung technischer Schulden

In voller Analogie zur Fruchtfolge können wir die Arbeit an Features bei jedem vierten Sprint oder so einstellen und sie nur zur Tilgung technischer Schulden zuweisen.



Vorteile:

• Entwickler teilen das gemeinsame Bestreben, sich ausschließlich auf die Tilgung technischer Schulden zu konzentrieren
• Entwickler können koordinieren, um größere Teile der technischen Schulden durch gleichzeitige Zusammenarbeit abzuzahlen
• Unternehmen sind motiviert, technische Schuldenergebnisse zu untersuchen, die die Bedeutung der Arbeit und das verbleibende Volumen belegen.

Minuspunkte:

• Zusammenführungskonflikte treten auf, wenn Mitarbeiter größere Mengen an architektonischen Änderungen vornehmen.
• Bei diesem Chaos und dieser Instabilität kann es schwierig sein zu sagen, ob etwas kaputt ist, wenn es keine gute Testabdeckung gibt.
• Nur weil Sie an technischen Schulden arbeiten, verschwinden Support-Vorfälle nie. Ohne Mitarbeiter, die bei der Eskalation von Supportanfragen helfen, wird die technische Verschuldung garantiert durch den Support behindert.

Engagierte Kapazität für die technische Rückzahlung von Schulden

In diesem Modell reserviert das agile Team eine bestimmte Anzahl von Punkten oder einen Prozentsatz der gesamten Sprintkapazität, um fortlaufend technische Schulden zu bezahlen. Zum Beispiel kann ein Team in jedem Sprint 5 Storypoins verschiedener Schuldentilgungsjobs annehmen.



Vorteile:

• Dies stellt sicher, dass die Tilgung technischer Schulden Teil der laufenden Unternehmenskultur ist.
• Laufende technische Schuldenarbeiten können verhindern, dass in Zukunft mehr Arbeit benötigt wird.

Minuspunkte:

• Wenn Änderungen am Sprint vorgenommen werden müssen, ist die Arbeit an technischen Schulden der wahrscheinlichste Kandidat für die Entfernung aus dem Sprint.
• Indem Sie Ihre Arbeit an technischen Schulden auf kleine Beträge beschränken, erschweren Sie es, die manchmal großen Teile technischer Schulden zu beseitigen.

Mitarbeiter für die Tilgung technischer Schulden einsetzen

Dies ist eine Mischung aus den letzten beiden Optionen. Jeder Sprint wählt einen Entwickler aus, der an der technischen Verschuldung arbeitet, während alle anderen ihre normale Arbeit fortsetzen.



Vorteile:

• , , .
• , ,

:

• ,
• , , capacity

Wenn Entwickler in diesem Modell ihre Arbeit planen, fügen sie dem Plan die Bereinigung des benachbarten Codes und die Zahlung erkennbarer technischer Schulden hinzu, die sich bereits im Arbeitsbereich befinden. Dies steht im Einklang mit dem Pfadfinderprinzip : Lassen Sie den Parkplatz (Codebasis) immer sauberer als vor Ihnen.



Mit anderen Worten bedeutet dies, dass der Code besser werden sollte, wenn Sie ihn berühren. In dem Code, der am häufigsten berührt wird, müssen Sie den höchsten Prozentsatz der technischen Schulden bezahlen. Daher ist es sinnvoll, die Schulden in den Bereichen des Codes zu begleichen, an denen Sie arbeiten.



Ein ähnliches Konzept findet sich in Malcolm Gladwells Buch The Tipping Point.für ein Beispiel aus der New Yorker U-Bahn. Die Stadtverkehrsbehörde hat festgestellt, dass Sie durch das Entkoppeln von U-Bahn-Wagen, das Reinigen von Graffiti und das Sicherstellen, dass zu jeder Zeit keine Graffiti vorhanden sind, die Auswirkungen zerbrochener Fenster sparen können , bei denen die Menschen glauben, dass der Zustand der Autos nicht stört Jeder und die Kriminalitätsrate kann steigen. Durch die Reduzierung der Anzahl von Kaninchen und Graffiti könnte die Agentur auch die Anzahl von Gewaltverbrechen in der U-Bahn reduzieren.



Wenn wir dasselbe Prinzip auf unsere Codebasis übertragen, müssen wir es so gestalten, dass beim Berühren von Bereichen des Codes diese bereinigt und die technischen Schulden beglichen werden.



Sie haben wahrscheinlich aus dem, was Sie oben gelesen haben, erraten, dass ich ein Fan dieses Ansatzes bin, aber lassen Sie uns trotzdem seine Vor- und Nachteile betrachten.



Vorteile:

• Tech-Schulden zahlen sich in Bereichen aus, die Entwickler natürlich häufiger berühren
• Sie müssen nicht mehr "Speicherplatz zuweisen", um technische Schulden zu bezahlen, sondern sind nur ein Teil des Workflows
• Zusammenführungskonflikte werden minimiert, da Änderungen nur in isolierten Bereichen vorgenommen werden.

Minuspunkte:

• Es gibt keine besondere Möglichkeit, große Änderungen vorzunehmen, die sich auf das gesamte System auswirken
• Dies führt zu einer "Inflation" der Storypoints, da mit jedem Ticket zusätzliche Arbeit geleistet werden muss. Dies reduziert den Arbeitsaufwand für jeden Sprint.

Wichtige Code-Revisionen

Oben habe ich über die Strategie gesprochen, technische Schulden durch schrittweises Ersetzen von Teilen des Systems abzuzahlen, wie im Gedankenexperiment mit Theseus 'Schiff , aber was ist, wenn das nicht ausreicht? Was ist, wenn Sie keine Zeit haben, die gesamte Software Stück für Stück zu ersetzen, und radikalere Änderungen vornehmen müssen?



Hier sind einige Ideen, die Ihnen helfen sollen:

Aufteilen einer Anwendung in kleinere Anwendungen

Mit dieser Methode teilen wir die monolithische Anwendung in kleinere Anwendungen auf. Oft wird dieser Ansatz durch domänengesteuertes Design und / oder Microservices ergänzt. Der Hauptpunkt besteht jedoch darin, dass die Anwendung, wenn sie zu groß ist, um sie zu ersetzen, in kleinere Teile unterteilt werden kann, deren Ersetzung realistisch ist. Anschließend können Sie die einzelnen Teile ersetzen Teil nacheinander.



Sie können dieses Schema auch mithilfe des Strangler-Anwendungsmusters von Martin Fowler implementieren , mit dem eine neue Anwendung erstellt wird, die dieselben Anforderungen wie die alte empfängt und Legacy-Systeme aufruft, bis für jedes System ein moderner Ersatz bereitsteht.



Vorteile:

:

• ,

capacity

In diesem Modell können Entwickler die Zeit oder die Zeit, die für technische Schulden vorgesehen ist, verwenden, um an langfristigen Projekten zu arbeiten, z. B. um einen Teil oder die gesamte Anwendung zu ersetzen. Sobald ausreichende Fortschritte erzielt wurden und ernsthaft mit der Arbeit begonnen werden kann, werden diese Aufgaben zur formellen Implementierung und Bereitstellung in einen Sprint oder eine Sprint-Serie implementiert.



Nach diesem Muster war ich sehr erfolgreich darin, JavaScript-Anwendungen auf TypeScript zu portieren , einschließlich Zeit außerhalb der Arbeit zu verbringen (nicht unbedingt, aber ich habe mich dazu entschlossen) und darauf zu warten, dass Regressionstestumgebungen online gehen.



Vorteile:

• Potenziell defekte Prototypen, die nicht an formale QS- / Lieferzyklen gebunden sind, können identifiziert und behoben werden
• Wenn die Arbeit bereit ist, in den Sprint aufgenommen zu werden, ist es normalerweise bereits eine sehr konzentrierte Arbeit, in der die meisten unbekannten Variablen gelöst werden.

Minuspunkte:

• Es kann schwierig sein, eine erhebliche Menge an Zeit für das Prototyping außerhalb des Zeitplans zu finden, es sei denn, Ihr Unternehmen möchte die Ressourcenzuweisung für andere Projekte reduzieren.

Vollständiger Übergang zur neuen Anwendung

In diesem Modell werden alle Arbeiten an der alten Anwendung eingestellt, mit Ausnahme der Behebung kritischer Fehler, und die Arbeit an der Anwendung beginnt, die vollständig ersetzt wird. Dies ist, was Menschen normalerweise meinen, wenn sie über das Umschreiben einer Anwendung sprechen.



Vorteile:

• Die Mitarbeiter können sich auf das neue System konzentrieren, ohne das bestehende System wirklich zu berücksichtigen.
• Die Gesamtausführungszeit kann kürzer sein

Minuspunkte:

• Bei sehr kurzen Lieferzeiten hat das Unternehmen möglicherweise das Gefühl, Geld für das Projekt zu verschwenden.
• Verzögerungen bei den Fristen können die Lieferung der erforderlichen Arbeiten beeinträchtigen
• Tatsächlich wird dieser Ansatz zu einem Alles-oder-Nichts-Prinzip.
• Berücksichtigen Sie möglicherweise nicht alle Risiken, bevor Sie in ein neues Plattformprojekt investieren

Ergebnisse

Berücksichtigen Sie diese Optionen für die kontinuierliche Aktualisierung von Anwendungen sowie radikalere Optionen. Meiner Meinung nach gibt es keine beste Option. Sie müssen diejenige suchen, die für Ihr Team, Ihr Produkt und Ihre Organisation am besten geeignet ist. Bewerten Sie diese Ansätze und bestimmen Sie, welche Optionen für Sie am besten geeignet sind, wenn Sie eine „Fruchtfolge“ vorbereiten, um Ihre Codebasis langfristig gesund zu halten.