17 agile Metriken zur Messung der Teamproduktivität und -leistung • BUOM

28. März 2022

Um die Produktivität in der Softwareentwicklung zu messen, müssen bestimmte Kennzahlen verfolgt werden, um besser zu verstehen, wie alle Teile Ihres Entwicklungsprozesses zusammenarbeiten. Agile Metriken können Ihnen dabei helfen, Produktivität und Qualität in verschiedenen Phasen Ihres Arbeitsablaufs zu messen. Agile-Metriken zu verstehen bedeutet, sie effektiv zu messen und zu wissen, welche für den Entwicklungsprozess wichtig sind. In diesem Artikel definieren wir diese Metriken und diskutieren 17 wichtige Agile-Metriken, die gemessen werden sollten, um Produktivität und Qualität zu verbessern.

Was sind Agile-Metriken?

Agile-Metriken sind Indikatoren, die Sie während des gesamten Entwicklungsprozesses verfolgen können, um die Projektqualität und -konsistenz sowie die Gesamtleistung des Teams zu überwachen. Diese Kennzahlen sind wichtig für die Identifizierung von Fehlern, Teamproblemen, Kosten und anderen Indikatoren für den Projektfortschritt. Agile Metriken sind Teil der agilen Entwicklung, einer Entwicklungsmethode, die sich auf Effizienz und Produktivität konzentriert.

Hier sind die wichtigsten Arten von Agile-Metriken, die Sie messen können:

• Scrum: Datenpunkte, die Entwicklungsteams nutzen, um ihren Entwicklungsprozess zu verbessern und ihn effizienter und effektiver zu gestalten.

• Kanban: Metriken, die Ihnen helfen, sich auf wichtigere Teile des Entwicklungsprozesses zu konzentrieren.

• Lean: Metriken zur Messung der Qualität und Konsistenz eines Projekts mit möglichst wenig Ressourcen.

17 agile Metriken zum Messen

Die Messung agiler Metriken bedeutet, zu verstehen, welche Metriken für den Entwicklungsprozess am wichtigsten sind. Hier sind 17 Kennzahlen, die Ihnen helfen, die Qualität und Produktivität Ihres agilen Entwicklungsprozesses zu verbessern:

1. Vorlaufzeit

Entwicklungsteams verfolgen die Durchlaufzeiten, um die Effizienz des Herstellungsprozesses zu messen. Die Durchlaufzeit ist ein Maß für die Zeit, die benötigt wird, um ein Projekt ab dem Zeitpunkt der Anforderung durch den Kunden abzuschließen. Wenn ein Entwicklungsteam beispielsweise sechs Wochen für die Entwicklung einer Anwendung benötigt, beginnt die Vorlaufzeit, wenn der Kunde eine Anfrage stellt, und endet sechs Wochen später, wenn das Endprodukt beim Kunden eintrifft. Eine kürzere Bearbeitungszeit kann auf ein effizienteres Entwicklungsteam und einen effizienteren Prozess hinweisen.

2. Zykluszeit

Diese Metrik misst, wie schnell das Entwicklungsteam eine Aufgabe erledigt. Entwickler messen die Zykluszeit, um Engpässe im Entwicklungsprozess zu finden oder Hindernisse für die agile Entwicklung zu identifizieren. Sie können beispielsweise messen, wie lange ein Team zum Programmieren einer Anwendung benötigt, um Kunden eine genauere Schätzung zu geben, wann das Team neue Projekte abschließen kann. Schnellere Zykluszeiten können auf einen effizienteren Entwicklungsprozess und ein einheitliches Entwicklungsteam hinweisen.

3. Geschwindigkeit

Velocity ist eine Kennzahl, die den durchschnittlichen Arbeitsaufwand eines Entwicklungsteams während eines einzelnen Sprints erfasst. Sie können die Sprintgeschwindigkeit mithilfe von Uhren oder „Story Points“ messen, die als Meilensteine ​​während einzelner Projektsprints dienen. Geschwindigkeitsmessungen können genauer sein, wenn Sie mehrere Iterationen oder Verlaufspunkte messen müssen. Je höher die Teamgeschwindigkeit, desto effizienter ist das Team im Entwicklungsprozess, sodass einzelne Sprints und ganze Projekte schneller voranschreiten können.

4. Sprint-Burnout

