Unsere Erfahrung mit den gängigsten agilen Metriken

Unsere Erfahrung mit den gängigsten agilen Metriken

Die Verwendung agiler Metriken zur Messung der Produktivität des Teams ist der Schlüssel zur Philosophie von Agile. Teammanager und alle Mitglieder sollten die Konsequenzen ihrer Arbeit sehen und diese Daten verwenden, um den Workflow zu verbessern und die Effizienz zu steigern.

Endbenutzer und Kunden können auch von der Verwendung agiler Projektmetriken profitieren, die sich auf die Bewertung des Ergebnisses des Produkts konzentrieren. Mit Metriken können Scrum Master, Entwickler, Designer und Tester die Leistung der Anwendung messen und nachverfolgen, ob aktuelle und frühere Aufgaben das Produkt verbessern.

In diesem Artikel werden wir wichtige Agile Metriken überprüfen und unsere Erfahrungen mit der Anwendung dieses Dashboards für Agile Metriken auf ein reales Projekt weitergeben. Um ein Team erfolgreich zu führen und Ergebnisse zu liefern, müssen Sie nicht nur wissen, welche Metriken Sie anwenden müssen, sondern auch, wie Sie dies tun — wir werden Ihnen mitteilen, wie wir es herausgefunden haben.

Arten gängiger Agiler Metriken

Die Klassifizierung agiler Metriken ist nicht in Stein gemeißelt — sie ändert sich ständig und restrukturiert sich. Dennoch haben wir im Laufe der Jahre den Aufstieg von drei Hauptarten agiler Metriken in verschiedenen agilen Frameworks gesehen.

1. Kanban-Metriken – Diese Metriken basieren auf der Messung der investierten Zeit (Zykluszeiten) und der gelieferten Ergebnisse (Durchsatz) sowie ihres Verhältnisses.
2. Scrum-Metriken – Metriken, die sich auf die Planung und das Verständnis des Workflows konzentrieren und zeigen, wie viel Arbeit in einem bestimmten Zeitraum ausgeführt wurde;
3. Lean—Metriken – die kontinuierliche Messung der Produktionseffizienz und Produktqualität mit technischer Bewertung durch Testen von Funktionen, Überprüfen auf mögliche Fehler und Voraussehen negativer Auswirkungen.

Wir verwenden alle drei Arten von Metriken, um die Hauptaspekte des Softwareentwicklungsprozesses und der Ergebnisse zu bewerten: produktqualität, Produktivität des Teams und Gesundheit.

Agile Qualitätsmetriken

Bevor Sie mit der Messung der Geschwindigkeit und Effizienz des Teams beginnen, müssen Sie wissen, ob Sie sich im Allgemeinen in die richtige Richtung bewegen. Was nützt die schnelle Lieferung aller Entwicklungsaufgaben, wenn die Aufgaben selbst falsch gebildet werden? Die Priorität für jedes Softwareentwicklungsteam und jeden Manager besteht darin, sicherzustellen, dass alle Aktivitäten mit der Verbesserung des Produkts zusammenhängen — dies geschieht durch Messung seiner Qualität und Erkennung negativer Tendenzen.

Escaped defects

Jedes Agile Projekt hat Sprints oder Arbeitszyklen, an deren Ende eine bestimmte Aufgabe geliefert wird. Nach Abschluss der Arbeit muss der Manager des Teams die Qualität der Turned-it-Ergebnisse bewerten. Alle Änderungen, Bearbeitungen und nicht behobenen Fehler sind maskierte Fehler — Probleme, die Entwickler hätten beheben können, aber nicht. Notieren Sie ihre genaue Anzahl und Art, um zu wissen, welche Fehler Entwicklern normalerweise entgehen.

Nachdem Sie einen Bericht über entkommene Defekte erstellt und greifbare Statistiken gesammelt haben, müssen Sie die Ergebnisse mit Ihrem Team besprechen. Stellen Sie sicher, dass jedes Teammitglied weiß, welche Arten von Fehlern das Team normalerweise vermisst. Wenn Sie individuelle Vorschläge haben, besprechen Sie diese mit den Teammitgliedern einzeln.

