9 Metriken, die für die heutigen Softwareentwicklungsteams einen Unterschied machen können

Wie ich im Artikel „Warum Metriken in der Softwareentwicklung keine Rolle spielen (es sei denn, Sie koppeln sie mit Geschäftszielen)“ erwähnt habe, erfordert die Auswahl von Metriken erhebliche Überlegungen und Sorgfalt, um die spezifischen Fragen zu unterstützen, die ein Unternehmen wirklich beantworten muss. Hier ist der kritische Punkt: Messungen sollten nur als eine Möglichkeit zur Beantwortung von Geschäftsfragen konzipiert werden. Und diese Fragen sind nie, „Wie viele KLOCs sind wir bis jetzt?“

Dieser Artikel knüpft dort an, wo der vorherige aufgehört hat, indem zuerst die spezifischen Metriken besprochen werden, die jedes Team verwenden sollte, oder zumindest planen, sie bald zu verwenden, um seine Leistung zu verbessern. Beachten Sie, dass der Titel dieses Artikels behauptet, dass es „9 Metriken gibt, die einen Unterschied machen können …“ — denn was wirklich wichtig ist, was wirklich einen Unterschied machen wird, ist, wie diese Metriken tatsächlich verwendet werden, um den Geschäftswert zu verbessern. Diese Verwendung liegt bei Ihnen. Abschließend wird in diesem Artikel erläutert, wie Sie diese Metriken kombinieren können, um Bedeutung zu erzeugen sowie eine Geschäftswerthypothese zu formulieren und zu testen.

Beginnen Sie mit der Messung der richtigen Dinge

Hier sind neun objektive Metriken (gekennzeichnet durch Aufzählungszeichen), die Sie kontinuierlich überwachen sollten, um schrittweise Verbesserungen an Prozessen und Produktionsumgebungen vorzunehmen. Verbesserungen dieser Zahlen garantieren nicht, dass Ihre Kundenzufriedenheit sprunghaft ansteigt. Aber zumindest sind dies die richtigen Dinge zu messen. In einem späteren Abschnitt dieses Artikels, „Putting it all together“, werden Sie sehen, warum.

Agile Prozessmetriken

Für agile und schlanke Prozesse sind die grundlegenden Metriken Vorlaufzeit, Zykluszeit, Teamgeschwindigkeit und Öffnungs- / Schließraten. Diese Metriken helfen bei der Planung und informieren über Entscheidungen zur Prozessverbesserung. Sie messen zwar nicht den Erfolg oder die Wertschöpfung und haben nichts mit der objektiven Qualität der Software zu tun, aber Sie sollten sie trotzdem messen. Ich werde unten erklären, warum.

• Leadtime — Wie lange dauert es, bis Sie von der Idee zur gelieferten Software gelangen. Wenn Sie besser auf Ihre Kunden reagieren möchten, arbeiten Sie daran, Ihre Vorlaufzeit zu verkürzen, indem Sie in der Regel die Entscheidungsfindung vereinfachen und die Wartezeit verkürzen. Vorlaufzeit beinhaltet Zykluszeit.
• Zykluszeit – Wie lange es dauert, bis Sie eine Änderung an Ihrem Softwaresystem vornehmen und diese Änderung in die Produktion bringen. Teams, die Continuous Delivery einsetzen, können Zykluszeiten in Minuten oder sogar Sekunden anstelle von Monaten messen lassen.
• Team Velocity – Wie viele „Einheiten“ Software das Team typischerweise in einer Iteration (auch „Sprint“ genannt) abschließt. Diese Zahl sollte nur zur Planung von Iterationen verwendet werden. Der Vergleich von Teamgeschwindigkeiten ist Unsinn, da die Metrik auf nicht objektiven Schätzungen basiert. Die Behandlung der Geschwindigkeit als Erfolgsmaßstab ist unangemessen, und die Umwandlung einer bestimmten Geschwindigkeit in ein Ziel verzerrt ihren Wert für die Schätzung und Planung.
• Öffnungs— / Schließraten – Wie viele Produktionsprobleme innerhalb eines bestimmten Zeitraums gemeldet und geschlossen werden. Der allgemeine Trend ist wichtiger als die spezifischen Zahlen.

Wenn eine oder alle dieser Metriken außerhalb des erwarteten Bereichs liegen oder in alarmierende Richtungen tendieren, gehen Sie nicht von einer Ursache aus. Sprechen Sie mit dem Team, erhalten Sie die ganze Geschichte und lassen Sie das Team entscheiden, ob es Anlass zur Sorge gibt und wenn ja, wie es behoben werden kann.