Der Sprint-Burndown ist eine separate Messung für einzelne Aufgaben während eines Sprints. Das Messen des Sprint-Burndowns bedeutet, die Zeit zu bestimmen, die dem Team zur Erledigung jeder Aufgabe zur Verfügung steht, und den Umfang der noch zu erledigenden Arbeit. Sie können beispielsweise den Sprint-Burndown messen, wenn das Team einen engen Entwicklungsplan einhält und bei einzelnen Aufgaben in Rückstand gerät. Für maximale Genauigkeit können Sie den Sprint-Burndown auch in Stunden oder Punkten messen.

5. Zusammenfassendes Blockdiagramm

Ein Gesamtflussdiagramm ist eine Metrik, die den Fortschritt und die Effektivität eines Projekts aus einer breiteren Perspektive misst, einschließlich des Status der Aufgaben in jedem Sprint, des Fortschritts jedes Sprints und des Gesamtfortschritts des Projekts. Dieses Diagramm bietet eine visuelle Darstellung aller Fehler oder Probleme im Entwicklungsprozess und kann Ihnen dabei helfen, Engpässe in Ihrer agilen Entwicklung zu erkennen.

6. Codeabdeckung

Die Codeabdeckungsmetrik ist ein Maß dafür, wie viel vom realisierbaren Code eines Projekts Ihre Unit-Tests abdecken. Wenn Sie wissen, wie viel Code Ihre Tests abdecken können, können Sie effizientere Testprozesse erstellen und den Fortschritt Ihres Codierungsteams ermitteln. Es hilft Ihnen jedoch nicht unbedingt dabei, den Gesamtfortschritt oder die Qualität einzelner Sprints oder des gesamten Projekts zu messen.

7. Statische Code-Analyse

Die statische Code-Analysemetrik ist ein Maß für die Lebensfähigkeit des Codes eines Projekts, ohne dass die Software ausgeführt werden muss. Diese Messung hilft Ihnen, Ihren Code auf Fehler, Bugs und andere Probleme zu testen, bevor Sie das Endprodukt erstellen und die letzten Tests durchführen. Diese Metrik ist normalerweise Teil des gesamten Entwicklungsprozesses und kann dazu beitragen, die Agilität Ihrer Entwicklung zu erhöhen, indem die Anzahl der Fehler und Rückmeldungen in der fertigen Software reduziert wird.

8. Fehlgeschlagene Bereitstellungen

Die Metrik für Bereitstellungsfehler ist ein Maß dafür, wie oft ein Team ein Projekt bereitstellt oder zum Testen oder zur Produktion einreicht. Diese Messung kann Ihnen zeigen, wie effektiv Ihr Team funktionsfähige Software erstellt, die zum Testen oder zur Verwendung bereit ist. Indem Sie die Anzahl der fehlgeschlagenen Bereitstellungen im Vergleich zur Anzahl der erfolgreichen Bereitstellungen messen, können Sie ein besseres Verständnis der Qualität der Arbeit Ihres Entwicklungsteams erhalten.

9. Gelieferter Wert

Die Kennzahl „Value Delivered“ ist eine Messung des Geld- oder Kundenwerts jedes Teils des Projekts. Projektmanager verwenden diese Kennzahl, um zu bestimmen, wie viel Wert jedes Projekt schafft. Ein Projektmanager könnte beispielsweise den Umsatz messen, den eine Software für ein Unternehmen generiert, im Vergleich zu den Kosten für die Entwicklung dieser Software und ihm einen Geldwert zuweisen. Oder ein Manager könnte die Kundenzufriedenheit messen und jedem Projekt Punkte zuweisen, um zu bestimmen, welchen Platz jedes Projekt in der Wertschöpfungskette einnimmt.

10. Entgangene Mängel

„Defects Resolved“ ist eine Kennzahl, die die Anzahl der Bugs, Fehler oder Defekte in einem Projekt misst, wenn es in die Produktion geht oder die Produktion verlässt und an den Kunden übergeben wird. Behobene Fehler sind in der Regel ein Maß für die Gesamtqualität des Projekts und die Qualitätskontrollbemühungen des Teams. Da Fehler während der Produktion zu Verzögerungen und Softwareproblemen führen können, ist es wichtig, übersehene Fehler nachzuverfolgen, damit Methoden zu ihrer Vermeidung implementiert werden können, beispielsweise aufwändigere Qualitätssicherungstests.

11. Netto-Prompter-Score

