Metriken des Erfolgs in der Software-Entwicklung

Ich werde oft gefragt: Wie machen Sie das? Wie führen Sie ein erfolgreiches Projekt nach dem anderen durch? Die Antwort ist einfach. Metrik. Ein Erfolg, der nicht gemessen werden kann, ist nicht wiederholbar.

Was Metriken sind - und was sie nicht sind

Es gibt mehrere potenzielle Metriken, die in Geschäftsprozessen allgemein angewendet werden können. KPIs sind nur eine von vielen. KPIs im Kontext ist keine Metrik an sich. Sie sind ein Indikator, der in seinem Endresultat auf zählbaren Parametern basiert. Bevor ich auf das Wesentliche dieses Blogbeitrags eingehe, möchte ich noch einige zusätzliche Worte über Prozesse, Metriken, Mentalität und Unternehmenskultur sagen.

Metriken können nicht ganz allein für sich allein arbeiten, um eine erfolgreiche Projektdurchführung zu garantieren. Die Menschen müssen zu Größe befähigt werden, eine Can-do-Mentalität ist unerlässlich, und eine freundliche Einstellung der Unternehmen zu „Trial and Error“ ist ein Muss, damit die Metriken erfolgreich umgesetzt werden können.

Einige sind der Meinung, dass das Reporting für den Erfolg unerlässlich ist. Das Reporting ist es, aber nicht das Reporting über die Zeitkontrolle, sondern das Reporting für die Kundenabrechnung. Diese zwei sind völlig unterschiedliche Dinge. Die eine zeigt eine Kein-Vertrauen-Mentalität, die für Qualitätslieferungen untragbar ist, während letzteres eine Notwendigkeit ist, um die aufgewendete Zeit zu rechtfertigen.

In ihrer Gesamtheit ist die aufgewendete Zeit, wie diese Zeit berichtet, weder eine Metrik, die den Erfolg garantiert, noch ist Wirkungserfolg irgendeine Form. Zeit ist eine Frage der Fähigkeit und des Willens zum Erfolg, also subjektiv und keine Metrik, die in einer von Daten beherrschten Welt angewendet werden könnte.

Grundfrage: Welche Metriken können in der Software-Entwicklung angewendet werden?

I impliziere, dass die Software-Entwicklung im Jahr 2020 auf der Grundlage agiler Methoden durchgeführt wird. Agile Entwicklung beschreibt wiederum in ihrer Gesamtheit einen Prozess. Die entscheidende Frage ist: Gibt es Metriken in einem Verfahren? Ja, die gibt es, aber nicht die, nach denen Sie wahrscheinlich suchen. Bei der Software-Entwicklung könnten einige nach der Anzahl der Commits an ein Code-Repository suchen oder nach der Anzahl der Codezeilen, die von einem Software-Entwickler in einem bestimmten Zeitraum geschrieben wurden. Keine von ihnen ist eine qualitative Metrik. Warum kann die Code-Menge keine Metrik sein, fragen vielleicht manche? Weil, um ein qualitatives Ergebnis zu garantieren, Quantität keine qualifizierte Metrik sein kann. Auch hier haben subjektive Metriken keinerlei Einfluss auf den Erfolg.

Lassen Sie mich eine Idee beschreiben: Was wäre, wenn Erfolg ein Ergebnis von Innovation wäre? Innovation wäre als Metrik gerechtfertigt, aber wiederum nur subjektiv. Innovation lässt sich mit Einsteins Relativitätstheorie vergleichen. Je nach dem Punkt des Betrachters im Raum bewegt sich die Zeit langsamer oder schneller. Innovation ist dasselbe. Für einige klingt sie innovativ, für andere, die die grundlegenden Veränderungen nicht verstehen, ist sie nur eine Wiederholung des “Alten”.

Unterm Strich gibt es zwei Gruppen von Metriken, die wir anwenden können:

1. Software-Metriken und
2. Code-basierte Metriken.

