Gibt es einen Zusammenhang zwischen technischer Verschuldung und Geschwindigkeit?

TL;DR

Velocity und Technical Debt sind nicht direkt korreliert, und Velocity kann Technical Debt nicht direkt messen. Geschwindigkeit kann jedoch (bei richtiger Implementierung) als Detektivkontrolle dienen, um versteckte Schulden aufzudecken.

Technische Schulden sind nicht unbedingt schlecht. Genau wie bei der finanziellen Hebelwirkung gibt es gute und schlechte Schulden. Die Aufnahme von Schulden, die sich das Projekt leisten kann, kann eine notwendige Entscheidung sein, um kurzfristige Ziele zu erreichen. Es ist nur wichtig, nur Schulden aufzunehmen, die sich das Projekt leisten kann und die das Team zurückzahlen kann!

Das Hauptproblem bei technischen Schulden ist, wenn sie unsichtbar sind. Das Gesetz der Transparenz℠ von CodeGnome besagt: „Keine unsichtbare Arbeit, niemals!“ Sichtbare Schulden verringern Ihre Geschwindigkeit nicht, können aber die Geschwindigkeit verringern, mit der neue Funktionen bereitgestellt werden können. Unsichtbare Arbeit wirkt sich negativ auf die Geschwindigkeit aus, was eine frühzeitige Warnung ist, dass es möglicherweise unbekannte oder unerwartete technische Schulden gibt, die auftauchen und vom gesamten Scrum-Team angegangen werden sollten.

Technische Schulden definiert

Wikipedia definiert technische Schulden derzeit wie folgt (fette Hervorhebung von mir):

Technische Schuld (auch als Designschuld 1 oder Codeschuld bekannt) ist ein Konzept in der Softwareentwicklung, das die implizierten Kosten zusätzlicher Nacharbeit widerspiegelt, die dadurch entstehen, dass man sich jetzt für eine einfache Lösung entscheidet, anstatt einen besseren Ansatz zu verwenden, der länger dauern würde.

Technische Schulden können mit monetären Schulden verglichen werden. Wenn technische Schulden nicht zurückgezahlt werden, können sich „Zinsen“ anhäufen, was die spätere Umsetzung von Änderungen erschwert. Unadressierte technische Schuld erhöht die Softwareentropie. Technische Schuld ist nicht unbedingt etwas Schlechtes, und manchmal (z. B. als Proof-of-Concept) ist technische Schuld erforderlich, um Projekte voranzubringen. Auf der anderen Seite behaupten einige Experten, dass die Metapher der „technischen Schulden“ dazu neigt, die Auswirkungen zu minimieren, was zu einer unzureichenden Priorisierung der notwendigen Arbeiten zu ihrer Behebung führt.

Wenn eine Änderung an einer Codebasis begonnen wird, besteht häufig die Notwendigkeit, gleichzeitig andere koordinierte Änderungen in anderen Teilen der Codebasis oder Dokumentation vorzunehmen. Erforderliche Änderungen, die nicht abgeschlossen sind, gelten als Schulden, die irgendwann in der Zukunft bezahlt werden müssen. Genau wie Finanzschulden verursachen diese nicht abgeschlossenen Änderungen Zinsen zusätzlich zu den Zinsen, was den Aufbau eines Projekts umständlich macht. Obwohl der Begriff hauptsächlich in der Softwareentwicklung verwendet wird, kann er auch auf andere Berufe angewendet werden.

In der Praxis können technische Schulden bekannt oder unbekannt und sichtbar oder unsichtbar sein. Bekannte und sichtbare Schulden können innerhalb Ihres Projekts explizit verfolgt werden oder nicht, obwohl dies sicherlich der Fall sein sollte .

Technische Schulden und Geschwindigkeit

Geschwindigkeit ist eine agile Metrik, die in erster Linie die Arbeitskapazität misst , die wahrscheinlich innerhalb einer einzigen Iteration abgeschlossen werden kann. Die zentrale Idee ist, dass historische Messungen geglättet werden können (oft durch Ausdrücken der Geschwindigkeit als Bereich oder gleitender Durchschnitt), um einigermaßen genaue (z. B. „gut genug“) kurzfristige Prognosen zu erstellen.

Es gibt im Allgemeinen zwei Klassen von technischen Schulden: sichtbare und unsichtbare. Im Folgenden werden die beiden Klassen verglichen.

Sichtbare und bekannte technische Schulden

Velocity misst technische Schulden nicht direkt. Wenn Sie Ihre technische Schuld explizit nachverfolgen und als Arbeit am Product Backlog sichtbar machen (wie Sie es sollten), dann werden die Hauptkosten der technischen Schuld oft wie folgt angezeigt:

1. Verstärkte Zuordnung von Teamkapazität zu "Schuldenzahlungen" in Form von Aufgaben und explizitem Refactoring bei steigender Verschuldung, im Allgemeinen auf Kosten neuer Funktionen.
2. Eine allgemeine Erhöhung der Größe der Teamschätzungen unter Berücksichtigung des impliziten Refactorings und des zusätzlichen Spielraums, der erforderlich ist, um die Folgeeffekte der Schulden zu bewältigen.
3. Eine scheinbare (wenn auch nicht unbedingt reale) Verringerung des Stakeholder-Werts bei jeder folgenden Iteration, da immer mehr Teamkapazität für die „Schuldenzahlungen“ aufgewendet wird, die erforderlich sind, um die Funktionen zu entwickeln oder das Projekt vor dem Zusammenbruch unter der Last seiner technischen Schulden zu bewahren.

Da die Schulden sichtbar sind und nachverfolgt werden können, wirkt sich dies im Allgemeinen überhaupt nicht auf die tatsächliche Geschwindigkeit des Teams aus. Stattdessen kann es den wahrgenommenen Wert dieser Geschwindigkeit beeinträchtigen, da es das Tempo der Bereitstellung neuer Funktionen verlangsamt. 20 Arbeitspunkte liefern vielleicht nicht mehr 20 Punkte Stakeholder-Wert, aber die tatsächliche Anstrengung, die das Team bei jeder Iteration aufwenden kann, wird sich nicht wirklich ändern.

Unsichtbare oder unbekannte technische Schuld

Die Kosten für unsichtbare Schulden – oder noch schlimmer, unbekannte technische Schulden – werden oft in Form einer unerwarteten Produktivitätseinbuße ausgezahlt . Wenn die Belastung der Produktivität groß genug wird und lange genug unsichtbar bleibt, führt dies schließlich zu:

1. Eine zunehmende Unfähigkeit, die Kapazität genau vorherzusagen.
2. Eine zunehmende Häufigkeit von Iterationen, die die Team- oder Stakeholder-Ziele nicht erreichen.
3. Ein Verlust des Vertrauens der Stakeholder in das Team.
4. Ein allgemeiner Vertrauensverlust in den Rahmen des Projektmanagements.

Kurz gesagt, anstatt die Implementierung des Rahmenwerks zu beschuldigen, wird das Rahmenwerk selbst (und höchstwahrscheinlich das Team, das zulässt, dass diese Schulden unsichtbar bleiben) für den mangelnden Fortschritt verantwortlich gemacht. Dies wird in agilen Implementierungen, die den Stakeholder-Wert nur bei der Geschwindigkeitsmessung verfolgen, enorm verstärkt. Wenn der Aufwand für jedes Feature steigt, wird die scheinbare Geschwindigkeit sinken, da die Kapazität des Teams für benutzersichtbare Features dramatisch abnimmt, da die unsichtbaren technischen Schulden mit jedem Sprint verstärkt werden.

Allgemeine Hinweise

Die Geschwindigkeit ist nur eine Metrik unter vielen. Verlassen Sie sich bei der Messung Ihres Projekts nicht nur auf die Velocity, aber verwerfen Sie sie auch nicht als irrelevant. Hier ist meine Top-Ten-Liste mit Vorschlägen für die Verwendung von Velocity und anderen Techniken zum Messen oder Aufdecken von technischen Schulden:

1. Verwenden Sie die Geschwindigkeit, um den Aufwand zu messen , nicht den Stakeholder-Wert.
2. Verwenden Sie Geschwindigkeit, um die Teamkapazität zu prognostizieren , nicht den potenziell lieferbaren Wert.
3. Identifizieren Sie technische Schulden so schnell wie möglich während jeder Iteration, einschließlich bei der Sprint-Planung, der Backlog-Verfeinerung und der Sprint-Überprüfung.
4. Halten Sie bekannte technische Schulden für das Entwicklungsteam, den Product Owner und alle Beteiligten jederzeit sichtbar.
5. Technische Schulden nur bewusst und mit informierter Zustimmung des gesamten Scrum-Teams (und idealerweise auch der Stakeholder) eingehen. Sie müssen es alle zusammen zurückzahlen!
6. Verfolgen Sie alle bekannten Arbeiten (einschließlich technischer Schulden) als Einträge im Product Backlog.
7. Überprüfen Sie Ihr Sprint-Backlog am Ende jedes Sprints, um neue Quellen für technische Schulden zu identifizieren.
8. Unterscheiden Sie in Ihren rohen Geschwindigkeitsmessungen nicht zwischen Aufgaben, Fehlern, Funktionen usw., da sie alle Zeit, Mühe und Ressourcen des Teams erfordern.
9. Überprüfen Sie unerwartete Zunahmen an Zeit, Aufwand und Ressourcen, da dies das Ergebnis unsichtbarer Technologieschulden sein kann.
10. Suchen Sie nach unsichtbaren technischen Schulden, wenn ein Sprintziel verfehlt wird oder die Geschwindigkeit unerwartet abfällt.

