Top 10 Produktivitätskennzahlen für die Softwareentwicklung
Top 10 Metriken bei der Softwareentwicklung zur Messung der Produktivität - Bild
Zurück

Top 10 Metriken bei der Softwareentwicklung zur Messung der Produktivität

Software-Messung ist eine Basiskomponente der guten Softwareentwicklung. Sie können genau verstehen, wann Ihr Entwicklungsteam seine beste Arbeit leistet und welche Faktoren dazu beitragen.

Wenn ein Manager über relevante Daten verfügt, kann er auch Engpässe des Projekts frühzeitig und effektiv erkennen, Risiken reduzieren und Fehler beseitigen. Mehrere Studien haben gezeigt, dass die Behebung eines Fehlers im Code umso kostspieliger ist, je länger es dauert, bis er entdeckt wird. 

Messung hilft Ihnen auch dabei, Szenarien zu erkennen, in denen aufgrund unklarer oder widersprüchlicher Projektanforderungen "nicht alles zusammenpasst". Eine Studie im Jahr 2008 schätzte, dass es bei 68% der befragten Unternehmen aufgrund der schlechten Projektanforderungen statistisch unwahrscheinlich war, ein erfolgreiches Projekt zu haben. Insbesondere waren sie in meisten Fällen mit folgenden Problemen konfrontiert:

  • Ein um 160 % höheres Budget als ursprünglich vorgesehen.
  • Sie benötigen 180 % mehr Zeit als erwartet.
  • Sie liefern weniger als 70 % der erwarteten Funktionalität.

Es ist schwierig, diese Balance einzuhalten, und es ist noch schwieriger, die besten individuellen Produktivitätsmetriken für die Softwareentwicklung zu finden, die verfolgt werden können.

Warum? Sie schaffen es nicht, ihre Prozesse zu kalibrieren und Produktivitätskennzahlen für die Softwareentwicklung festlegen, welche tatsächlich nützliche Erkenntnisse über den Produktzustand und die Teamleistung liefern. Manager entscheiden sich auch oft dafür, zu wenige oder zu viele Parameter zu verfolgen, nur um Informationen zu sammeln. Das Problem bei solchem Denken besteht darin, dass es selten zu einer wirklich datengetriebenen Softwareentwicklung führt.

Messungen sollten nur zur Beantwortung von Geschäftsfragen bereitgestellt werden. Sie sollten Ihrem Unternehmen helfen, zu verstehen, wie Sie dem Endbenutzer noch mehr Nutzen bieten können. Zahlen in Bezug auf Betriebszeiten, Serviceverfügbarkeit und Einhaltung des Budgets sind wichtig, können Ihnen jedoch nicht die vollständige Geschichte der Leistung Ihres Engineering-Teams und des Produktzustands erzählen.

Eine von Gartner im vergangenen Jahr durchgeführte Studie hat gezeigt, dass die meisten CIOs das folgende Gleichgewicht für das Beste halten, wenn es um Metriken geht:

  • 56% der nachverfolgten Metriken sollten sich auf Geschäftsergebnisse beziehen, z. B. Umsatzwachstum, Geschäftsmargen und Einfluss auf die Geschäftsstrategie.
  • 44% sollten mit IT-Bereitstellung zusammenhängen.

Es ist schwierig, die Balance der Messungen einzuhalten, und es ist noch schwieriger, die besten individuellen Softwaremetriken zu finden, die verfolgt werden können.

Im folgenden Beitrag versuchen wir Ihnen zu erklären, was Metriken im Software Engineering sind, wie sie verwendet werden können, um verschiedene Aspekte des agilen Lebenszyklus Ihrer Produkte zu bewerten sowie zu verbessern und letztendlich, wie Sie die Produktivität Ihrer Teams messen und die angestrebten Geschäftsergebnisse erzielen können.

Wer braucht Produktivitäts-Metriken bei der Softwareentwicklung?