Um die gesamte Bandbreite eines Projekts abzudecken (selbst bei einer langfristigen Software-Verpflichtung), müssen wir beide metrischen Gruppen verfolgen. Lassen Sie uns nun die auf dem Code basierenden Metriken eine nach der anderen betrachten und sehen, wie wir aus ihnen einen Nutzen ziehen können.

Code-Qualität

Code-Qualitätsmetriken messen den Software-Zustand während eines automatisierten Prozesses von Code-Reviews. In realen Situationen bedeutet eine niedrige Punktzahl für die Codequalität, dass der Code zu kompliziert ist und es wahrscheinlich zu schwierig sein wird, die Funktionalität zu erweitern, und selbst Supportaktivitäten könnten sich nach dem Start als schwierig erweisen.

Die kritischsten Code-Qualitätsmetriken sind:

• Wartbarkeitsindex
• Zyklomatischer Komplexitätsgrad
• Vererbungstiefen-Score
• Kopplung von Klassen
• Anzahl der produzierten Code-Zeilen

Qualitätsmetriken

Die Qualitätsmetriken für das Testen von Software beziehen sich auf den Reifegrad des Codes und die Produktionsreife eines Softwareprodukts. Die Testqualitätsmetriken ermöglichen auch ein gewisses Feedback über die Produktivität eines QA-Teams, wenn Software-Fehler minimiert werden. QAs tragen auch zu qualitativ hochwertigen Software-Rollouts bei.

• Testabdeckung
  Der Begriff “Testabdeckung” bezieht sich auf den Prozentsatz der Softwareanforderungen, die mit programmatischen Testfällen (manchmal auch als Unit-Tests bezeichnet) abgedeckt werden. Durch die Aufrechterhaltung einer hohen Testabdeckung wird die Konformität der Software mit der Softwareanforderungsspezifikation (SRS) verbessert.
• UAT-Test
  Mängel, die während der Benutzerakzeptanztests (UAT) gefunden werden, wirken sich auf die Qualität der Software vor dem Produktionsstart aus. Die Anzahl der in dieser Metrik entdeckten Fehler sollte ausreichend niedriger sein als die entsprechende Anzahl in früheren Phasen. Wenn die Anzahl der Fehler nahe an der Anzahl der in früheren Phasen gefundenen Fehler liegt, müssen sowohl die Test- als auch die Software-Entwicklungsphase verbessert werden.
• Produktionsfehler
  Fehler, die in die Produktion durchschlüpfen, können Einnahmeverluste verursachen. Sie sollten sicherstellen, dass mindestens 95% aller Fehler vor der endgültigen Software-Version behoben sind.

Verfügbarkeit

Die Verfügbarkeit von Software ist eine wesentliche metrische Gruppe, da Endbenutzer dazu neigen, eine Software-Anwendung aufzugeben, die aus UX-Perspektive problematisch oder schwierig zu verwenden ist. Diese Metrik zeigt auch die Effizienz eines Entwicklungsteams beim Testen, bei der Fehlerbehebung und bei der Verbesserung von Leistung, Stabilität und Benutzerfreundlichkeit.

• MTBF - Durchschnittliche Zeit zwischen Ausfällen
  Die MTBF-Metrik kann zur Vorhersage von Ausfällen eines Software-Produkts und zur Messung der Arbeit eines Support-Teams verwendet werden. Diese Metriken weisen auf eine unzureichende Überwachung der Systemleistung oder eine geringe Qualität der in der Vergangenheit geleisteten Arbeit hin.