Sie können die Hauptursachen aus den Zahlen nicht kennen oder annehmen, aber diese Metriken geben Ihnen einen Einblick, wo Ihre wesentlichen Prozesse Aufmerksamkeit benötigen. Eine hohe Öffnungsrate und eine niedrige Abschlussrate über einige Iterationen hinweg können beispielsweise bedeuten, dass die Produktionsprobleme derzeit eine niedrigere Priorität haben als neue Funktionen, oder dass sich das Team darauf konzentriert, die technische Verschuldung zu reduzieren, um ganze Problemklassen zu beheben, oder dass die einzige Person, die wusste, wie man sie behebt, aufhört oder etwas anderes. Sie können die Ursachen aus den Zahlen nicht kennen oder annehmen.

Produktionsanalyse

• Mittlere Zeit zwischen Ausfällen (MTBF)
• Mittlere Zeit bis zur Wiederherstellung / Reparatur (MTTR)

Beides sind allgemeine Kennzahlen für die Leistung Ihres Softwaresystems in der aktuellen Produktionsumgebung.

• Anwendungsabsturzrate — Wie oft eine Anwendung fehlschlägt geteilt durch wie oft sie verwendet wurde. Diese Metrik bezieht sich auf MTBF und MTTR.

Beachten Sie, dass keine dieser drei Metriken Auskunft über einzelne Funktionen oder betroffene Benutzer gibt. Je kleiner die Zahlen, desto besser. Moderne Betriebsüberwachungssoftware macht das Sammeln detaillierter Metriken für einzelne Programme und Transaktionen relativ einfach, aber es erfordert Zeit und sorgfältige Überlegungen, geeignete Bereiche für Warnungen und / oder Auslöser für die Skalierung nach oben oder unten (für Cloud-basierte Systeme) einzurichten.

Wir möchten, dass unsere Software niemals ausfällt, aber das ist statistisch unwahrscheinlich. Wenn unsere Software ausfällt, möchten wir, dass sie niemals kritische Daten verliert und sofort wiederhergestellt wird, aber das kann außerordentlich schwierig sein. Wenn Ihre Software jedoch Ihre Einnahmequelle ist, lohnt sich der Aufwand.

Über MTBF und MTTR hinaus basieren feinkörnigere Messungen auf einzelnen Transaktionen, Anwendungen usw. und spiegeln den Geschäftswert und die Kosten für die Behebung von Fehlern wider. Wenn Ihre Transaktionsverarbeitungsanwendung einmal in hundert abstürzt, sich aber in ein oder zwei Sekunden erholt und keine kritischen Informationen verliert, kann diese Absturzrate von 1 Prozent gut genug sein. Aber wenn jeder Absturz einer App ist, die 100.000 Transaktionen pro Tag ausführt, verliert einen $ 100 Verkauf, und kostet $ 50 auf dem Back-End zu beheben, dass 1 Prozent Absturzrate wird eine Priorität sein. Das Beheben wirkt sich erheblich auf das Endergebnis aus.

Sicherheitsmetriken

Sicherheit ist ein Aspekt der Softwarequalität, der oft erst später (oder zu spät) übersehen wird. Sicherheitsanalysetools können im Build-Prozess verwendet werden, zusätzlich zu spezielleren Auswertungen und Stresstests. Sicherheitsanforderungen sind oft einfach und sinnvoll, aber das Softwareentwicklungsteam muss sie und die daraus abgeleiteten Metriken berücksichtigen.

Das gesamte Spektrum der Sicherheitspraktiken und der damit verbundenen Metriken geht über den Rahmen dieses Artikels hinaus, aber wie bei agilen Prozessmetriken und Produktionsmetriken gibt es einige spezifische Metriken, die für die allgemeine Zufriedenheit Ihrer Kunden von großer Bedeutung sein können.

• Endpunktvorfälle – wie viele Endpunkte (mobile Geräte, Workstations usw.) haben eine Virusinfektion über einen bestimmten Zeitraum erlebt?
• MTTR (mean time to repair) — In Sicherheitsmetriken ist dies die Zeit zwischen der Entdeckung einer Sicherheitsverletzung und einer bereitgestellten, funktionierenden Abhilfe. Wie bei der oben genannten Produktions-MTTR-Metrik sollte die Sicherheits-MTTR über bestimmte Zeitintervalle verfolgt werden. Wenn der MTTR-Wert im Laufe der Zeit kleiner wird, können Entwickler Sicherheitsprobleme wie Fehler und deren Behebung effektiver verstehen.

Für diese beiden Metriken bedeuten kleinere Zahlen im Laufe der Zeit, dass Sie sich in die richtige Richtung bewegen. Weniger Endpoint Incidents sprechen für sich. Da der MTTR-Wert kleiner wird, können Entwickler Sicherheitsprobleme wie Fehler und deren Behebung effektiver verstehen.