Die kurze Antwort lautet: Unternehmen, die effektive Software entsprechend den spezifischen Anforderungen pünktlich und im Rahmen des Budgets bereitstellen möchten.

Indem Sie Messungen in verschiedenen Bereichen anwenden, können Sie feststellen, wo Änderungen erforderlich sind. Nur die Messung weicher Faktoren allein kann neue Erkenntnisse darüber liefern, wie ein bestimmter Prozess funktioniert, wie er verbessert werden kann und wie sich diese Verbesserung auf Ihr Unternehmen auswirkt, z. B. Erhöhung der Vorlaufzeit bis zur Markteinführung.

Bevor wir tiefer in die Messung der Produktivität der Anwendungsentwicklung eintauchen, definieren wir einige Schlüsselbegriffe.

Was ist eine Metrik in der Softwareentwicklung?

Eine Softwaremetrik steht für einen potenziellen Bereich, in dem die Messung effektiv auf ein bestimmtes Softwaremodul oder dessen Spezifikationen angewendet werden kann. Mit anderen Worten, eine Metrik setzt voraus, dass einige Daten aus Ihrem Lebenszyklus der Anwendungsentwicklung entnommen und zur Messung der Produktivität von Software-Entwicklern verwendet werden.

Diese Daten können aus einer oder mehreren Datenquellen stammen. Jeder rückführbare Datenpunkt kann zu einer Metrik werden, um die Leistung Ihres Teams zu messen (obwohl dies nicht sein sollte). Die meisten Produktivitäts-Messwerkzeuge sind bereits mit Dashboards und Analytik-Einheiten ausgestattet, die Sie einrichten können, um alles und jeden zu überwachen.

Aber müssen Sie wirklich auf alle verfügbaren Kennzahlen, Metriken und Indikatoren im Software Engineering achten? Eigentlich nicht.

Oft geraten Manager in die Falle, sich auf einige Daten zu verlassen, nur weil sie leicht zu erhalten sind oder in ihrem Tool leicht verfügbar sind, z. B. historisches Prozent der gebrochenen Build-Prozesse mit einem grafischen Diagramm der Build-Zeiten.

In Wirklichkeit lohnt es sich nur, darauf zu achten, ob der letzte Build kaputt gegangen ist und wie sich die letzten Build-Zeiten verändert haben, anstatt zu versuchen, den Zeitrahmen mit jedem Build-Prozess zu vergleichen, der während des Projekts stattgefunden hat.

Um die optimalen Softwaremetriken für Ihr Projekt auszuwählen, sollten Sie sich auf drei Prinzipien stützen:

  • Sie können nur einen Bereich der Anwendungsentwicklung oder des Prozesses effektiv messen.
  • Es besteht eine Beziehung zwischen dem, was gemessen werden kann und dem, was Sie wissen möchten.
  • Diese Beziehung kann überprüft werden und in Form einer Formel oder eines Modells ausgedrückt werden.

Das Endziel der Verfolgung und Nutzung von Softwaremetriken ist die Steigerung der Produktivität in der Softwareentwicklung.

Was ist Softwareproduktivität?

Softwareproduktivität kann als das Verhältnis zwischen den Funktionswerten der produzierten Software zu den für die Entwicklung erforderlichen Anstrengungen und Kosten definiert werden.

Es gibt viele Möglichkeiten, die Produktivität zu messen, jedoch verwenden die meisten Manager zwei Typen von Metriken:

  • Größenbezogene Metriken geben die Größe der Ergebnisse einer Aktivität an. Zum Beispiel die Zeilen des geschriebenen Quellcodes.
  • Funktionsbezogene Metriken stellen die Menge an nützlichen Funktionen dar, die während eines festgelegten Zeitraums ausgeliefert werden. Das Function-Point-Verfahren und Application-Point-Verfahren sind die am häufigsten verwendeten Metriken für die Softwareentwicklung nach dem Wasserfallmodell, während Story Points die üblichen Metriken für agile Projekte sind.