Velocity an sich kann technische Schuld aufdecken oder auch nicht, kann aber durchaus als Früherkennungssystem für unsichtbare Arbeit dienen. Solange Sie bestrebt sind, die gesamte Arbeit sichtbar zu halten, Ihren Prozess transparent zu halten und alle Prüf- und Anpassungszyklen Ihres Frameworks effektiv zu nutzen, werden Sie in der Regel nicht von technischen Schulden überrascht . Sie können immer noch Schulden anhäufen, und unbezahlte Schulden können Ihr Projekt immer noch zum Sinken bringen, aber zumindest werden das Team und die Beteiligten nicht überrascht sein!

Verfolgen Sie alle Arbeiten, die Teamkapazitäten verbrauchen (einschließlich aller Dinge, die Sie als technische Schulden klassifizieren), als erstklassiges Element in Ihrem Product Backlog. Genau wie bei Finanzschulden ist die Wahrscheinlichkeit, dass Sie „pleite gehen“, viel geringer, wenn Sie Ihre Ausgaben genau im Auge behalten und belastende Zinszahlungen vermeiden.

Abhängig davon, wie Sie mit technischen Schulden umgehen möchten, wird bestimmt, ob dies Ihre Geschwindigkeit beeinflusst. Du hast, soweit ich das sehe, mehrere Möglichkeiten:

1. Weisen Sie technischen Schulden keine Story Points in einem separaten „Problem“ zu.

Wenn Sie technische Schulden ohne Story Points übernehmen, z. B. in einer separaten Aufgabe, werden Sie einen Geschwindigkeitsabfall für diesen Sprint feststellen. Das ist zu erwarten, weil mit der technischen Schuld keine Story Points verbunden sind.

2. Weisen Sie technische Schulden in einem separaten "Problem" Story Points zu

Dadurch wird die Geschwindigkeit nicht beeinflusst, da die Story Points bei der Berechnung der Geschwindigkeit verwendet werden. Wenn Sie dies konsequent tun, wird Ihnen eine Geschwindigkeit angezeigt, und wenn die technische Schuld in Story Points korrekt geschätzt werden kann, sollten Sie in der Lage sein, die Arbeit zu planen

3. Schließen Sie die Behebung der technischen Schuld in die Geschichte ein, für die sie gelöst werden muss. Wenn Sie eine Geschichte haben, die nicht geliefert werden kann, bis die technische Schuld gelöst ist, schließen Sie die Arbeit in die Schätzung der Geschichte ein. Wenn das bedeutet, dass die Story zu groß wird, um sie in einem Sprint zu bewältigen, erstellen Sie ein Epic und teilen Sie die Story in kleinere Teile auf und verbinden Sie sie mit dem Epic. Dies ist meine Präferenz, da es zeigt, was getan werden muss, um ein Feature zu implementieren, und Sie können Abhängigkeiten in den unter dem Epos aufgeführten Geschichten angeben.

Es besteht sowohl kurz- als auch langfristig ein starker Zusammenhang zwischen technischer Verschuldung und Umlaufgeschwindigkeit.

Ein Team könnte möglicherweise seine kurzfristige Geschwindigkeit erhöhen, indem es technische Schulden anhäuft. Tatsächlich schieben sie Dinge auf, damit sie den Anschein eines schnelleren Fortschritts erwecken können.

Langfristig kann die Anhäufung technischer Schulden die Geschwindigkeit nach unten ziehen, da sie die Entwicklung erschwert.

Ein Schlüsselaspekt der technischen Schuld ist die Transparenz des Entscheidungsprozesses .

Das heißt, wenn ein Team neue technische Schulden aufnimmt oder bestehende technische Schulden erkennt, sollte es eine klare und sichtbare Entscheidung darüber treffen, was damit zu tun ist.

Beispielsweise könnte ein Team beschließen, die Lösung einiger anspruchsvoller technischer Schulden aufzuschieben, weil eine Veröffentlichung bevorsteht. Sie würden die Auswirkungen anerkennen und sichtbar machen, die dies auf die langfristige Leistung des Teams haben wird, und sie könnten auch entscheiden, der Begleichung der Schulden nach der Entlassung Priorität einzuräumen.