Kennzahlen und KPIs für die Agile Softwareentwicklung zur Optimierung der Produktbereitstellung

Lesezeit: 13 Minuten

Der agile Ansatz für die Softwareentwicklung ist seit langem üblich. Laut der HP Online-Umfrage entscheiden sich 16 Prozent der IT-Experten für pure Agile, 51 Prozent für die IT und 24 Prozent für einen agilen Hybridansatz. Heute wird die Wasserfallentwicklung am häufigsten als agiles Unterscheidungsmerkmal erwähnt, was Agile nicht ist. Wir haben die Hauptunterschiede in unserem Whitepaper zu agilen Projektmanagement-Methoden ausführlich diskutiert.

Trotz der Anpassungsfähigkeit und Flexibilität des agilen Managements und seiner schnellen Reaktion auf Änderungen kann der Workflow zentralisiert und kontrolliert bleiben. Agile KPIs (Key Performance Indicators) geben Orientierung bei der strategischen Planung, Bewertung und Verbesserung operativer Prozesse.

Traditionelle Wertmanagementsysteme tendieren dazu, sich auf die Erledigung von Aufgaben im Rahmen von kategorischem Zeitplan und Kosten zu konzentrieren. Mit Agile sehen Kunden und Teammitglieder jedoch sofortige Ergebnisse und passen Zeitrahmen und Aufwand an, um ein Produkt zu liefern, das den Zeitplananforderungen entspricht. Welche Werkzeuge und Techniken erfordert dieses Wissen? Hier ist unser Überblick über die Leistungsbewertung von Agile Development Metrics.

Agile Softwareentwicklungs-KPIs

In diesem Artikel werden wir nicht alle möglichen agilen Entwicklungsmetriken und KPIs untersuchen. Darüber hinaus können Sie Ihre eigenen erfinden, die am besten zu Ihrem Projekt passen. Wir werden jedoch die häufigsten KPIs beschreiben, die für mehrere Aspekte der Softwareentwicklung verwendet werden:

• Geschwindigkeit
• Sprint-Burndown
• Release-Burndown
• Zykluszeit
• Kumulativer Fluss
• Flusseffizienz
• Codeabdeckung durch automatisierte Tests
• Testautomatisierung gegen manuelles Testen
• McCabe Zyklomatische Komplexität (MCC)
• Code-Abwanderung

Messung der laufenden Arbeit

Geschwindigkeit

Geschwindigkeit misst den Arbeitsaufwand (eine Reihe von Funktionen), der in einem Sprint erledigt wurde. Velocity ist zwar kein Vorhersage- oder Vergleichstool, bietet Teams jedoch eine Vorstellung davon, wie viel Arbeit im nächsten Sprint erledigt werden kann.

Der Velocity-Index ist für jedes Team einzigartig und sollte festgelegt werden, um zu beurteilen, wie realistisch das Engagement ist. Wenn das Projekt-Backlog beispielsweise 200 Story Points hat und das Team durchschnittlich 10 Story Points pro Sprint abschließt, bedeutet dies, dass das Team etwa 20 Sprints benötigt, um das Projekt abzuschließen.

Je länger Sie die Geschwindigkeit verfolgen, desto höher ist die Genauigkeit der Übereinstimmung zwischen Verpflichtungen und Kosten

Für ein Team, das gerade die agile Methodik übernommen oder sogar ein neues Produkt entwickelt hat, sind die Geschwindigkeitsschätzungen der ersten Sprints wahrscheinlich unregelmäßig. Wenn die Teams jedoch Erfahrung sammeln, wird die Geschwindigkeit ihren Höhepunkt erreichen und dann ein Plateau mit vorhersehbarem Fluss und Leistungserwartung erreichen. Eine Abnahme des gleichmäßigen Flusses weist auf Probleme in der Entwicklung hin und zeigt die Notwendigkeit von Änderungen auf.

Tipps zur Verwendung der Geschwindigkeitsmetrik