Die Produktivitätsmetriken, die Sie verfolgen können, sollten das Folgende sein:

  • Konsequent: verwenden Sie klare Definitionen, damit die Zahl eine Bedeutung hat.
  • Überprüfbar: Außenstehende können die Durchführbarkeit der Maßnahmen nachweisen.
  • Verfügbar: kann für das Benchmarking verwendet werden.
  • Wiederholbar: Verschiedene Benutzergruppen erhalten im Wesentlichen die gleiche Zahl.

Wenn Sie bedenken, dass Ihr Entwicklungsteam für die Verfolgung selbst verantwortlich sein sollte, dann sollten Sie sich mit Metriken zufrieden geben, die leicht zu erhalten und zu erreichen sind. Versuchen Sie nicht, alle Softwaremetriken zu verfolgen, die Sie erfassen können. Identifizieren Sie einige Bereiche für die Verbesserung Ihrer Teamleistung, überlegen Sie, welche KPIs diese Bereiche darstellen können, und sammeln Sie Daten, um diese abzuschätzen. Fahren Sie dann mit dem nächsten Bereich zur Verbesserung fort.

Geschäftliche Vorteile von Produktivitäts-Metriken bei der Softwareentwicklung

Das Ziel der Verwendung präziser Metriken und Messungen im Software Engineering besteht darin, die Faktoren zu identifizieren und zu kontrollieren, die die Softwareentwicklung und das Projekt als Ganzes beeinflussen können. Insbesondere trägt die Verwendung von Softwaremetriken zu Folgendem bei:

Präzise Projektplanung

Projektmanager und Teamleiter können mehr Einblicke in das Projekt erhalten und die möglichen Ergebnisse mit höherer Präzision vorhersagen. Zum Beispiel können sie bewerten:

Was kostet jeder Prozess? Sie können die Kosten für das Erfassen der Anforderungen, die Kosten für die Spezifikation und den Entwurf des Systems sowie die Kosten für die Entwicklung und Prüfung des Systems schätzen. Auf diese Weise kann man die Beteiligung jeder Aktivität an den Gesamtprojektkosten verstehen und bessere Prioritäten festlegen.

Ist dieser Prozess effektiv? Schätzen Sie, wie häufig und prägnant Sie neue Einheiten liefern; bewerten Sie die Auswirkungen neuer Praktiken oder Änderungen und setzen Sie Ziele für Prozess- und Produktverbesserungen.

Wie können wir uns weiter verbessern? Sie können die Zeit messen, die für die Durchführung jeder wichtigen Entwicklungsaktivität erforderlich ist, und deren Einfluss auf Qualität und Produktivität abschätzen. Anschließend können Sie die Kosten und Vorteile bestimmter Praktiken vergleichen, um festzustellen, welche die Kosten wert sind. Oder Sie können zwei verschiedene Praktiken vergleichen, um eine bessere Lösung zu wählen: Bitten Sie beispielsweise zwei Teams verschiedene DevOps-Praktiken zu prüfen und bestimmen Sie, welche die Codequalität erhöht.

Verbesserte Leistungen der Softwareentwickler

Produktivitäts-Metriken für die Softwareentwicklung verdeutlichen Leistungserwartungen. Ihr Team bleibt engagiert, da es genau weiß, was von ihm erwartet wird. Metriken übermitteln Ihre Erwartungen und zeigen Ihnen, wie Sie die Produktivität von Entwicklern ohne jede Voreingenommenheit messen können.

Produktivitäts-Metriken für die Softwareentwicklung helfen Ihnen dabei, die Faktoren zu ermittelt, die die Effizienz Ihres Teams behindern, und diese zu beseitigen, was letztendlich zu einem glücklicheren und leistungsfähigeren Team führen würde.

Bessere Produktergebnisse

