Tech Debt: Was ist das und wie geht man damit um

Alle Teams müssen sich bei der Entwicklung eines Produkts mit Fristen, Budgets und anderen Einschränkungen auseinandersetzen.

Diese Parameter wirken sich alle auf die Entscheidungsfindung aus und führen zur Einführung von Tech-Schulden. Manchmal entstehen technische Schulden dadurch, dass man schnell ein Update veröffentlichen muss. In anderen Fällen kann es an mangelndem Verständnis oder mangelnder Erfahrung liegen. Unabhängig davon, was die Ursache ist, müssen Teams eine Möglichkeit haben, mit den technischen Schulden umzugehen, damit sie in Zukunft nicht zu sehr gebremst werden. Wenn Teams technische Schulden verstehen und sich darauf vorbereiten können, können sie Updates schneller veröffentlichen, ihre Codebasis in einem Zustand halten, mit dem sie leicht arbeiten können, und eine bessere Vorstellung von den Herausforderungen haben, denen sie in Zukunft gegenüberstehen werden.

Aber was ist Tech-Schulden?

Tech-Schulden sind zukünftige Arbeiten, die sich aus Entscheidungen ergeben, die während der Feature-Entwicklung und Bugfixes getroffen wurden. Es sind die Kompromisse, die wir eingehen, um ein Produkt zu entwickeln. Manchmal können die technischen Schulden ziemlich hoch sein; vielleicht muss ein System komplett neu konzipiert werden, weil die aktuelle Implementierung eine sehr große Benutzerbasis nicht bewältigen kann. In anderen Fällen kann es etwas Einfaches sein, wie das Refactoring einer Klasse oder Funktion, sobald sie erweitert werden muss.

Definition, Identifizierung und Bewertung technischer Schulden hebt 13 Arten von Technologieschulden hervor:

• Architekturverschuldung
• Schulden aufbauen
• Code Schulden
• Defekte Schuld
• Schulden entwerfen
• Dokumentation Schulden
• Infrastrukturverschuldung
• Schulden der Menschen
• Schulden verarbeiten
• Anforderung: Schulden
• Serviceverschuldung
• Testen Sie Automation Debt
• Schulden testen

Eine eingehendere Diskussion zu diesem Thema finden Sie unter Auf dem Weg zu einer Ontologie von Begriffen zur technischen Verschuldung, auf dem der obige Blogbeitrag basiert, aber hinter einer Paywall existiert

Woher kommen Tech-Schulden?

Die kurze Antwort lautet: Jedes Mal, wenn eine Produktentscheidung getroffen wird, sind technische Schulden damit verbunden. Bei dieser Entscheidung kann es darum gehen, einer neuen Funktion Priorität einzuräumen, das Design zu aktualisieren, das Backend zu ändern usw. Das mag zwar schlecht klingen, aber technische Schulden sind nicht unbedingt eine schlechte Sache, da sich Systeme an die sich ändernden Bedürfnisse anpassen sollten. Ein System kann so eingerichtet werden, dass es mit einer kleinen Benutzerbasis umgehen kann, um Geld zu sparen, da man weiß, dass es aktualisiert werden muss, wenn die Benutzerbasis zunimmt. Die durch diese Entscheidung verursachte Verschuldung wäre wahrscheinlich eine Architekturschuld. Wenn sich das System ändert und Sie wissen, dass Sie die Dokumentation aktualisieren müssen, haben Sie Dokumentationsschulden.

Wie können wir Tech-Schulden verwalten?

Der erste Schritt besteht darin, besser zu verstehen, welche Konsequenzen Ihre Entscheidungen haben werden. Wenn Sie im Voraus wissen, wie hoch die technischen Schulden sind, können Sie sie planen. Abhängig von Ihrer Rolle sollten Sie sich nur um einen Teil der 13 Arten von Tech-Schulden kümmern müssen. Sykorax, Das Team, in dem ich bin, kam auf die Idee, ein Zustand der Basis alle paar Monate nach wichtigen Meilensteinen.

Zustand der Basis

Das Sycorax-Team stand kurz davor, mit der Arbeit an einem neuen Projekt zu beginnen, und die Entwickler wollten besser vorbereitet sein. Während wir auf das zurückblickten, was wir bereits gemacht hatten und wie wir die gewonnenen Erkenntnisse anwenden konnten, beschlossen wir, einige unserer Beschwerden und Probleme mit dem ersten Projekt aufzulisten. Wir haben dieses Konzept speziell für den Umgang mit Code-, Dokumentations- und Architekturschulden entwickelt, aber es kann optimiert und auf jede Art von technischen Schulden angewendet werden.