Die Clean-Prompter-Metrik ist ein Indikator für die Bereitschaft eines Kunden, Ihre Produkte nach der Verwendung einer anderen Person zu empfehlen. Dies hilft dem Team, den Wert seiner Software für den Kunden zu verstehen, und bietet einen Qualitätsmaßstab, den das Team in zukünftigen Projekten verwenden kann. Sie können die Nettopunktzahl eines Souffleurs auf einer Skala von -100 bis 100 messen, wobei 100 die höchste Punktzahl ist. Mithilfe eines Netto-Prompter-Scores können Sie auch die Kundentreue messen, was für den Geschäftserfolg wichtig ist, denn je loyaler ein Kunde ist, desto wahrscheinlicher ist es, dass er sich für Ihre Produkte gegenüber Ihren Mitbewerbern entscheidet.

12. Glück

Zufriedenheit ist ein Maß für die Zufriedenheit eines Entwicklungsteams mit seiner Position und seinem Unternehmen. Durch die Messung der Teamzufriedenheit können Sie feststellen, ob das Arbeitsumfeld, die Teamkultur oder die ihnen zur Verfügung stehenden Tools und Techniken verbessert werden müssen. Glückliche Teams sind tendenziell produktiver, loyaler gegenüber dem Unternehmen und konzentrieren sich auf die Qualität ihrer Arbeit. Sie können die Teamzufriedenheit durch direkte Interviews oder Gruppenumfragen messen und dabei eine Skala von eins bis 10 bereitstellen, um die Zufriedenheit jedes Teammitglieds zu messen.

13. Ausführungszeit der Funktion

Die Funktionsausführungszeit ist ein Maß für die Zeit, die zwischen einer Anforderung einer Softwarefunktion und der Implementierung dieser Funktion vergeht. Dies hilft dem Projektmanager zu bestimmen, wie effizient das Entwicklungsteam der Software neue Funktionen hinzufügen kann und welche Auswirkungen dies auf die Gesamtfertigstellungszeit und -bewertung hat. Normalerweise können Sie die Ausführungszeit einer Funktion in Stunden messen.

14. Teammoral

Die Teammoral ist ein fortgeschrittenerer Zufriedenheitsindikator, der sich auf spezifische, prägnante Aussagen konzentriert, die dem Projektmanager helfen, die Gesamtzufriedenheit jedes Mitglieds des Entwicklungsteams zu bestimmen. Typischerweise messen Manager die Teammoral, indem sie die Teammitglieder bitten, direkten, umsetzbaren Aussagen zuzustimmen oder sie abzulehnen, wie zum Beispiel:

• Ich fühle mich als wertvolles Mitglied meines Teams.

• Ich bin stolz auf die Arbeit, die ich und mein Team leisten.

• Ich liebe die Arbeit, die ich für mein Team mache.

• Ich spüre eine starke Verbindung zu den anderen Teammitgliedern.

15. Bandbreite darstellen

Der Story-Durchsatz ähnelt der Geschwindigkeit, da beide die Anzahl der Storys messen, die ein Team in einem einzelnen Sprint abschließt. Allerdings konzentriert sich der Story-Durchsatz auf die Messung von Storys nach ihrer Fertigstellung und nicht darauf, wann das Team sie startet. Dies kann dem Projektmanager zeigen, wie viele Storys das Team tatsächlich in einem Sprint abschließt und wie viele Storys das gesamte Projekt ausmachen.

16. Qualitätsintelligenz

Qualitätsanalyse ist eine Qualitätssicherungsmetrik, die dem Entwicklungsteam hilft, die Lebensfähigkeit und Qualität der Software als Ganzes zu messen, anstatt sich auf bestimmte Phasen des Entwicklungsprozesses zu konzentrieren. Mithilfe hochwertiger Analysetools kann das Team Softwarefehler oder -probleme vor der Auslieferung identifizieren und so qualitativ hochwertige Ergebnisse für die Kunden erzielen. Die Messung von Daten während des gesamten Entwicklungslebenszyklus bietet einen umfassenderen Überblick über die Projektqualität und die Bemühungen des Teams, die Projektqualität aufrechtzuerhalten oder zu verbessern.

17. Episches und Release-Burnout

Die Epic- und Release-Burndown-Metrik verfolgt den Fortschritt eines großen Arbeitsvolumens. Dies unterscheidet sich vom Sprint-Burndown, bei dem der Schwerpunkt auf dem Fortschritt über verschiedene Zeiträume oder Sprints hinweg liegt. Epic- und Release-Burndown-Charts verfolgen in der Regel Metriken wie:

• Arbeit abgeschlossen

• Job hinzugefügt

• Jobprognose

• Arbeit übrig