Technische Schulden mit DX und KI bewältigen

Jedes Unternehmen, groß oder klein, macht sich Sorgen über technische Schulden. Gartner schätzt, dass etwa 40% der Infrastruktursysteme dieses Problem haben. In einer Umfrage von McKinsey unter CIOs fühlten sich fast ein Drittel der Meinung, dass mehr als 20% ihres Neuprodukt-Budgets für die Lösung von Problemen im Zusammenhang mit technischen Schulden aufgewendet wurde. Aber im Gegensatz zu dem, was viele glauben, ist dies nicht nur ein Codierungsproblem, sondern auch ein Problem der Entwicklererfahrung (DX). Denn wenn Entwickler mit unzureichender Architektur, veralteter Tooling und unterdurchschnittlichen Entwicklungswerkzeugen arbeiten müssen, leiden Produktivität, Leistung und Moral.

Die Priorisierung von technischen Schulden unter Berücksichtigung der Entwickler, der Art und Weise, wie sie arbeiten, der Tools, die sie verwenden, und der Karrierechancen, die sie haben, hilft Teams, sich zu konzentrieren und schneller zu liefern. Dies ist der Grund, warum die Art und Weise, wie Unternehmen technische Schulden bewältigen, sich ändert, getrieben von DX und einer zunehmenden Fokussierung auf KI-gestützte Tooling.

DX fördern

Die Art und Weise, wie Entwickler oft aufgebaut werden, lässt viel zu wünschen übrig. Es kann einige Wochen dauern, bis jemand zum Projekt beiträgt. Sobald sie endlich kleine Funktionen oder Patches hinzugefügt haben, ist es nicht ungewöhnlich, dass der Continuous-Integration-(CI)-Dienst aufgrund von etwas vollkommen Unabhängigem von den Änderungen, an denen sie gearbeitet haben, fehlschlägt. Dies ist im Grunde genommen der Test-Suite-Fehler aufgrund von Qualitätsproblemen, und der Entwickler hat keine Änderungen vorgenommen, um die Test-Suite zu brechen. Es handelt sich um einen flaky, schlecht geschriebenen Test, der nur 90% der Zeit funktioniert. Das bestehende Team ist wahrscheinlich damit einverstanden – es verlangsamt nur die Prozesse –, aber die Tooling kann veraltet und demotivierend für jeden außerhalb der Organisation sein.

Dies ist nur eines von vielen Beispielen, die die richtige DX behindern. Eine Möglichkeit, dies zu verhindern, besteht darin, einen bestimmten Champion in Ihrem Software-Engineering- und Entwicklungsteam zu haben. Viele kleine Organisationen haben keinen DX-Leader, aber große, erfolgreiche Unternehmen haben sie. Diese Experten verfolgen Dinge wie die Zeit, die es einem neuen Entwickler benötigt, um eine Umgebung einzurichten. Und wenn zwei Wochen zu lang sind, finden sie heraus, wie sie diese Zeit halbieren können.

Es gibt Tooling, das helfen kann, wie CircleCI, mit nativen Funktionen, die die Flakiness einer Test-Suite verfolgen. Was benötigt wird, ist jemand, der die Führung übernimmt und nach jedem Sprint anhält, um einige der Änderungen anzusprechen, die den Code in Zukunft einfacher zu warten und zu arbeiten machen. Es kommt darauf an, einen Leiter zu haben, der daran interessiert ist, die DX zu verbessern. Um dies zu erreichen, suchen Sie nach einem senior-level-Ingenieur, begleitet von einem relativ neuen Mitarbeiter, der Feedback zu möglichen Lücken geben kann.

Außerdem erwartet IDC, dass der Markt für KI-gestützte Software-Testautomatisierung bis 2027 weiter mit einem CAGR von 31,2% wachsen wird, also stellen Sie sicher, dass Sie diese Technologie voll ausnutzen.

Metriken und Warnsignale

Es gibt viele Metriken, die Sie verfolgen können, wenn Sie bewerten, wie technische Schulden Ihr Team beeinträchtigen. Einige grundlegende Metriken sind “Zeit zum Fixen” oder “Zeit zur Funktion”. Nehmen wir an, Sie bemerken einen Bug und wissen, wie Sie ihn beheben können. Einige Tools können die Zeit verfolgen, die von der Codierung bis zur Produktion aufgewendet wird. Zum Beispiel könnten Sie sehen, dass ein sehr kleiner Patch zwei Geschäftstage zum Fixen und Versand benötigte, wenn Ihr Team in der Lage sein sollte, dies in Stunden zu tun. Sie können auch Verhältnisse wie die Anzahl der Bug-Fixes im Vergleich zu den abgeschlossenen Funktionen verfolgen.

Es gibt auch Möglichkeiten, um festzustellen, wenn Moralprobleme die Leistung Ihres Teams beeinträchtigen. DX-Leader können quartalsweise Umfragen durchführen, um zu bestimmen, wie zufrieden ein Entwickler mit der Arbeit an einem Projekt oder einem Teil davon ist. Sie können sich auf spezifische Bereiche wie den CI-Prozess konzentrieren. Und Sie können immer den Fluktuationsgrad oder die Fluktuation in Ihrem Team verfolgen. Wenn Sie bemerken, dass Menschen immer wieder gehen, könnten sie das Gefühl haben, dass ihre Bedenken nicht gehört werden.

Tooling mit KI