Fehlgeschlagene Bereitstellungen

Wenn das Produkt bereitgestellt, aber nicht freigegeben wurde oder keine Benutzer angezogen hat, wird dies als fehlgeschlagene Bereitstellung aufgezeichnet. Manchmal ist eine fehlgeschlagene Bereitstellung auf die Entscheidungen eines der Stakeholder zurückzuführen oder das Geschäftsmodell erweist sich als unzuverlässig. Was auch immer die Ursache des Problems war, Sie müssen alle fehlgeschlagenen Bereitstellungen zusammen mit den Gründen für ihren Ausfall aufzeichnen.

Vor der Freigabe einer neuen Bereitstellung kann sich das Team jederzeit die Liste der zuvor fehlgeschlagenen Bereitstellungen ansehen und prüfen, ob diese nicht denselben Prozess durchlaufen können. Durch die Analyse der Gründe für das Scheitern früherer Versionen können zukünftige Probleme vermieden werden.

Release Net Promoter Score (NPS)

Der Net Promoter Score ist die Metrik, bei der die Reaktionen der Nutzer in quantitativen (Zahlen, Statistiken, Durchschnittsbewertungen) und qualitativen Feedbacks (Bewertungen, direktes Feedback, Nachrichten, E-Mails, Anrufe) bewertet werden. Nachdem das Team das Feedback gesammelt und analysiert hat, schlägt jedes Teammitglied eine Punktzahl vor, die bewertet, wie sehr der Benutzer das Produkt wahrscheinlich empfiehlt (in der Regel werden die Punktzahlen in Grenzen von 1 bis 10 festgelegt).

Agile Projektmanagement-Metriken

Nachdem Sie eine vollständige Historie früherer Fehler und Erfolge haben, können Sie die Richtung für alle aktuellen unvollständigen Projekte analysieren und relevante Aufgaben basierend auf früheren Erfahrungen vergeben. Nachdem Sie die Entwicklungsrichtung festgelegt haben — das „Was zu tun ist“ des Produkts, müssen Sie die Effizienz des Teams bewerten – es ist der Faktor „Wie geht es uns?“. Sie können Agile Projektmetriken verwenden, um zu erfahren, ob Teammitglieder Ihre Erwartungen erfüllen, ihre Aufgaben verstehen, Termine verwalten und ob alle Prozesse koordiniert und synchronisiert sind.

Vorlaufzeit

Die Vorlaufzeit ist eine Metrik, mit der Teams überprüfen können, wie lange es gedauert hat, bis der Product Backlog-Eintrag am Ende des Sprints eingetroffen ist. Es kann verwendet werden, um Produkte in jeder Entwicklungsphase, Aufgabe für Aufgabe, zu verfolgen oder den Gesamtzeitaufwand von der Ideenfindung bis zur Veröffentlichung zu bewerten. Es ist eine langfristige Metrik, die Entwickler verwenden können, während sie ihre zukünftige Arbeit planen und Preise schätzen.

Stellen Sie sicher, dass Sie die Vorlaufzeit für jedes Ihrer Projekte aufzeichnen. Es ist am besten, sowohl übergreifende Statistiken zu führen, die das gesamte Projekt abdecken, als auch organisierte Sprint-Metriken zu haben, damit Sie jede Phase separat untersuchen können.

Zykluszeit

Wenn die Vorlaufzeit zu den langfristigen Kennzahlen der Teamleistung gehört, konzentriert sich die Zykluszeit auf einzelne Aufgaben. Diese Metrik wertet die Dauer eines einzelnen Zyklus aus, wobei ein Zyklus von einer Aufgabe benötigt wird, berechnet die Anzahl der Zyklen pro Projekt und misst die erzielten Ergebnisse für den Endbenutzer, wenn das Produkt bereits Beta-getestet oder freigegeben ist.