Inkonsistenz nach 3-5 Sprints bekämpfen. Wenn die Geschwindigkeit nach langer Zeit inkonsistent bleibt, sollten Sie sowohl externe als auch interne Faktoren berücksichtigen, die eine klare Schätzung verhindern.

Ändert die Geschwindigkeitsverfolgung nach Team- und Aufgabenänderungen. Wenn ein Teammitglied das Projekt verlässt oder weitere Mitglieder / Aufgaben hinzugefügt werden, berechnen Sie die Geschwindigkeit neu oder starten Sie die Berechnung vollständig neu.

Drei Sprints reichen für frühe Prognosen. Verwenden Sie zur Vorhersage der zukünftigen Leistung den Durchschnitt der drei vorherigen Sprints.

Sprint-Burndown-Chart

Das Sprint-Burndown-Chart zeigt an, wie viel Arbeit vor dem Ende eines Sprints noch zu erledigen ist. Das Tool ist besonders wertvoll, da es den Fortschritt auf dem Weg zum Ziel anzeigt, anstatt abgeschlossene Elemente aufzulisten. Es ist auch sehr nützlich, um Planungsfehler aufzudecken, die ein Team zu Beginn eines Sprints gemacht hat.

Auf dem Chart darunter repräsentiert die schwarze Linie die prognostizierte (ideale Trend-) Linie, die zeigt, mit welcher Geschwindigkeit das Team Story Points abbrennen muss, um den Sprint pünktlich abzuschließen. Die blaue Linie zeigt den Gesamtaufwand und den Fortschritt während des Sprints an. Sie können sehen, dass es einem Team an den Tagen fünf und sechs nicht gelungen ist, die prognostizierten Fortschritte zu erzielen. Am siebten Tag wurde das Problem jedoch behoben und die Arbeit war wieder auf Kurs. Solche laufenden Updates ermöglichen es Teams, aufkommende Probleme während der täglichen Stand-up-Meetings anzugehen.

Neben der Arbeitsleistung selbst können Burndown-Diagramme Planungsprobleme aufdecken

Tipps zum Sprint-Burndown

Story Points sollten gleichmäßig sein. Wenn der Workflow nicht konsistent ist, wurden einige Aufgaben möglicherweise in ungleiche Abschnitte unterteilt. Das Ausmaß der Abweichung zwischen einem idealen Trend und der Realität hebt dieses Problem deutlich hervor.

Konto für ungeplante Aufgaben. Das Burndown-Diagramm ist nützlich, um den Umfang versteckter und nicht verfolgter Aufgaben zu verstehen. Wenn der Arbeitsaufwand zunimmt, anstatt abzunehmen, hat das Projekt viele nicht geschätzte oder ungeplante Aufgaben, die angegangen werden sollten.

Verwenden Sie ein Burndown-Diagramm, um das Vertrauen des Teams zu bewerten. Fragen Sie Ihr Team angesichts der aktuellen Raten, wie zuversichtlich es ist, den Sprint pünktlich abzuschließen. Je länger Sie diese Metrik anwenden, desto genauer sind Ihre Sprintschätzungen.

Schätzen des Releases mit einem Burndown-Chart

Ein Release-Burndown-Chart gibt an, wie viel Arbeit vor einem Release erledigt werden muss. Das Diagramm veranschaulicht die Fortschrittsübersicht und ermöglicht es Ihnen, Änderungen zu implementieren, um die pünktliche Lieferung sicherzustellen.

Eine traditionelle Version des Diagramms ähnelt dem Sprint-Burndown-Diagramm, gibt jedoch einen Überblick über das gesamte Projekt, wobei die Y-Achse Sprints und die x-Achse ein Maß für die verbleibende Arbeit (Tage, Stunden oder Story Points) ist. Aber was ist, wenn dem Projekt mehr Arbeit hinzugefügt wird oder Ihre geschätzte Arbeit nicht den Erwartungen entspricht?