• MTTR - Durchschnittliche Zeit bis zur Wiederherstellung/Reparatur
  Die MTTR-Metrik gibt an, wie viel Zeit ein Team im Durchschnitt damit verbringt, Softwareprobleme zu beheben. Es gibt zwei Sub-Metriken, die Reparaturzeit, die nur die aktive Wiederherstellungszeit, das Testen und die Rückkehr zu einem funktionsfähigen Zustand umfasst. Die zweite Submetrik zur MTTR ist die Wiederherstellungszeit, die von der anfänglichen Problemerkennung oder -meldung an beginnt und sich über die Überanalyse bis zur endgültigen Reparatur erstreckt und sich entwickelt.
  
  Insbesondere wenn Dritte beteiligt sind und ein SLA für die Software-Wartung vorhanden ist, sollten beide Parteien anerkennen, welche Metriken zur Aufrechterhaltung der Vereinbarung verwendet werden. Eine niedrige MTTR-Punktzahl definiert ein Softwareprodukt mit der richtigen Architektur, wodurch lange Ausfallzeiten und potenzielle Umsatzverluste vermieden werden.
• Nichtverfügbarkeit
  Die Nichtverfügbarkeit in einem Softwareprodukt gibt an, wie oft innerhalb eines festgelegten Zeitraums eine Anwendung fehlgeschlagen ist. Diese Metrik hilft Software-Ingenieuren bei der Analyse und der Entwicklung der Lösungsverfügbarkeit.
  
  Eine 100%ige Betriebszeit zu erreichen, könnte auch keine gute Idee sein, besonders wenn ein Software-Produkt frisch auf den Markt kommt. Möglicherweise möchten Sie einige Ausfallzeiten beim Lasttest oder beim absichtlichen Absturz der Anwendung berücksichtigen - und messen, was hinter den Kulissen passiert. Dies könnte helfen, zukünftige Fälle in bestimmten Situationen vorherzusagen oder sogar Performance-Probleme aufzuzeigen, die nie entdeckt worden wären.
• Seitenladezeit-Metrik (nur für Web)
  Die Seitenladezeit ist eine häufig verwendete Metrik in webbasierten Anwendungen (einschließlich SPA- und PWA-Anwendungen). Sie gibt die Geschwindigkeit an, mit der eine Anwendung von einem Endbenutzer vollständig genutzt werden kann. Diese Metrik ist nicht in Stein gemeißelt und kann sich von Standort zu Standort des Endbenutzers unterscheiden.
  
  Es sollte auch kontinuierlich verbessert werden, da es hauptsächlich die Benutzerfreundlichkeit einer Webanwendung betrifft. Webapplikationen sollten innerhalb eines Seitenladelimits von 2-3 Sekunden bleiben. Alles, was niedriger ist, ist besser und wird die Konversionsraten erhöhen. Die Seitenladegeschwindigkeit ist auch ein Index für Suchmaschinen, der eine Webseite in den organischen Ergebnissen einordnet.

Sicherheit und Penetration

Die Gruppe Sicherheitsmetriken gibt an, welche Teile der Software anfällig sein könnten und Verwaltungsaktivitäten benötigen, um unerwünschte Gäste zu verhindern. Obwohl Penetrationstests eine gute Praxis vor der Veröffentlichung von Software sind, kann diese Metrik niemals kugelsicher sein. Im Allgemeinen sollten Sie die in der Sicherheitsindustrie dargelegten Trends verfolgen.

• Anzahl der durch regelmäßige Penetrationstests festgestellten Schwachstellen
  Diese Metrik gibt die Gefährdung durch Sicherheitsrisiken an. In einem Best-Case-Szenario sollten die erreichten Punktzahlen mit zunehmender Projektreife abnehmen. Eine steigende Anzahl von entdeckten Schwachstellen bedeutet, dass bestimmte Freigabeprozesse möglicherweise nicht eingehalten wurden oder dass Codeabdeckungseinheitstests für neu hinzugefügten Code/Features übersprungen wurden.
• Anzahl offener Schwachstellen
  Die Anzahl der bereits geschlossenen oder gepatchten Schwachstellen gibt kein vollständiges Bild von der Sicherheit einer Lösung. Diese Metrik muss direkt mit der Anzahl der Sicherheitslücken verglichen werden, die - noch - nicht behoben sind. Diese Metrik ermöglicht es, den Fokus auf diesen kritischen Aspekt von Software-Implementierungen zu legen. Sicherheitsverbesserungen sollten bei allen Software-Entwicklungsprojekten ein wichtiges Anliegen sein.