Mit der Zykluszeit können Teams sofort erkennen, ob eine Aufgabe zu lange dauert oder ob einige Teammitglieder ihre Ziele nicht erreichen. Diese kurzfristige Metrik erleichtert das Projektmanagement erheblich und hilft, auftretende Probleme schnell zu lokalisieren.

Sprint Burndown

Diese Metrik wird sowohl kurzfristig als auch langfristig angewendet. Manager können Sprint-Burndown-Scrum-Berichte in Echtzeit erstellen, um den Fortschritt ihres Teams beim aktuellen Projekt zu verfolgen — dazu müssen sie die Gesamtzahl der Sprints schätzen und den voraussichtlichen Zeitaufwand vorhersagen. Es kann auch langfristig verwendet werden – Manager können Berichte zu früheren Projekten analysieren, Phasen ermitteln, in denen die erwarteten Zeitrahmen fehlgeschlagen sind, und Ursachen für Verzögerungen analysieren.

Am wichtigsten ist, dass Sprint Burndown die Dynamik des Workflows von Teams verfolgen kann. Einige Mitglieder neigen dazu, in den ersten Phasen langsamer zu arbeiten, während andere gegen Ende des Projekts ausbrennen. Mit Sprint Burndowns können Teamleiter diese Tendenzen erkennen, ihre Ursachen ermitteln und den Mitgliedern bei der Arbeitsverteilung und dem Zeitmanagement helfen.

Epic & Release Burndown

Diese Metrik ähnelt Sprint Burndown — der einzige wesentliche Unterschied besteht darin, dass sie sich auf die Produktivität des Teams vor und nach der Veröffentlichung konzentriert. Manager können neue Anforderungen hinzufügen und Aufgaben übernehmen, die auf dem Feedback der Endbenutzer basieren. Es ist eine verbesserte Version von Sprint Burndown, da es auch Aufgaben enthält, die nach der Veröffentlichung des Projekts gegeben wurden.

Velocity

Diese Metrik wertet die Anzahl der abgeschlossenen Story Points über einen bestimmten Zeitraum aus. Basierend auf Ihrer Historie können Sie die Zeitkosten für zukünftige Story Points vorhersehen. Die Abnahme der Geschwindigkeit des Teams bei bestimmten Sprints kann auf Missverständnisse zwischen Teammitgliedern oder auf Aufgaben hinweisen, die schwieriger sind als zuvor erwartet.

Zusätzliche Agile Metriken

Agile Metriken helfen dem Team, sein Projekt besser zu kennen und viele wichtige Aspekte der Produktentwicklung im Auge zu behalten. Es gibt auch agile Metriken für Führungskräfte, die es ermöglichen, das Gesamtbild der Entwicklung und des Wohlbefindens des Teams zu sehen. Nach unserer Erfahrung helfen diese zusätzlichen Metriken, jeden Aspekt Ihrer Arbeit zu messen. Wir haben jedoch die wichtigsten Merkmale definiert, die am meisten über das Endprodukt aussagen und dazu beitragen, ein vollständiges Ergebnis zu erzielen.

Kumulativer Fluss

Der Name der Metrik vermittelt eindeutig ihren Zweck — alle Projektflüsse zu sammeln und in einem einzigen Diagramm auszuwerten. Ein solches Diagramm bietet Ihnen eine umfassende Ansicht — es kann an Projektbeteiligte gesendet werden, die keine Zeit haben, detailliertere Agile Berichte zu analysieren.

Das Diagramm beschreibt normalerweise die folgenden Prozesse:

• Aufgaben im Backlog: Wie viele Aufgaben im Backlog Teammitglieder über den angegebenen Zeitraum haben;
• Genehmigte Arbeit: wie viele Aufgaben unter den geplanten abgeschlossen wurden – der Teammanager sieht sofort die Unterschiede zwischen geplanten und abgeschlossenen Aktivitäten;
• Pufferaufgaben: Alle Arbeiten, die auf Genehmigung warten, befinden sich in einer Pufferzone;
• In Bearbeitung: Sie müssen die aktuelle Arbeitslast auswerten.