Der Aufstieg der KI-Tooling soll Entwickler und Ingenieure produktiver machen und Produkte schneller liefern, aber technische Schulden verlangsamen dies. Nehmen wir an, Sie verwenden ein Tool wie GitHub oder Copilot, um bei Code-Änderungen zu helfen, dann reichen Sie den Pull-Request ein und der CI benötigt ein paar Stunden, um zurückzukehren. In der Zwischenzeit arbeitet ein Entwickler an etwas anderem? Überprüft er E-Mails? Es handelt sich um einen Kontextwechsel und einen Produktivitätskiller.

Entwickler möchten an Produkten arbeiten, bei denen sie sich einfach auf den Code konzentrieren können. Die Tooling ist da, um ihnen zu helfen, es in die Produktion zu bringen, nicht um ein ständiges Hindernis zu sein. KI kann Zeit sparen, aber es liegt an den Ingenieursteams, ihre eigenen Standards für akzeptable Komplexität zu definieren. Um dies zu tun, stellen Sie zunächst sicher, dass jeder Code, der Ihrem Hauptzweig hinzugefügt wird, ein akzeptables Maß an technischen Schulden hat. Bevor Sie dies tun, führen Sie eine offene Diskussion und erhalten Sie die Zustimmung des Ingenieursteams zu dem akzeptablen Schwellenwert für technische Schulden und Code-Qualität. Stellen Sie sicher, dass jeder weiß, dass das Überschreiten dieses Schwellenwerts eine sofortige Sanierung erfordert. Sobald Sie diese Standards definiert haben, kommt die KI ins Spiel.

Es gibt einen Fall für KI-Agenten mit Ingenieuren als Orchestrierern. Eine Umfrage von Capgemini unter 1.100 Managern in großen Unternehmen hat ergeben, dass 82% planen, KI-Agenten in den nächsten drei Jahren zu integrieren, und sie haben bereits Auswirkungen auf die Zukunft der Arbeit. Sie könnten einen Bug-Bericht betrachten und sehen, dass er klein genug für einen KI-Agenten ist, um ihn von der Konzeption bis zur Code-Überprüfung zu bearbeiten, wodurch Ihrem Team Zeit gespart und es in die Lage versetzt wird, komplexere Arbeiten zu übernehmen. Es gibt jedoch manchmal, wenn wir diesen Tools blindlings folgen, Kompromisse, die die KI nicht berücksichtigen kann.

Dann wird die menschliche Meinung zum entscheidenden Faktor.

Technische Schulden mit Zielen ausrichten

Wie können Sie die Reduzierung von technischen Schulden mit den Zielen, die Sie erreichen möchten, oder messbaren Ergebnissen in Einklang bringen? Es geht zurück zu den akzeptablen technischen Schulden, und manchmal müssen Sie in der Geschäftswelt schnell liefern. Sie können dies tun, indem Sie wissen, dass ein Produkt nicht skaliert, und es möglicherweise Leistungsprobleme gibt, wenn die Zeit vergeht. Oft macht ein Entwickler eine Notiz, um später zu diesem Problem zurückzukehren, wenn es Zeit gibt, diese Probleme anzusprechen, aber das passiert selten. Und wenn diese schlechte Kultur überhandnimmt, in der Sie ständig morgen liefern müssen, wird der Einfluss der Schulden offensichtlich.

Das ist verständlich für ein Start-up, aber nicht für ein Unternehmen, das seit einem Jahrzehnt läuft. Sie müssen frühzeitig beginnen, Ihre Kultur zu ändern und aktiv technische Schulden zu bewältigen; andernfalls werden Sie viel Geld für die Behebung von Produktionsfehlern oder die Sorge um Sicherheit und Compliance ausgeben.

Schließlich gibt es Metriken, um den Wert der Refaktorierung oder der Tilgung von technischen Schulden gegenüber Stakeholdern zu kommunizieren. Zeit könnte eine davon sein, von der Konzeption bis zur Produktion oder von der Öffnung eines Pull-Requests bis zum Merge und Versand in die Produktion. Ein weiterer ist die mittlere Zeit bis zur Reparatur (MTTR). In diesem Fall könnten Sie einen Bug oder einen fehlerhaften Build gefunden haben und messen, wie lange es Ihrem Team dauert, ihn zu beheben. Sie könnten auch die Anzahl der Bugs in der Produktion verfolgen. Wenn Sie sehen, dass diese Zahl steigt, könnte es ein Problem im Zusammenhang mit technischen Schulden geben.

Technische Schulden mit Zinsen

Jede Organisation kann einige Stunden pro Woche aufwenden, um ihre DX zu verbessern und technische Schulden zu reduzieren. Wenn nicht, können Sie später dafür bezahlen, wahrscheinlich durch langsames Arbeiten, erhebliche Verlangsamung der Entwicklungsvelocity oder Sicherheitsprobleme. Zum Beispiel könnte Ihr Team von Ingenieuren und Entwicklern die Ruby-on-Rails-Upgrades für ein Jahrzehnt aufgeschoben haben. Plötzlich ist der Projektkaufpreis um eine halbe Million Dollar erhöht, weil die Ruby-Version vier Generationen zurückliegt, was Ihnen eine Masse an Code und veralteten Abhängigkeiten beschert.

Wenn Sie schrittweise upgegradet hätten, würden Sie nicht in dieser Situation sein. Also unterstützen Sie Ihr Software-Entwicklungsteam und zahlen Sie schrittweise. Andernfalls werden diese technischen Schulden Sie mit Zinsen heimsuchen.