Weitere Möglichkeiten, Sicherheitsmetriken auf die Softwareentwicklung anzuwenden, finden Sie in den Artikeln Anwendungssicherheit für agile Projekte und Sicherheitsbedrohungsmodelle: Eine agile Einführung.

Ein Hinweis zu Quellcode-Metriken

Heute ist es einfach, einen Quellcode-Scanner in Ihre Build-Pipeline einzubinden und Unmengen objektiver Metriken zu erstellen. Es gibt empirische Durchschnittswerte und vorgeschlagene Bereiche sowie logische Argumente für die relative Bedeutung dieser Metriken. In der Praxis sind diese Tools jedoch am hilfreichsten, um Codierungsstile durchzusetzen, bestimmte Anti-Muster zu kennzeichnen und Ausreißer und Trends zu identifizieren.

Es lohnt sich einfach nicht, an den Zahlen hängen zu bleiben. Hier ist ein Beispiel zur Erläuterung.

Angenommen, Sie finden eine Methode in einer Klasse mit einer lächerlichen Metrik, z. B. einer NPATH-Komplexität von 52 Millionen. Das bedeutet, dass 52 Millionen Testfälle erforderlich wären, um jeden Pfad durch den Code vollständig auszuführen. Sie könnten den Code in eine einfachere Struktur umgestalten, aber bevor Sie das tun, überlegen Sie, was die geschäftlichen Auswirkungen wären. Die Chancen stehen gut, dass der alte, hässliche Code gut genug funktioniert (obwohl seine Testabdeckung möglicherweise unzureichend ist). Das Anti-Pattern an das Team zu rufen, damit es nicht wiederholt werden kann, ist ein wertvolles Lernen, aber das Beheben würde wahrscheinlich nicht die Nadel in einer relevanten Geschäftsmetrik bewegen.

Es ist am besten, wenn das Team dem Grad der Compliance und den Regeln zustimmt, denen sein Code unterliegt, aber beachten Sie, dass die Untersuchung von Ausreißern und die Sorge um Trend-Blips viel Zeit verschwenden können.

Dann setzen Sie alles zusammen: Erfolg ist die ultimative Metrik

Die Freude an der Verwendung automatisierter Tools zur Verfolgung und Messung von Qualitätsmetriken und Benutzeranalysen besteht darin, dass Sie Zeit haben, sich auf die wirklich wichtigen Metriken zu konzentrieren: Erfolgsmetriken.

Verwendung von Metriken für den Erfolg

Unternehmen haben Ziele. Ziele implizieren Fragen wie „Wie sieht Erfolg aus?“ oder „Wie wird sich das auf das Kundenverhalten auswirken?“ Richtig quantifizierte Fragen implizieren Metriken.

Anders ausgedrückt: Metriken sollten nur zur Beantwortung von Fragen und zum Testen von Hypothesen verwendet werden, die ein bestimmtes Geschäftsziel unterstützen. Und dies sollte nur so lange geschehen, wie die Fragen und Antworten dazu beitragen, positive Veränderungen voranzutreiben.

Haben nicht alle Projekte im Allgemeinen invariante Ziele, Fragen und Hypothesen und damit Metriken?

Ja, aber nur aus der Sicht des Unternehmens. Maßnahmen auf Geschäftsebene wie Benutzerengagement, Abschlussraten, Umsatzgenerierung usw. geben Feedback dazu, wie sich das Unternehmen in der realen Welt entwickelt. Änderungen an Software, die sich auf das Unternehmen auswirken, wirken sich auch auf diese Art von Metriken aus.

Bei einer feineren Auflösung kann jedes Feature und jede User Story eine eigene Erfolgsmetrik haben — vorzugsweise nur eine, die direkt mit einem Wertmaßstab für den Kunden zusammenhängt. Das Abschließen von neun von zehn Storys in einem Sprint für Funktionen, die nie bereitgestellt werden, ist Verschwendung und kein Erfolg. Geschichten zu liefern, die Kunden nicht wollen oder verwenden, ist Verschwendung, kein Erfolg. Die Bereitstellung einer Story, die einen Aspekt der Benutzerzufriedenheit verbessert, ist ein Erfolg. Die Bereitstellung einer Story, die nachweislich die Benutzerbindung nicht verbessert, ist ebenfalls ein Erfolg, da Sie etwas gelernt haben, das nicht funktioniert hat, eine Geschäftshypothese ungültig gemacht und Ressourcen für andere Wege freigesetzt haben.

So formulieren Sie eine Werthypothese