Code churn

Diese Metrik zeigt die Trends der Änderungen der Codebasis vor der Veröffentlichung. Churn-Diagramme zeigen, wie viel Code einmal hinzugefügt, entfernt oder geändert wurde. In frühen Sprints wird es viele Spitzen und Stürze in der Grafik geben, da der Code immer noch instabil ist, aber im Laufe des Projekts sollte die Code-Churn-Grafik stabil werden, ohne drastische Höhen und Tiefen.

Vor der Veröffentlichung sollte die Abwanderung einen Rückgang erhalten — das Hinzufügen oder Bearbeiten von Code vor der Veröffentlichung bedeutet, dass er nicht ausreichend getestet wird. Wenn es eine Unregelmäßigkeit in den Agile-Charts gibt, untersuchen Sie die Gründe.

Kontrollkarte

Ein Kontrolldiagramm ist ein Diagramm, in dem das Team Informationen über die Dauer seiner Zykluszeiten sehen kann. Das ideale Ergebnis wäre, dass die Linie auf dem Chart mit der Zeit stetig abnimmt — dies würde bedeuten, dass die Geschwindigkeit des Teams zunimmt — pro Zyklus ist weniger Zeit erforderlich. Ein weiterer wichtiger Aspekt ist die Konsistenz – die Zykluszeiten müssen unabhängig von der Art der Aufgabe konstant bleiben — dies bedeutet, dass Sie die richtige Arbeitsverteilung haben.

Gesundheitsmetriken

Softwareentwicklungsteams müssen sich auf langfristige Prioritäten konzentrieren, z. B. die reibungslose Kommunikation zwischen den Mitgliedern und die Überprüfung, ob alle zufrieden sind. Agile ist eine flexible Methodik, was bedeutet, dass sie sich an die Interessen verschiedener Mitglieder anpassen kann, sobald Manager wissen, worauf sie achten müssen. So finden wir heraus, ob alle unsere Teammitglieder mit dem Workflow zufrieden sind.

Wenn Sie vertrauensvolle, informelle Beziehungen in Ihrem Team haben, ist es einfacher, mit einem offenen Dialog mit jedem Mitglied zu beginnen. Bitten Sie alle, ihre Erfahrungen im Unternehmen von 1 bis 5 zu bewerten. Sie können Ihnen Fragen stellen — Was sind die besten und schlechtesten Aspekte ihrer Arbeit, was könnte verbessert werden und was könnte das Glück steigern? Wenn das Team keine freundlichen Kommunikationsgewohnheiten hat, kann die Verwendung anonymer Umfragen zu objektiveren Ergebnissen führen.

Teammoral

Teammoral und Glück sind nicht dasselbe. Glück hat mehr mit Komfort zu tun, während die Teammoral an Produktivität, Selbstwertgefühl und die Bewertung der eigenen beruflichen Qualitäten gebunden ist. Auch hier können Sie die Mitarbeiter bitten, ihre Moral von 1 bis 5 zu bewerten und die folgenden Fragen zu stellen;

• Hat die Arbeit im Unternehmen dazu beigetragen, Ihre Fähigkeiten zu verbessern?
• Inwieweit wird Ihr volles Potenzial mit der aktuellen Arbeitsbelastung ausgeschöpft?
• Gefällt Ihnen Ihre Arbeit?
• Sehen Sie die klaren Ergebnisse Ihrer Arbeit?
• Sind Sie begeistert von neuen Projekten?

Das Ziel ist hier zu verstehen, dass der Entwicklungsstrom des Teams in die richtige Richtung geht. Manchmal übernimmt der Manager des Softwareentwicklungsteams profitable, aber langweilige Aufgaben und ignoriert die Interessen der Mitglieder. Anhand dieser Umfrage können Sie feststellen, ob Mitarbeiter von ihrer Arbeit begeistert und herausgefordert sind.