In der folgenden Tabelle plante ein Team, ein Projekt in vier Sprints abzuschließen, und hatte zunächst 45 Story Points. Während der Fortschritt im ersten und zweiten Sprint wie geplant verlief, stieg beim dritten Sprint die geschätzte Arbeit, was sich auf der y-Achse in negativen Werten widerspiegelt. Während des dritten Sprints erschienen 5 neue Story Points. Sie wurden nicht abgeschlossen und der vierte Sprint fügte weitere 5 Story Points hinzu. Daher mussten der Fortschritt und die Freigabezeit angepasst werden.

Das Release-Burndown-Diagramm ist sehr effektiv für Situationen mit vielen sich ändernden Anforderungen und ermöglicht es einem Team, während jedes Sprints auf dem richtigen Weg zu bleiben

Wie kann das Release-Burndown-Diagramm helfen?

Echtzeitvorhersage bei Veröffentlichung. Sobald Ihr Projekt Änderungen erfährt, die jedes Mal bei der iterativen Entwicklung von Produkten auftreten, müssen Sie sehen, wie sich diese Änderungen auf das Veröffentlichungsdatum auswirken. Das Release-Burndown-Diagramm ermöglicht die Vorhersage des Veröffentlichungsdatums in Echtzeit gemäß Aktualisierungen im Arbeitsumfang.

Terminvorhersagen. Sie können abschätzen, ob das Team eine Produktfreigabe rechtzeitig abschließen kann, oder davon ausgehen, dass sich die Frist unter Berücksichtigung zusätzlicher Aufgaben weiter verschieben sollte.

Schätzen der Anzahl der Sprints. Die Beurteilung, wie viele Sprints erforderlich sind, um die Arbeit zu beenden, ist ebenfalls ein wichtiger Faktor, der beim Release-Burndown-Diagramm berücksichtigt werden muss.

Bewertung des Prozesszustands und Auffinden von Engpässen

Zykluszeit

Die Zykluszeit-Metrik beschreibt, wie viel Zeit für eine Aufgabe aufgewendet wurde, einschließlich jedes Mal, wenn die Arbeit erneut geöffnet und erneut abgeschlossen werden musste. Die Berechnung der Zykluszeit liefert Informationen über die Gesamtleistung und ermöglicht die Abschätzung der Fertigstellung zukünftiger Aufgaben. Während die kürzere Zykluszeit eine bessere Leistung veranschaulicht, werden die Teams, die innerhalb eines konsistenten Zyklus liefern, am meisten geschätzt.

Anhand des folgenden Diagramms können Sie die durchschnittliche Zeit ermitteln, die zum Ausführen einer Aufgabe benötigt wird, einen Median oder eine Kontrollgrenzlinie zeichnen, die nicht überschritten werden sollte, und feststellen, welche Aufgaben ungewöhnlich lange gedauert haben.

Die Standardabweichung zeichnet eine Linie zwischen der normalen und der nicht empfohlenen Anzahl von Tagen zum Ausführen der Aufgabe

Sie können auch alle Zyklen für einen bestimmten Zeitraum stapeln und Erkenntnisse aus dem Vergleich mit anderen Daten ziehen. Durch eine weitere Untersuchung können Sie Rückschlüsse auf die Qualität der Arbeit ziehen.

Hier sehen Sie, dass die Anzahl der abgeschlossenen Aufgaben von März bis Juni ebenso gestiegen ist wie die Anzahl der Fehler

Verwendung der Zykluszeit

Suchen Sie nach Ähnlichkeiten. Eine gute Praxis besteht darin, ähnliche Elemente zu finden, deren Fertigstellung unvorhersehbare Zykluszeiten in Anspruch nimmt und wiederkehrende Probleme entweder im Engineering oder im Management aufdeckt.

Vorhersagen zeichnen. Sie können datengesteuerte Entscheidungen treffen, indem Sie die Zeit für die Erledigung neuer Aufgaben basierend auf ähnlichen Aufgaben aus der Vergangenheit vorhersagen.

Verfolgen Sie das Tempo. Das Diagramm beschreibt, wie Sie das gleiche Arbeitstempo beibehalten und definieren, ob es interne Probleme gibt, die die Arbeitsgeschwindigkeit verringern.