Die Kombination der oben genannten Faktoren trägt zu vereinfachten Arbeitsabläufen und zur konsistenten Entdeckung neuer Erkenntnisse bei, die bestehende Produktlebenszyklen verbessern können. Sie können die am häufigsten vorkommenden Engpässe erkennen, sofort Maßnahmen ergreifen und besseren Code schneller und zu geringeren Kosten bereitstellen.

Die letzte Frage: wie kann man Software-Produktivität messen? Unsere Antwort: Quantifizieren Sie individuelle Eingaben und achten Sie auf agile Software-Metriken, die wirklich wichtig sind.

Liste der wichtigsten Produktivitäts-Metriken für die Softwareentwicklung, die verfolgt werden sollten

Sie können Ihre Teams trainieren, um ihre beste Arbeit schnell und effektiv durchzuführen, aber wenn Ihr Endprodukt Software ist, die funktioniert, aber keinen Geschäftswert schafft, verfolgen Sie die falschen Metriken.

Um zu verstehen, wie Sie die Produktivität bei der Softwareentwicklung messen können, müssen Sie sowohl geschäftliche als auch agile Metriken verfolgen.

  • Geschäftliche oder anwendungsspezifische Metriken sollten Ihnen mitteilen, wie Verbraucher Ihr Produkt verwenden und ob es den Marktanforderungen entspricht.
  • Agile Metriken sollten verschiedene Aspekte des Entwicklungsprozesses messen.

Machen Sie Ihren Geschäftserfolg zur ultimativen Metrik Ihrer Produktivitätsmessung. Ist Ihr Kunde zufrieden? Stellen Sie das Produkt pünktlich bereit? Wie schnell verbessern sich Ihre Geschäftsergebnisse? Um datengestützte Antworten auf diese Fragen zu erhalten, müssen Sie für jede Produktanforderung spezifische Erfolgskriterien angeben (z. B. Akzeptanzrate von Endbenutzer) und diese Erfolgskriterien den unten beschriebenen Metriken Ihres Projekts zuordnen.

Metriken zur Optimierung der Softwarebereitstellung (1 - 4)

1. Sprint Burndown ist eine der Schlüsselmetriken für agiles Scrum. Ein Burndown-Bericht vermittelt den Charakter der Arbeit, während sich Sprint auf Story-Punkten basiert. Das Ziel des Teams besteht darin, alle Arbeiten entsprechend der Prognose konsequent zu erledigen. 

Dank des Verfolgens dieser Metrik erhalten Sie wichtige Erkenntnisse:

  • Regelmäßig zu früh beendete Sprints können einen Mangel an geplanter Arbeit für einen Sprint bedeuten.
  • Ständig verpasste Sprinttermine können dagegen auf eine Lücke in Ihrer Planung und auf die Tatsache hinweisen, dass Ihr Team zu viel Arbeit zu erledigen hat.
  • Ihr Bericht sollte eine starke Reduzierung der "verbleibenden Werte" aufweisen, anstatt einen dramatischen Rückgang, da letzterer anzeigt, dass die Arbeit nicht in stückweise zugewiesen wurde.
Sprint Burndown
Sprint Burndown

2. Team Velocity Metrik weist die "Menge" an Software aus, die Ihr Team während eines Sprints bereitstellt. Es kann in Story Punkten oder Stunden gemessen werden, und Sie können diese Metrik zur Bewertung und Planung verwenden.

Durch Messung der Geschwindigkeit können Sie:

  • Bessere Liefererwartungen und realistische Sprint-Prognosen festlegen
  • Verstehen, ob Ihr Team blockiert ist (Fallgeschwindigkeit)
  • Unvorhergesehene Herausforderungen erkennen, die bei der Sprint-Planung nicht berücksichtigt wurden
  • Untersuchen, ob Ihre Prozessänderungen zu Ergebnissen führen (stabile oder erhöhte Geschwindigkeit)

Sie sollten auch auf die Schwankungen Ihrer Geschwindigkeit achten. Wenn Sie konstant hohe Volatilität erzielen, bedeutet das, dass ein Prozess jetzt funktioniert, und Sie müssen dies untersuchen.