Umsatz der Teammitglieder

Wenn Teammanager häufig Teammitglieder ersetzen, bedeutet dies, dass das Arbeitsumfeld wahrscheinlich ungesund ist. Eine gewisse Fluktuationsrate im Laufe der Zeit ist gesund — in der Tat möchten Sie jahrelang keine zusätzlichen Mitarbeiter haben, da dies Stagnation bedeuten würde. Sie sollten jedoch auf plötzliche Aktivitätsspitzen achten – Monate, in denen mehrere Personen das Team verlassen haben oder viele Personen beigetreten sind. Wenn Sie plötzlich viele neue Teilnehmer hinzufügen, müssen Sie auf den Onboarding-Prozess achten, bevor Sie direkt zur projektbezogenen Arbeit übergehen.

Messung des Nutzens für Endbenutzer

Agile Teams sollten wissen, wie gut das Produkt den Bedürfnissen eines Endbenutzers und Geschäftsinhabers entspricht. Dies geschieht mit einer umfassenden Codeanalyse, die die Codequalität und ihre Verwendbarkeit für einen Endbenutzer sowie mögliche Wartungskomplikationen bestimmt.

Statische Codeanalyse

Es ist die einfache Art der Codeanalyse, wenn die Software inaktiv ist. Wenn Sie Code automatisch mit Open-Source-Tools überwachen, können Sie Sicherheitsprobleme identifizieren, technische Probleme und Fehler erkennen und problematische Codefragmente an den Garbage Collector senden.

Dynamische Codeanalyse

Für die dynamische Codeanalyse muss Ihr Team Software ausführen, um die Erfahrungen der Endbenutzer zu bewerten. Wir ermutigen unsere Entwickler und Tester, sich immer in die Lage der Benutzer zu versetzen und die häufigsten Szenarien zu erkunden. Zum Beispiel können sie ihre Kollegen und Familienmitglieder in die Lösung einführen und Feedback anfordern — es sei denn, dies ist nicht durch die Vereinbarung verboten. Am wichtigsten ist, dass wir ein Team von QA-Fachleuten haben, die voll und ganz für die dynamische Codeanalyse verantwortlich sind — obwohl wir glauben, dass die Endproduktqualität umso besser ist, je mehr Menschen zum Testen von Metriken in Agile beitragen.

Anwendung der besten agilen Metriken

Aus der Vielzahl der verfügbaren Agilen Metriken müssen Sie diejenigen auswählen, die langfristig für Ihr Team und Ihre Projekte relevant sind. Das Verfolgen dieser Schlüsselmerkmale sollte eine Gewohnheit sein, während es Sie nicht von dringenderer Arbeit ablenken sollte. So haben wir Agile Metriken nahtlos in unseren Workflow integriert.

Konzentrieren Sie sich auf Leistung, Budget und Qualität

Sie müssen sicherstellen, dass Sie nach Auswahl aller Metriken ein klares Bild von Qualität, Auslastung, Zeitaufwand und Budget Ihrer Arbeit erhalten. Zunächst richten wir kurzfristige Metriken ein, die sich auf unsere aktiven Projekte beziehen: Zykluszeit und Geschwindigkeit für die agile Leistungsbewertung, Codeanalyse für die Bewertung der Codequalität und kumulativer Fluss, um alle Entwicklungsprozesse und deren Kosten im Auge zu behalten.

Während des ersten Sprints achten wir darauf, Folgendes zu tun:

• Definieren Sie, wie viele Sprints und Zyklen das Projekt haben wird;
• Schätzen Sie den Zeitaufwand für das gesamte Projekt unter Berücksichtigung der Bedürfnisse des Kunden ab;
• Bewertung wettbewerbsfähiger Lösungen, um den Komplexitätsgrad des Endprodukts zu verstehen;
• Sammeln Sie Feedback von unseren Teammitgliedern zu ihren Erwartungen an die aufregendsten, herausforderndsten und schwierigsten Aspekte des Projekts.