Kumulatives Flussdiagramm (CFC)

Die kumulative Flussmetrik wird durch den Diagrammbereich beschrieben, der die Anzahl der verschiedenen Arten von Aufgaben in jeder Phase des Projekts anzeigt, wobei die x-Achse die Daten und die y-Achse die Anzahl der Story Points angibt. Das Hauptziel besteht darin, eine einfache Visualisierung der Verteilung von Aufgaben in verschiedenen Phasen bereitzustellen. Die Linien auf dem Chart sollten mehr oder weniger gleichmäßig bleiben, während das Band mit den „erledigten“ Aufgaben kontinuierlich wachsen sollte.

Das Diagramm enthält viele kritische Informationen wie plötzliche Engpässe oder Anstiege in einem der Bänder

Der CFC wird für Kanban-Teams als einfache Visualisierung der Teamarbeit von großem Nutzen sein. Das Diagramm entspricht auch dem dreistufigen Workflow von Kanban. Hier ordnen Sie auch drei Hauptaufgabenkategorien zu: To-do, in Bearbeitung und abgeschlossen.

Darüber hinaus hilft das Diagramm zu erkennen, wann die Work-in-Progress-Grenzwerte (WIP) überschritten werden. Als eines der wertvollsten Tools in der agilen Entwicklung sollen WIP-Limits die Kultur des Abschlusses von Arbeiten fördern und Multitasking eliminieren, indem der maximale Arbeitsaufwand für jeden Projektstatus festgelegt wird.

Auf welche Probleme weist der FCKW hin?

• Das Backlog-Wachstum zeigt die ungelösten Aufgaben an, die entweder eine zu niedrige Priorität haben, um sie im Moment anzugehen, oder veraltet sind
• Inkonsistenter Fluss und plötzliche Engpässe geben an, welche Bereiche in späteren Phasen geglättet werden sollten
• Die Breite jedes Bandes zeigt die durchschnittliche Zykluszeit an
• Die signifikante Erweiterung des Bereichs „In Bearbeitung“ kann dazu führen, dass das Team das gesamte Projekt pünktlich

Durchflusseffizienz

Durchflusseffizienz ist eine sehr nützliche Metrik in der Kanban-Entwicklung, die von der Entwicklung meist übersehen wird Forschungsteams. Während die Flusseffizienz den kumulativen Fluss ergänzt, gibt sie Einblicke in die Verteilung zwischen tatsächlicher Arbeit und Wartezeiten. Es ist ein seltener Fall, wenn ein Entwickler an einer Sache arbeitet, ohne zu warten. Die Realität ist in der Regel komplexer. Und „Work-in-progress“ ist ein Name, der nicht immer mit dem Status übereinstimmt.

Zum Beispiel kann der Code viele Abhängigkeiten haben und Sie können nicht mit einer Funktion arbeiten, bevor eine andere beendet ist, oder Ihre Prioritäten ändern sich oder Sie warten auf die Genehmigung eines Stakeholders. Das Messen, wie viel Zeit Sie auf die Arbeit warten, kann noch nützlicher sein als das Rationalisieren von Prozessen im Zusammenhang mit der tatsächlichen Arbeit.

Durch blick auf die niedrigsten effizienz indikatoren, sie können verstehen die wichtigsten engpässe

Wie zu verwenden fluss effizienz

Berechnung formel. Wenn Sie keine Projektmanagement-Software anwenden, die diese Metriken enthält, können Sie die Flusseffizienz anhand dieser einfachen Formel berechnen: Arbeit / (Arbeit + Warten) * 100%. Dann können Sie es digital visualisieren oder sogar die Grafik auf Ihrem Büro-Whiteboard zeichnen.

Definieren Sie Ihre normale Durchflusseffizienz. Wie bei allen anderen Metriken ist es unmöglich, normale Zahlen für alle Projekte zu beanspruchen. Einige sagen, dass die 15-Prozent-Marke für die meisten Projekte in Ordnung ist, was im Grunde bedeutet, dass ein Story Point oder ein anderes Arbeitselement 85 Prozent gegenüber 15 Prozent Bearbeitungszeit wartet. David J. Anderson, ein Managementexperte der LeanKanban School of Management, schlägt vor, dass 40 Prozent und mehr das Ziel für die meisten Teams sein sollten.