• Quantitative Schwere potentieller Sicherheitsvorfälle
  Diese Metrik zeigt den allgemeinen Trend in der Lösungssicherheit und hilft Software-Ingenieuren, Vorfälle und offene Schlupflöcher zu priorisieren, die von vornherein hätten beachtet werden müssen. Master-Kriterien in einem Schweregrad-Ranking konzentrieren sich darauf, wie stark sich ein Ereignis auf die Software-Zuverlässigkeit auswirken kann.

Benutzerzufriedenheit

Sobald wir Benutzer in unsere Softwarelösung hereinlassen, müssen wir mehrere Faktoren messen. Die Zufriedenheit der Benutzer kann durch Umfragen, Bildschirmaufnahmen, Heatmaps, Klickkarten gemessen werden, d.h. die übliche und beste Praxis bietet den Benutzern die Möglichkeit, ihre Erfahrungen zu bewerten. Diese Metrik hilft zu verstehen, welche Funktionen die Benutzer verwenden und schätzen und kann auf die Funktionen erweitert werden, die die Benutzer als nächstes sehen möchten. Folgende Parameter zu Umfragen zur Benutzerzufriedenheit sollten angestrebt werden:

• Entsprach die Anwendung Ihren Erwartungen?
• Hilft die vorhandene Funktionalität bei der Erreichung des Ziels?
• Ist die Benutzerschnittstelle geeignet, das Ziel zu erreichen?
• Ist die Software stabil und leistungsfähig?
• Welche Features würden Sie sich als nächstes wünschen?

OKRs oder KPIs?

Was wir noch nicht definiert haben, ist das System. OKRs verhalten sich gut in Geschäftsprozessen, messen den persönlichen Erfolg oder sogar die Ziele einer ganzen Organisation, denn über feinkörnige Metriken hinaus werden sie sich nicht halten können. KPI steht für Key Performance Index; es wird im Namen angegeben, dass eine Messung oder ein Score das Ergebnis ist.

KPI-Beispiele

Um ein Beispiel für die oben genannten Leistungsindikatoren zu geben, habe ich sie in der untenstehenden synoptischen Tabelle zusammengefasst. Beide Metriken müssen auf einen bestimmten Zeitrahmen angewendet werden. Unten sehen Sie ein Beispiel für monatliche Zielvorgaben auf der Grundlage eines Beispiels für ein Softwareentwicklungsprojekt.

Erfolg oder nicht?

Die oben genannten Indikatoren messen die Qualität des produzierten Codes, die Qualität der Software-Tests, die breitere Systemverfügbarkeit, die Anwendungssicherheit und schließlich die Benutzerzufriedenheit. Die oben genannten Faktoren allein sind jedoch quantitativ und helfen beim Verständnis von Engpässen im Entwicklungsprozess. Sie können verwendet werden, um die Zuverlässigkeit implementierter Software-Entwicklungsprozesse festzustellen.

Eine letzte Frage, die bleibt: Ist dies der Schlüssel zum Erfolg? Und die Antwort ist Nein. Dies ist der quantitative Teil der messbaren Erfolgsfaktoren. Der wichtigste und oft übersehene Erfolgsfaktor bei der Software-Entwicklung ist das Team, das selbst an einer Software-Lösung arbeitet.

Spezielle Teambedürfnisse und Setup

Bei der Einstellung von Software-Ingenieuren achte ich besonders auf bestimmte Merkmale. Während ich nach hochspezialisierten Fähigkeiten suche, suche ich auch nach einer Reihe von Soft Skills. Wenn ein Software-Ingenieur jedoch nicht in die Unternehmenskultur passt, ist es ein No-Go. Wenn sich alle Teammitglieder vor der Einstellung dieser persönlichen Prüfung unterziehen, wird der obige quantitative Ansatz durch den menschlichen Faktor preisgekrönter Teams ergänzt.