Auf diese Weise können wir wissen, wie viel Zeit wir für die Fertigstellung des Projekts aufwenden werden, Qualitätsstandards auf der Grundlage ähnlicher Lösungen festlegen und ob unser Team motiviert ist, an den Aufgaben zu arbeiten oder nicht (dies hat einen großen Einfluss auf die Produktivität).

Metriken nach dem ersten Sprint

Hier konzentrieren wir uns darauf, Feedback vom Kunden und allen Teammitgliedern zu erhalten. Nach dem ersten Sprint wollen wir wissen, dass alle am Workflow Beteiligten den Prozess verstehen und sich wohl fühlen. Außerdem legen wir Wert auf die Bewertung der Codequalität — wir planen sogar die Codeanalyse und die Bewertung der Tech-Schulden als Teil jedes unserer nächsten Sprints. Sobald die ersten Zeilen des Codes geschrieben wurden, ist die Aufrechterhaltung seiner Qualität unsere Priorität.

Velocity folgt auf

Velocity ist eine der wichtigsten Metriken in unseren Projekten, aber nicht die wichtigste. Wir verzichten darauf, unser Urteil in der Anfangsphase auf Geschwindigkeitszahlen zu stützen. Die Strategie, schnell durch die ersten Schritte zu kommen, ist eine Katastrophe, die darauf wartet, passiert zu werden – das Team könnte die Planung überspringen oder vergessen, einem Kunden einige wichtige Fragen zu stellen. Wir beeilen uns nicht in den ersten Phasen des Produkts und lassen Kunden und Teammitglieder ihr Tempo finden.

Die Steigerung der Geschwindigkeit unseres Teams wird zu einer unserer Prioritäten, wenn wir am Punkt der Ausführung sind. Sobald alle Funktionen und das Design festgelegt sind, bemühen wir uns, den Zeitaufwand zu minimieren und alle Aufgaben so schnell wie möglich zu erledigen.

Individuelle Metriken

Jede der verwendeten Metriken sollte für das gesamte Team und einzelne Mitglieder gleichermaßen verfügbar sein. Entwickler, Tester und Designer sollten das Tempo und die Ergebnisse ihrer Arbeit sehen können, nicht nur ein Team als Ganzes. Um dies zu erreichen, verwenden wir Produktivitätstools und Zeitverfolger wie Jira und Hubstaff. Alle allgemeinen Berichte werden mit einzelnen synchronisiert — Mitglieder können sehen, wie viel Prozent der gesamten produktiven Zeit ihre Stunden ausmachen.

Häufig gestellte Fragen

Was ist KPI in Agile?

Key Performance Indicators in Agile sind messbare Werte, die die Effizienz des Teams bei der Erreichung der Geschäftsziele zeigen. High-Level-KPIs konzentrieren sich auf langfristige Ergebnisse, die von vielen Faktoren abhängen — wie viele Nutzer vom Endprodukt angezogen wurden, Conversion-Raten, Feedback-Qualität. Low-Level-KPIs sind kurzfristige Werte, die nicht durch viele zusammenhängende Faktoren beeinflusst werden — die für das Projekt aufgewendete Zeit (normalerweise in Stunden berechnet), das Projektbudget (Investition pro Aufgabe) usw.

Agile ist eine Entwicklungsmethodik, die auf kontinuierlicher Verbesserung basiert — Softwareentwicklung analysiert Daten und passt sich diesen an. Das Team analysiert agile KPIs auf seine Leistung und Arbeitsqualität und implementiert Änderungen sofort im nächsten Sprint.

Was sind Sprint-Metriken?

Sprint-Metriken sind Metriken, die die Ergebnisse des Softwareentwicklungsteams bewerten und überprüfen, wie viel Wert dem Endkunden am Ende jedes Sprints geliefert wurde . Dieser Wert kann mit einer neuen Funktion, Designverbesserungen oder dem Löschen von Fehlern gemessen werden.