Zerlegen Sie Details der Arbeit, bevor Sie die Durchflusseffizienz festlegen. Das Diagramm ermöglicht es Ihnen, genaue Zeiträume anzuzeigen, in denen Ihre Effizienz am niedrigsten war. Und diese Daten müssen sehr sorgfältig analysiert werden, da die wahre Ursache und ihre Abhilfe nicht so leicht zu erkennen sind. Bevor Sie mit intensiven Maßnahmen beginnen, sollten Sie die Ursachen gründlich untersuchen.

Verbessern Sie die Durchflusseffizienz mit Blocker-Analyse. Eine gute Möglichkeit, den vorherigen Punkt zu realisieren, besteht darin, Ihre Flusseffizienz mit einer Clusteranalyse zu verbessern. Wenn einige Arbeiten blockiert sind, verdient es einen farbigen Aufkleber oder eine andere Form des visuellen Signals, um diese Blocker auf das Team aufmerksam zu machen, damit sie darauf reagieren können.

Sie können markieren, wie viele Tage ein Teil der Arbeit blockiert ist, und die Auflösung priorisieren

Normalerweise sammeln sich Blocker in Clustern an, da sie viele Abhängigkeiten voneinander haben. Eine bessere Blockeranalyse kann durchgeführt werden, wenn Sie sie ausgehend von Ähnlichkeiten auf hoher Ebene wie internen und externen Blockern gruppieren und dann nach Design, fehlendem Inhalt oder anderen fehlenden Funktionen weiter spezifizieren. Blocker-Analyse ist eine einfache Möglichkeit, die Täler in der Strömungseffizienz zu untersuchen.

Messung der Codequalität

Codeabdeckung

Die Codeabdeckung definiert, wie viele Codezeilen oder Blöcke ausgeführt werden, während automatisierte Tests ausgeführt werden. Die Codeabdeckung ist eine kritische Metrik für die testgetriebene Entwicklung (TDD) und die kontinuierliche Bereitstellung. Traditionell wird die Metrik nach einem einfachen Ansatz interpretiert: Je höher die Codeabdeckung, desto besser. Um dies zu messen, benötigen Sie eines der verfügbaren Tools wie Overalls. Aber sie funktionieren alle ziemlich gleich: Während Sie Tests ausführen, erkennt das Tool, welche der Codezeilen mindestens einmal aufgerufen werden. Der Prozentsatz der aufgerufenen Zeilen ist Ihre Codeabdeckung.

Coveralls, zum Beispiel, wird brechen Sie die Code-Abdeckung für jede Datei Messung und markieren Sie bedeckt und unbedeckt Linien

How to use code coverage

Konzentrieren Sie sich auf unbedeckte Linien und überschätzen Sie nicht die abgedeckten. Wenn die Codezeile einmal oder sogar mehrmals aufgerufen wird, bedeutet dies nicht unbedingt, dass die unterstützte Funktion einwandfrei funktioniert und die Benutzer zufrieden bleiben. Das Aufrufen einer Codezeile reicht nicht immer aus, um die Testaufgabe zu schließen. Auf der anderen Seite zeigt der Prozentsatz der unbedeckten Linien, was überhaupt nicht abgedeckt wurde und möglicherweise getestet werden muss.

Priorisieren Sie abgedeckten Code und zielen Sie nicht auf 100 Prozent ab. Dies scheint zwar nicht intuitiv zu sein, eine 100-prozentige Abdeckung bedeutet jedoch nicht, dass Sie den Code ordnungsgemäß getestet haben. Ihr Projekt hat den Code, der zählt, und den Rest einer Codebasis. Da die Testautomatisierung in der Regel eine teure Initiative ist, sollte sie die Funktionen und die entsprechenden Codeblöcke priorisieren.