Eine Werthypothese ist eine Aussage darüber, was Ihrer Meinung nach als Ergebnis der Bereitstellung eines bestimmten Merkmals passieren wird. Die Beziehung zwischen der Software, dem gewünschten Ergebnis und den Metriken bildet die Werthypothese für das Feature (oder System oder Story oder Upgrade usw.). Die Hypothese sollte ausdrücken, wie sich die Zielmetrik voraussichtlich ändern wird, in welchem Zeitrahmen und um wie viel sie als effektiv angesehen werden soll. Sie müssen mindestens mit dem Team und dem Product Owner sprechen, um herauszufinden, was diese Funktion oder Geschichte in Bezug auf das Unternehmen schaffen oder verbessern soll, um ihre Werthypothese zu formulieren. Möglicherweise müssen Sie ein paar Mal „Warum“ fragen (wie ein Dreijähriger), um die Schichten unausgesprochener Annahmen abzuziehen. sei geduldig. Wenn Sie verstehen, was der Geschäftswert sein soll, können Sie beginnen, die Fragen zu stellen, die Sie zu den Metriken führen, die die Frage beantworten.

Zum Beispiel kann eine „technische“ Geschichte zur Verbesserung der Geschwindigkeit eines E-Commerce-Checkout-Prozesses die Annahme haben, dass ein schnellerer Checkout zu mehr Umsatz führt. Aber warum denken wir das? Verlassen viele Leute ihre Einkaufswagen während des Checkout-Prozesses? Wenn dies der Konsens ist (da dieser Konsens durch Basisdaten gestützt wird), lautet die Werthypothese möglicherweise: „Wir glauben, dass ein schnellerer Checkout-Prozess zu geringeren Abbruchraten des Warenkorbs führt, was zu höheren Umsätzen und einer verbesserten Benutzererfahrung führt.“

Sie können wahrscheinlich davon ausgehen, dass Benutzer einen schnelleren Checkout mögen, aber es tut nicht weh zu fragen, ob sie es bemerkt haben. Cart-Abbruchraten und Verkäufe können vor und nach der Einführung des neuen Prozesses für einen bestimmten Zeitraum gemessen werden. Wenn die Warenkorbabbruchrate sinkt und der Umsatz steigt (über statistische Schwankungen hinaus), stützen die Beweise die Hypothese und Sie könnten überlegen, ob noch weitere Geschwindigkeitsverbesserungen gerechtfertigt sind. Wenn dies nicht der Fall ist, lassen Sie diese Metrik in den Hintergrund treten (oder entfernen Sie sie, wenn sie ablenkt) und richten Sie Ihre Aufmerksamkeit auf die nächste Hypothese. Wenn die Warenkorbabbruchrate sinkt, der Umsatz jedoch unverändert bleibt, messen Sie über einen längeren Zeitraum oder überdenken Sie den angenommenen Zusammenhang zwischen Warenkorbabbruch und Umsatz. Mit anderen Worten, verwenden Sie Metriken, um zu lernen, und nur so lange, wie sie sich als nützlich erweisen, um Verbesserungen voranzutreiben.

In einigen Fällen kann die Hypothese eindeutig falsch sein, daher lassen wir die Metriken fallen (und machen die Softwareänderungen rückgängig!) nach einigen Tagen. In anderen Fällen kann die Hypothese richtig sein, so dass wir weiterhin Verbesserungen in diesem Bereich seit Jahren vorantreiben.

Sechs Heuristiken zur effektiven Nutzung von Metriken

Wir haben gesehen, dass subjektive Softwaremetriken für den Geschäftserfolg weitaus wichtiger sind als die traditionellen, objektiven Qualitätsmetriken der Vergangenheit. Der Aufwand, relevante Geschäftsmetriken für Features zu finden und zu messen, wird durch die gewonnenen Erkenntnisse und Lernmöglichkeiten aufgewogen. Geschäftsbedingungen und Chancen ändern sich ständig, also anstatt eine Formel zu folgen, die zerbrechlich sein kann, hier sind sechs Faustregeln oder Heuristiken, um Fokus und Flexibilität zu erhalten. Mögen sie Sie auf Ihrem Weg zu Qualitätssoftware und Geschäftserfolg begleiten!

1. Metriken können dir die Geschichte nicht erzählen; nur das Team kann das tun (mit einer Hutspitze zu Todd DeCapula).
2. Schneeflocken zu vergleichen ist Verschwendung.
3. Sie können fast alles messen, aber Sie können nicht auf alles achten.
4. Kennzahlen zum Geschäftserfolg treiben Softwareverbesserungen voran, nicht umgekehrt.
5. Jedes Merkmal schafft einen Mehrwert; entweder messen oder nicht.
6. Messen Sie nur, was jetzt zählt.