Das nächste Ziel von Sprint Metrics ist es, die Effektivität des Teams in geschäftlicher Hinsicht zu messen — wie schnell die Lösung auf den Markt gebracht wurde, wie das Feedback des Kunden ist und wie hoch die Conversion ist. Schließlich müssen Metriken die Zufriedenheit der Entwickler mit ihrem Projekt und der Richtung, in die das Team im Allgemeinen geht, zeigen.

Warum sind Metriken für agile Projekte wichtig?

Der springende Punkt der agilen Methodik ist, dass Entwickler nach jedem Sprint immer Korrekturen im Prozess vornehmen können. Mit greifbaren Daten, Statistiken und Grafiken können Entwickler verstehen, welche Änderungen für den nächsten Sprint vorgenommen werden müssen, und die Qualität des Endprodukts bewerten.

Was ist ein Sprint in Agile?

Ein Sprint ist ein klar definierter Zeitraum mit Start- und Enddatum, in dem das Team eine bestimmte Anzahl von Aufgaben erledigen soll. Sprints sind die Basis von Scrum, Agile und DevOps – Teams teilen ihre Arbeitsbelastung in kleinere überschaubare Teile auf und verfolgen die Ergebnisse jedes Sprints. Jede dieser Perioden wird wie ein Miniprojekt mit einer detaillierten Planung, Risikobewertung, Verantwortungszuweisungen und Post-Sprint-Analyse behandelt.

Jedes Projekt besteht aus einer Reihe von Sprints. Da jeder Sprint ausgewertet wird, ist es einfach, Probleme frühzeitig zu erkennen und im nächsten Sprint zu entfernen — so wird der Workflow ständig optimiert.

Was sind die Metriken für die Softwareentwicklung?

Softwareentwicklungsmetriken sind quantitative Werte, mit denen die Qualität, Leistung und Gesundheit des Softwareentwicklungsprojekts gemessen werden können. Sie helfen, den Entwicklungsprozess im Laufe des Projekts zu verbessern und können für die zukünftige Arbeit des Teams verwendet werden, um die Organisation und Planung zu verbessern.

Es gibt sechs Haupttypen von Softwareentwicklungsmetriken:

• Formale Code-Metriken – Dies sind objektive qualitative Werte, die berechnen, wie viel Arbeit durch Bestimmen der Anzahl der Codezeilen (LOC), der Befehlspfadlänge und anderer ausgeführt wurde.
• Kennzahlen zur Entwicklereffizienz – Das Team kann den Zuweisungscode, die aktiven Tage und die für die Aufgabe aufgewendete Zeit berechnen.
• Agile Prozessmetriken – Wenn das Projekt in Sprints unterteilt ist, kann das Team die Effizienz kleinerer Teile des Projekts messen – Vorlaufzeit (wie viel Zeit für eine bestimmte Entwicklungsphase aufgewendet wurde, die mehrere Sprints enthalten kann), Zykluszeit (ein Sprint fällt normalerweise unter einen einzelnen Zyklus) und Geschwindigkeit (wie viele Aufgaben wurden in einem bestimmten Zeitrahmen erledigt).
• Betriebsmetriken – Diese Metriken überprüfen die Laufeigenschaften der Software und bestimmen, wie effektiv die Mitarbeiter des Unternehmens das Tool ohne Hilfe von Drittanbietern warten können. Mean Time Between Failures and Mean Time to Recover (MTTR) Überprüfen Sie, wie die Software unter natürlichen Umständen ausgeführt wird und wie gut das interne Team im Umgang mit der Last ausgestattet ist.
• Testmetriken – Diese Metriken bewerten die Codeabdeckung — wie viel Code getestet wurde, die Anzahl der Fehler und den Prozentsatz der technischen Schulden.
• Kundenzufriedenheit – Das Team erhält Einblicke in die Reaktionen der Endbenutzer auf das Produkt, indem es den Net Promoter Score, den Customer Satisfaction Score und den Customer Effort Score misst. Diese Metriken bewerten, ob Benutzer das Produkt empfehlen würden und ob sie mit dem Ergebnis zufrieden sind.