Testautomatisierung gegen manuelles Testen

Diese Messung definiert, wie viele Codezeilen innerhalb eines Features bereits mit automatisierten Tests gegen diejenigen abgedeckt sind, die manuell getestet werden. Dies folgt direkt der vorherigen Metrik, hat jedoch einen bestimmten Anwendungsfall. Der Testautomatisierungsanteil gegenüber manuellen Tests wird nur verwendet, wenn Sie eine Automatisierung zur Abdeckung von Regressionen dringend benötigen. Regressionstests werden durchgeführt, um zu überprüfen, ob nach Feature-Updates etwas kaputt gegangen ist. Und wenn Ihr Produkt ständig verbessert wird – was es sollte -, sollten Regressionstests automatisiert werden. Wenn dies nicht der Fall ist, müssen Ihre manuellen QS-Spezialisten dieselben Testszenarien nach jedem Update-Commit wiederholt wiederholen.

Sie können die gleichen Instrumente verwenden, die für die Codeabdeckung verwendet werden, um diese Metrik zu zeichnen

Wenn Sie die automatisierte Testabdeckung pro Feature skizzieren, können Sie die Features priorisieren, die 1) nach Updates unter Regression leiden können und 2) für die automatisierte Tests kritisch sind. Normalerweise haben Sie nicht genug Zeit und Personal, um alles durch automatisierte Tests auf einmal abzudecken, es sei denn, Sie arbeiten innerhalb des testgetriebenen Entwicklungsrahmens. Daher ist es besser, die Funktionen zu priorisieren, die sich sicher auf die Benutzererfahrung auswirken.

McCabe Cyclomatic Complexity (MCC) of code

Messungen der Codekomplexität werden verwendet, um die Risiken von Problemen beim Testen und Warten von Code zu bewerten. Je höher die Komplexität des Codes ist, desto schwieriger wird es, sicherzustellen, dass er eine akzeptable Anzahl von Fehlern aufweist und eine hohe Wartbarkeit aufweist. Der gebräuchlichste Ansatz zur Messung der Codekomplexität ist die McCabe Cyclomatic Complexity Metric (MCC). Eine der Formeln zum Zeichnen von Komplexitätsergebnissen für MCC lautet wie folgt:

MCC = edges – nodes + return Anweisungen

MCC auf dem Bild entspricht 3

Mit dieser Metrik schätzen Entwickler ihre Codekomplexität nicht subjektiv ein. Da sich die Fähigkeiten der Ingenieure unterscheiden, variieren ihre Bewertungen, was das Refactoring von Code oder das Beheben von Fehlern auf längere Sicht schwieriger macht. Es gibt viele MCC-Messwerkzeuge auf dem Markt, die mit anderen Codekomplexitätsmetriken wie der Tiefe der Codehierarchie und der Anzahl der Codezeilen kombiniert werden können.

Besonderheiten und Fallstricke der MCC-Verwendung

Gleichgewicht zwischen menschlicher und maschineller Wahrnehmung der Codekomplexität. Einer der Hauptgründe für die Verwendung von MCC besteht darin, Code für andere Entwickler lesbar zu machen. Die Lesbarkeit des Codes reduziert das Risiko eines langfristigen Onboardings neuer Entwickler, die sich mit Legacy-Code befassen müssen. Es wird auch das Refactoring vereinfachen. Das Problem hierbei ist, dass das MCC-Modell einige komplexe, aber lesbare Methoden als inakzeptabel betrachten kann. Und wenn Sie einen Entwickler zwingen, komplexe Methoden in viele Untermethoden umzugestalten, können Sie das Gegenteil erreichen: Viele Methoden mit einfacher Logik können für einen Menschen noch schwieriger zu verstehen sein als eine einzelne, aber komplexe Methode.