Wir haben ein Dokument erstellt, um einige der Probleme aufzuzeichnen und uns Zeit zu nehmen, um sie zu besprechen und zu erfahren, wie die Probleme verbessert oder in Zukunft vermieden werden können. Wir haben uns schließlich für eine einfache Tabelle mit 5 Spalten entschieden:

Probleme/ÄnderungsnotizenLift (1-10) Priorität (1-10) Ticket (s) erhöhen die Beobachtbarkeit robustere Logs erleichtern uns das Aufspüren von Problemen28Ticketlinkhinzufügen Snapshot-TestenDies kann das Schreiben und Aktualisieren unserer Komponententests einfacher11ticket-Link

Die Entwickler können dieses Dokument jederzeit ergänzen, wenn etwas auftaucht, das sie verbessern oder mit dem sie sich befassen möchten. Dies hilft uns, bei der Arbeit an den Funktionen auf dem Laufenden zu bleiben, während wir neue Tickets erstellen und darauf hinweisen, PRs überprüfen oder einfach nur an Teilen der Codebasis arbeiten, ohne dass technische Schulden durch das Raster fallen. Die obige Tabelle enthält zwei Beispiele. Wir haben festgestellt, dass jedes ziemlich einfach ist, aber die Prioritäten waren unterschiedlich. Die Verbesserung unserer Protokolle kann uns helfen, einen Fehler für unsere Kunden zu diagnostizieren. Je früher wir es finden, desto eher können wir es lösen. Die zweite dient lediglich dazu, das Schreiben von Tests ein wenig zu vereinfachen. Es lohnt sich vielleicht nicht, unsere bestehenden Tests zu ändern, aber es ist etwas, das Sie für zukünftige Tests berücksichtigen sollten.

Vorteile von State of the Base

• Arbeit, die für das Team wertvoll ist, bleibt verfügbar, auch wenn epic-spezifische Tickets blockiert werden könnten
• Alle Verbesserungen, die nichts mit Funktionen zu tun haben, sind übersichtlich an einem Ort priorisiert
• Beugt Abzweigungen bei technischen Diskussionen vor und hilft dem Team, konzentriert zu bleiben
  • Dieser Vorteil erstreckt sich auch auf PRs, wenn Bedenken auftauchen, die nicht in den Geltungsbereich fallen, und sollten angemessen inszeniert werden, damit sie weiterverfolgt werden können.
• Ermutigt zur Eigenverantwortung, indem sichergestellt wird, dass Raum für die Überprüfung aller Verbesserungsvorschläge geschaffen wird
• Ermutigt zu konsistenten Verbesserungen der Code-Wartbarkeit

Das klingt großartig, aber wir haben keine Zeit, mehr Arbeit hinzuzufügen...

Tech-Schulden bedeuten mehr Arbeit, unabhängig davon, ob Sie dies planen oder nicht. Das System kann den Verkehr nicht mehr bewältigen, die „schnelle Lösung“ hatte Nebenwirkungen, mit denen Sie nicht gerechnet hatten, mit denen Sie sich jetzt aber auseinandersetzen müssen usw. Die Tech-Schulden werden auf Sie zukommen! Wenn Sie dies verstehen und planen, können Sie sich früher und möglicherweise schneller mit technischen Schulden befassen, als wenn das Problem auftaucht und die Produktion unterbrochen wird. Das bedeutet nicht, dass Sie ständig versuchen müssen, die technischen Schulden auf Kosten von Produktverbesserungen zu bewältigen. Wir schreiben alle unsere State of the Base-Tickets auf und speichern sie im Backlog, damit die Entwickler sie abholen können, wenn es die Zeit erlaubt. Durch das Hinzufügen der Lift- und Prioritätsspalten können wir die Tickets besser an unseren PM anpassen. Wenn sich das Team Zeit nimmt, um die technischen Schulden zu besprechen und festzustellen, was behoben werden muss und was behoben werden sollte, kann das Team erklären, warum die Änderungen erforderlich sind. Dies ist besonders wichtig, wenn Dinge vorgeschlagen werden, die die Benutzerinteraktion nicht ändern, wie z. B. das Aktualisieren des Datenbankschemas.

Fazit

Ob du dich entscheidest, State of the Base zu adoptieren oder dir dein eigenes einfallen zu lassen Methoden, das Verständnis und die Planung von Tech-Schulden sollten Teil Ihres Entscheidungsprozesses sein. Wenn Sie wissen, welche Probleme sich aus Ihren Entscheidungen ergeben, können Sie bessere Entscheidungen treffen und besser auf zukünftige Änderungen vorbereitet sein.