Agile Metriken sind Teil von Softwarenetzwerken und können aus anderen Kategorien bestehen, wie Sie unserem Leitfaden entnehmen können.

Was sind SDLC-Metriken?

SDLC ist ein Softwareentwicklungslebenszyklus — eine Reihe von Phasen, die eine typische Technologie während ihrer Konzeption, Ausführung und Finalisierung durchläuft. Ein durchschnittlicher SDLC besteht aus den folgenden Phasen:

• Bewertung bestehender Systeme und Definition ihrer Merkmale, Vorteile, Probleme;
• Definition der Anforderungen an das neue Projekt Funktionalität, Design, Zielgruppe usw.;
• Entwerfen des Systems und Skizzieren eines typischen Benutzerpfads;
• Entwickeln der Software, dh Schreiben von Code, Vorbereiten von Hardware und Erstellen von Funktionen;
• Testen der Softwareleistung, Funktionalität, Sicherheit, Schnittstelle usw.;
• Bereitstellung der Software in ihrer natürlichen Umgebung, in der die Technologie langfristig läuft;
• Wartung des Systems durch Aktualisierung des Codes, Ersetzen oder Bearbeiten bestimmter Fragmente und Entfernen von Fehlern.

Jede Stufe von SLDC kann anhand der folgenden Eigenschaften gemessen werden.

• Anforderungen: Das Team muss alle Anforderungen für das Projekt sammeln und die Umsetzung jedes einzelnen in Bezug auf Zeit und Geld bewerten;
• Softwarequalität: Alle agilen Qualitätsmetriken können in der Entwicklungsphase eines SDLC verwendet werden;
• Testfälle: Das Team muss die Anzahl der durchgeführten Testaktivitäten, die Geschwindigkeit und die endgültige Codeabdeckung berechnen;
• Defekte: Um die Effizienz ihrer Arbeit zu messen, müssen Entwickler und Tester die genaue Anzahl der Probleme kennen, die während der Entwicklung auftreten;
• Aufgaben: Messen der Zeitaufwand und mit dem pro Aufgabe verdienten Geld kann bewertet werden, ob alle Teammitglieder produktiv sind oder nicht.

Alle in unserem Leitfaden beschriebenen Metriken können in verschiedenen Phasen des Softwareentwicklungslebenszyklus verwendet werden. Das Projekt muss näher an der Veröffentlichung überwacht werden, da sich Probleme häufen können und es leicht ist, einen kritischen Fehler im Produkt zu übersehen.

Was ist Durchsatz in agilen Metriken?

Diese Metrik berechnet die Anzahl der abgeschlossenen Storys pro Sprint. In Scrum wird eine ähnliche Metrik als Sprint Velocity bezeichnet.

Fazit

Agile Metriken bilden eine solide Basis für fundierte Entscheidungen während eines Softwareentwicklungsprojekts. Entwickler können diese Erkenntnisse nutzen, um ihre Effizienz in den nächsten Sprints zu steigern und die Qualität ihres Produkts ständig zu verbessern. Es ist jedoch erwähnenswert, dass Entwicklungsmetriken im Softwareentwicklungsprojekt keine absolute Priorität haben sollten. Entwickler sollten sich in erster Linie auf Projektanforderungen und Publikumspräferenzen verlassen.

Bei Jelvix verwenden wir einen personalisierten Ansatz, um Metriken auf das Projekt anzuwenden. Zuerst besprechen wir den MVP des Projekts mit dem Kunden, recherchieren die Zielgruppe, analysieren Wettbewerbslösungen und wählen erst dann die Metriken aus, die am besten zum Projekt passen. Wir bemühen uns nicht, jeden einzelnen KPI anzuwenden — stattdessen wählen wir diejenigen aus, die die Projektanforderungen am besten widerspiegeln.