Machen Sie MCC nicht zu einer restriktiven Metrik. Einige Organisationen üben das Beenden von Code-Commits, die den MCC-Test nicht bestehen. Während dies möglicherweise die Code-Einfachheit erhöhen kann, ist es natürlich, komplexen Code auf den Ebenen von Klassen, Methoden und Funktionen zu haben. Sie vollständig zu blockieren ist nicht immer vorteilhaft. Eine gute Praxis besteht darin, allgemeine Kennzahlen für die Codekomplexität für Entwickler festzulegen, die sie ermutigen, bewusster an die Codierung heranzugehen und an Einfachheit zu denken.

Wenden Sie MCC für die Codeüberprüfung an. Eine weitere wertvolle Praxis für MCC-Tests besteht darin, sie während der Codeüberprüfung anzuwenden, um den Arbeitsumfang auf die Überprüfung bestimmter Codeabschnitte einzugrenzen, bei denen das Fehlerrisiko am höchsten ist.

Code churn

Code Churn ist eine sehr nützliche Visualisierung von Trends und Schwankungen, die in einer Codebasis sowohl in Bezug auf den Gesamtprozess als auch auf die Zeit vor einer Veröffentlichung auftreten. Churn misst, wie viele Codezeilen hinzugefügt, entfernt oder geändert wurden. Manchmal zeigen die Grafiken alle drei Messungen.

Dieses Beispiel von Microsoft enthält alle drei Parameter, aber Sie können sie selektiv verwenden

Obwohl Tracking Code Churn eine etwas primitive Metrik zu sein scheint, ermöglicht es die Bewertung der Code-Stabilität in verschiedenen Entwicklungsstadien. Sie sollten die niedrigste Stabilität während der frühen Sprints und die höchste Stabilität – mit der damit einhergehenden niedrigsten Abwanderung – kurz vor einer Veröffentlichung erwarten. Wenn Ihr Code sehr instabil ist und das Veröffentlichungsdatum näher rückt, schlagen Sie Alarm.

Anwendungsfälle für Code-Abwanderung

Suchen Sie nach Regelmäßigkeiten. Regelmäßige Spitzen bei Codeänderungen können zeigen, dass der Ansatz zur Aufgabengenerierung nicht fokussiert genug ist und viele große Aufgaben auf wiederkehrender Basis erzeugt.

Unregelmäßige, aber hohe Spitzen erfordern eine Untersuchung. Wenn Sie unregelmäßige, aber starke Spitzen bei Codeänderungen haben, können Sie untersuchen, welche Aufgaben solche seismischen Spitzen in Ihrem Code verursacht haben, und den Grad der Abhängigkeiten überdenken, insbesondere wenn die Anzahl der neuen Codezeilen die Anzahl der geänderten Zeilen erhöht hat.

Achten Sie auf Trends. Die Stabilität Ihres Produkts wird vor einer Veröffentlichung sehr kritisch. Wie bereits erwähnt, sollte die Abwanderungsrate einen rückläufigen Trend aufweisen, je näher Ihr Team einem Release kommt. Ein wachsender Trend bedeutet eine mögliche Instabilität des Produkts nach einer Veröffentlichung, da der neue Code wahrscheinlich nicht ausreichend getestet wird.

Streben Sie nach Fortschritt, nicht nach Kontrolle

Genau wie alle anderen Leistungsindikatoren haben agile Metriken nicht immer eindeutige Antworten oder umsetzbare Tipps, die Ihren Erfolg besiegeln. Sie sollten jedoch das Wissen nutzen, das sie vermitteln, um eine Diskussion zu beginnen, eine Bewertung durchzuführen und Ihren eigenen Plan für den Umgang mit problematischen Themen anzubieten.

Während Metriken den numerischen Einblick in die Leistung eines Teams und die allgemeine Zufriedenheit mit der Arbeit bieten, sollten Sie sich nicht auf sie konzentrieren. Wenn man bedenkt, dass agile Metriken nicht standardisiert sind, macht es keinen Sinn, die Erfolge verschiedener Teams zu vergleichen. Stellen Sie vielmehr sicher, dass Sie das Feedback Ihres Teams annehmen, regelmäßige Diskussionen initiieren und eine Atmosphäre gemeinsamer Ziele und Unterstützung schaffen.