Anmerkung: Denken Sie daran, dass die Geschwindigkeitsmetrik jedes Teams einzigartig ist und nicht zum Vergleich von Team A und B in Bezug auf Leistung oder Produktivität verwendet werden sollte. Jedes Team hat eine bestimmte Schätzkultur und kann eine andere Interpretation von Story-Punkten haben, die Sie berücksichtigen sollten.

3. Durchsatz gibt die gesamte wertschöpfende Arbeitsleistung des Teams an. Es wird typischerweise durch die Arbeitseinheiten (Tickets) repräsentiert, die das Team innerhalb eines festgelegten Zeitraums abgeschlossen hat. Sie sollten Ihre Durchsatzmetrik an Ihren aktuellen Geschäftszielen ausrichten. Wenn Ihr Ziel darin besteht, in diesem Sprint neue fehlerfreie Module zu veröffentlichen, sollten Sie darauf achten, dass ein Großteil der Fehlertickets behoben wird und so weiter. 

Das Messen des Durchsatzes hilft auch dabei:

  • Zu erkennen, wenn das Team blockiert wird, da die Durchsatzmetrik sinkt.
  • Zu verstehen, wann das Team überlastet ist, indem Sie den durchschnittlichen Durchsatz mit der aktuellen Arbeitsbelastung vergleichen.

Wenn Sie noch einen Schritt weiter gehen möchten, können Sie zusätzliche Leistungskennzahlen für die Softwareentwicklung verfolgen, wie Todd DeCapua, führender Technologieprediger für Application Development Management (ADM) bei HP. Seinen Teams gelang es, die Codequalität jährlich um 25 % und den Durchsatz um 100 % zu steigern, indem sie die Softwarequalität basierend auf den folgenden Metriken neu definierten:

  • Codeintegrität
  • Auswirkungen von Defekten auf Kunden und Betrieb
  • Lieferdatum
  • Qualität der Kommunikation
  • Systemfähigkeit zur Erfüllung von Service Levels
  • Stornierte Fehler, die verschwendete Zeit für Fragen und Antworten eliminierten.

4. Cycle Time steht für die Gesamtzeit, die vom Beginn der Arbeit an einem Item (z. B. Ticket, Bug, Aufgabe) bis zu dessen Abschluss vergeht.

Zykluszeit-Metrik
Zykluszeit-Metrik

Mit dieser Metrik können Sie abschätzen, wie schnell Sie Benutzern neue Funktionen bereitstellen können. Es ist auch eine weitere Möglichkeit, die aktuelle Geschwindigkeit Ihres Teams für verschiedene Aufgaben zu verstehen, indem Sie den Gesamtdurchsatz nach Status oder Problemtyp auf die durchschnittliche Zeit herunterbrechen. Sie können die genauen Engpässe ermitteln, die sich auf die Leistung des Teams auswirken, und genauere Erwartungen festlegen.

Wenn Sie beispielsweise Ihre durchschnittliche Fehlerzykluszeit kennen, können Sie den Benutzern die richtigen Erwartungen kommunizieren. Und indem Sie Ihre durchschnittliche Feature-Zykluszeit messen, können Sie die Erwartungen der Stakeholder bedienen und genaue Prognosen liefern.

Schlüsselkennzahlen zur Messung der Wartbarkeit von Software (5 – 8)

Im agilen Ansatz steht Wartbarkeit für jeden Prozess, der dazu beiträgt, Ihren Verbrauchern Veränderungen zu liefern. Wenn Sie im Rahmen Ihres Continuous Integration and Continuous Delivery (CI/CD)-Frameworks die Bereitstellungszeiten verlängern und Code-Updates vereinfachen möchten, sollten Sie die nächsten Softwareleistungsmetriken überwachen:

5. Vorlaufzeit – die Zeit zwischen der Definition einer neuen Funktion und ihrer Verfügbarkeit für den Benutzer. Es hilft Ihnen einzuschätzen, wie gut Ihr Team bisher abschneidet.

6. Mittlere Reparaturzeit (MTTR) – wie schnell können Sie Lösungen für die Verbraucher bereitstellen.

7. Codeabdeckung – die in LOC gemessene Codemenge, die von einem Unit-Test abgedeckt wird.

8. Fehlerraten – durchschnittliche Anzahl von Fehlern, die generiert werden, wenn neue Funktionen bereitgestellt werden. Es kann Ihnen dabei helfen, abzuschätzen, ob Sie einen Mehrwert liefern oder nur halbgaren Code herausbringen, um den Erwartungen nach regelmäßigen Weiterentwicklungen gerecht zu werden.

Darüber hinaus möchten Sie möglicherweise einige allgemeine Statistiken zum Anwendungszustand sammeln, um einen besseren Einblick in den Zustand der Anwendung zu erhalten und Ihre Aktionen an diesen Daten auszurichten. Speziell:

  • Fehleranzahl
  • CPU-/Speicherauslastung
  • Reaktionszeit
  • Transaktionen
  • Festplattenplatz
  • Müllbeseitigung
  • Thread-Zählungen

Schlüsselkennzahlen zur Messung der Effektivität Ihrer Anforderungen (9 – 10)

Agile Methodik begrüßt und berücksichtigt Veränderungen in jeder Phase des Projekts. Veränderte Anforderungen können sich jedoch negativ auf die Leistung Ihres Teams auswirken und zu verschwendeten Stunden und Code führen.

Ihr Ziel hier ist es, sicherzustellen, dass Ihr Team sowohl bei statischen als auch bei dynamischen Anforderungen im konstanten Tempo arbeiten kann. Die folgenden Metriken sollen Ihnen dabei helfen, einige Erkenntnisse darüber zu gewinnen.

9. Aufgabenvolumen + durchschnittliche Schätzungen – Die Anzahl der Aufgaben, die Ihr Team angesichts von Veränderungen erledigen kann, im Vergleich zu den durchschnittlichen Schätzungen hilft Ihnen zu verstehen, wie konsequent Ihr Team seine Arbeit erledigt.

10. Rückfall – eine hohe Zahl bedeutet, dass jemand im Workflow nicht den gleichen Standard hatte wie jemand, der nachgelagert ist. Dies ist ein guter Indikator für unvollständige oder inkonsistente Anforderungen, die Sie möglicherweise untersuchen möchten.

Vorlaufzeit, Geschwindigkeit und Entwicklungszeit – alle messen, wie lange Ihr Team braucht, um Aufgaben unter Berücksichtigung der Anforderungsänderung abzuschließen.

Schlussfolgerung

Es gibt noch mehr agile Softwarequalitätsmetriken, die Sie verfolgen können. Aber am Ende des Tages sollten Sie nicht von Ihrem Hauptziel abgelenkt werden – Wert liefern und Ihrem Engineering-Team und Ihren Kunden gegenüber fair bleiben.

Jedes Projekt wird einzigartige Komplexitäten und Schwierigkeiten aufweisen. Sie sollten zwar einige grundlegende Softwareproduktivitäts-Kennzahlen festlegen, die Sie konsequent verfolgen, aber lassen Sie sie offen für Diskussionen mit Ihrem Team und den wichtigsten Teilhabern.

Müssen Sie den Reifegrad Ihres Softwareentwicklungsprozesses beurteilen? Kontaktieren Sie uns für Hilfe.

Weitere Artikel

Wir haben eine Lösung für Ihre Anforderungen. Senden Sie uns einfach eine Nachricht, und unsere Experten werden sich so schnell wie möglich mit Ihnen in Verbindung setzen.

Vielen Dank!

Wir haben Ihre Anfrage erhalten und werden Sie in Kürze kontaktieren.