Auch wenn praktische Fähigkeiten und Kenntnisse in bestimmten Programmiersprachen, Tools und Technologien der Schlüssel zu einem Vollzeitjob als Softwareentwickler sind, gibt es einen weiteren wertvollen Indikator, der in vielerlei Hinsicht als Voraussetzung für den Erfolg in diesem Beruf angesehen werden kann: Produktivität. Die Produktivitätsmessung ist etwas, das alle professionellen Softwareentwickler verstehen und berücksichtigen müssen, da Leistungsmetriken für jedes Softwareentwicklungsteam im heutigen Geschäftsumfeld von Natur aus wichtig sind.
Warum ist Ihre Produktivität als Entwickler wichtig?
Im Zeitalter der agilen Entwicklung, DevOps und immer kürzerer Software-Release-Zyklen, in denen Entwickler neue Produktversionen so schnell wie möglich ausliefern müssen, verwenden Unternehmen mehrere unterschiedliche Produktivitätsmetriken, um die Leistung einzelner Programmierer und eines Teams als Ganzes zu bewerten. Aus der Sicht eines Entwicklers betrachtet kann die Leistungsmessung eine Reihe wertvoller Zwecke erfüllen und Ihnen dabei helfen, den Fortschritt Ihrer Programmierkenntnisse zu verfolgen, was Ihnen eine kontinuierliche berufliche Weiterentwicklung ermöglichen würde. Hochproduktive Programmierer sind diejenigen, die am Ende umwerfende Gehaltsangebote erhalten und an den aufregendsten Projekten arbeiten. Aber selbst wenn Sie nicht gerade ein Leistungsträger sind und einfach nur einen Job in der Softwareentwicklung wollen und darin einigermaßen erfolgreich sein wollen, Sie müssen dennoch zumindest ein grundlegendes Verständnis von Leistungsindikatoren und deren Verwendung zur Messung der Produktivität Ihres Inputs bei der Arbeit haben. Darüber werden wir heute sprechen.
Kennzahlen zur Messung der Softwareentwicklungsproduktivität
Was sind Produktivitätskennzahlen für die Softwareentwicklung?
Softwareentwicklungsmetriken sind die Bereiche der Programmierarbeit, in denen quantitative Messungen angewendet werden können, um die Leistung, Arbeitsqualität und Produktivität eines Entwicklers zu verfolgen. Jede Produktivitätsmetrik basiert darauf, Daten aus dem Entwicklungsprozess zu erfassen und zur Messung der Produktivität zu verwenden. Da so gut wie nichts im Zusammenhang mit der Softwareentwicklung einfach und unkompliziert ist, könnte man sagen, dass die Messung der Programmierproduktivität branchenweit recht uneinheitlich und fragmentiert ist. Oder einfacher ausgedrückt: Verschiedene Teams und Unternehmen können völlig unterschiedliche Leistungsindikatoren verwenden und dieses Thema aus verschiedenen Blickwinkeln angehen. Sie müssen sich also nicht die Mühe machen, jede einzelne Metrik zu lernen, die von Softwareentwicklungsteams verwendet werden kann.
Welche Arten von Produktivitätsmetriken für die Softwareentwicklung gibt es?
Natürlich gibt es viele unterschiedliche Produktivitätsmetriken, mit denen sich die Leistung auf verschiedenen Ebenen und aus verschiedenen Blickwinkeln messen lässt. Hier sind die häufigsten Arten solcher Produktivitätskennzahlen:
Formale größenorientierte Metriken.
Diese Metriken konzentrieren sich auf die Messung der Größe des Arbeitsergebnisses eines Programmierers, wie z. B. Codezeilen (LOC), Länge der Codeanweisungen, Codekomplexität usw. Diese Metriken gelten in der heutigen Softwareentwicklungsbranche zunehmend als veraltet.
Zeit- und funktionsorientierte Produktivitätskennzahlen.
Es gibt eine Auswahl traditioneller Produktivitätsmetriken, die in der Wasserfall-Softwareentwicklung verwendet werden, wie z. B. aktive Tage, der Umfang der in einem bestimmten Zeitraum gelieferten Funktionalität, Code-Abwanderungsraten, Anzahl der zugewiesenen Aufgaben usw.
Metriken des agilen Entwicklungsprozesses.
Agile Entwicklungsprozessmetriken wie Sprint-Burndown-Bericht, Geschwindigkeit, Durchlaufzeit, Zykluszeit und andere sind heute wahrscheinlich die am häufigsten verwendeten Metriken in Softwareentwicklungsteams. Wir werden später in diesem Artikel ausführlicher auf agile Metriken eingehen.
Betriebsanalytische Kennzahlen.
Dieser Satz von Metriken konzentriert sich auf die Messung der Softwareleistung in der aktuellen Produktionsumgebung. Die Mean Time Between Failures (MTBF), die Mean Time To Recovery (MTTR) und die Anwendungsabsturzrate sind hier die am häufigsten verwendeten Metriken.
Testmetriken.
Softwaretests verfügen über eigene Metriken zur Messung der Qualität von Systemtests, z. B. den Prozentsatz automatisierter Tests, die Codeabdeckung usw.
Kennzahlen zur Kundenzufriedenheit.
Schließlich ist die ultimative Messgröße für jede Software die Endkundenerfahrung, und auch dafür gibt es eine ganze Reihe von Messgrößen, wie z. B. den Customer Effort Score (CES), den Customer Satisfaction Score (CSAT) und den Net Promoter Score (NPS). und andere.
Metriken für die agile Softwareentwicklung
Wie Sie sehen, verliert man sich leicht in den Feinheiten der Software-Produktivitätskennzahlen. Die einzigen, mit denen ein normaler Softwareentwickler gut vertraut sein sollte, sind jedoch die Agile-Metriken, die heute von Softwareentwicklungsteams häufig als Standards für die Messung der Teamproduktivität in verschiedenen Teilen des Softwareentwicklungslebenszyklus verwendet werden. Lassen Sie uns die wichtigsten und am häufigsten verwendeten Agile-Metriken auflisten.
1. Sprint-Burndown.
Sprint-Burndown-Berichte sind eine der Schlüsselmetriken für agile Scrum-Entwicklungsteams. Da der Entwicklungsprozess bei agilen Methoden durch zeitgebundene Sprints organisiert ist, wird Sprint Burndown verwendet, um die Erledigung von Aufgaben während eines Sprints zu verfolgen. Als Maßeinheit werden Stunden oder Story Points verwendet. Das Ziel besteht darin, konsistente Fortschritte zu erzielen und die Arbeit im Einklang mit den ursprünglichen Prognosen zu liefern. Sprint Burndown hilft Teams, das Arbeitstempo zu messen und es bei Bedarf anzupassen.
2. Teamgeschwindigkeit.
Ein weiterer wichtiger Indikator ist die Geschwindigkeit, die ebenfalls auf Stunden oder Story Points als Maßeinheit basiert. Es misst den durchschnittlichen Arbeitsaufwand, den ein Team während eines Sprints erledigt, und wird für die Schätzung und Planung während des gesamten Projekts verwendet. Die Verfolgung der Geschwindigkeit ist wichtig, um sicherzustellen, dass das Team eine konstante Leistung erbringt.
3. Story-Punkte.
Auf der Ebene eines einzelnen Entwicklungsteammitglieds sind Story Points eine wertvolle Messgröße, da die Größe der Storys, die ein Programmierer während jeder Veröffentlichung liefert, ein Indikator für die Produktivität dieses Programmierers ist.
4. Zykluskontrolldiagramm.
Misst die Gesamtzeit vom Beginn der Arbeit an einer Aufgabe oder einem anderen Backlog-Element bis zu deren Abschluss. Ermöglicht die Verfolgung und Steuerung von Zykluszeiten und liefert so vorhersehbarere Ergebnisse.
5. Durchsatz und gelieferter Wert.
Projektmanager analysieren die den Entwicklern zugewiesenen Aufgaben und weisen ihnen einen Wert zu. Diese Kennzahl wird dann verwendet, um den Durchsatz des Teams oder mit anderen Worten die Menge der geleisteten Mehrwertarbeit zu messen.
6. Code-Änderung.
Die Code-Abwanderung ist eine weitere erwähnenswerte Kennzahl, da sie sowohl zur Messung der Produktivität eines Teams als Ganzes als auch zur Verfolgung der Leistung einzelner Programmierer verwendet wird. Die Codeabwanderung misst, wie oft ein Entwickler zuvor hinzugefügte Codezeilen entfernt oder Änderungen daran vornimmt und wie viel Prozent des zuvor geschriebenen Codes letztendlich geändert oder weggeworfen werden.
Expertenmeinungen
Zum Abschluss noch ein paar Zitate von erfahrenen Fachleuten aus der Softwareentwicklungsbranche zu diesem Thema, um etwas Perspektive hinzuzufügen. „Ich hoffe sehr, dass Sie Ihre Kennzahlen nicht mit einer Art Standard oder sogar mit der Leistung eines anderen Teams in einem anderen Unternehmen „vergleichen“ möchten. Überall, wo ich gearbeitet habe, gab es einzigartige Unterschiede in den Definitionen von Story Points, Geschwindigkeit, Stundenschätzungen, Aufgaben usw., die es wirklich nahezu unmöglich machten, die Leistung eines Teams eines Unternehmens direkt mit der eines anderen Teams eines anderen zu vergleichen Unternehmen“, bemerkte Cliff Gilley, ehemaliger technischer Produktmanager und Agile Coach. „Ich bin ein wenig misstrauisch gegenüber Kennzahlen, wenn es darum geht, die Teamleistung zu steuern. Sobald Sie nur auf eine oder zwei Variablen achten, kann es sehr leicht passieren, dass Sie (absichtlich oder unabsichtlich) die Kennzahl austricksen und sich selbst vorgaukeln, dass Sie sich verbessern – wenn Sie doch nur die Kennzahl verbessern. Beispielsweise können auf der Geschwindigkeit basierende Metriken „verbessert“ werden, indem das Team zu kleineren Storys übergeht (weniger Arbeit pro Story – also mehr Storys abgeschlossen – also höhere Geschwindigkeit). Das könnte eine gute Sache sein, wenn es sich bei den Storys um nützliche User Stories handelt, die kleinere Steigerungen des Geschäftswerts liefern. Das könnte eine schlechte Sache sein, wenn die Geschichten kleiner werden und „technischere“ Aufgaben werden, die für sich genommen keinen wirklichen Wert liefern“, sagte Adrian Howard, ein weiterer Branchenexperte. „Wenn ich in einem Pull-basierten System arbeite, lege ich Wert auf Durchsatz und Zykluszeit. Die erste gibt mir allgemeine Informationen über die Kapazität unseres Teams und kann im Laufe der Zeit zu einem sehr aussagekräftigen Vorhersagemaß werden. Der zweite Wert dient als allgemeiner Maßstab für die Effizienz unserer Pipelines. Wenn die Zykluszeit hoch ist, ist es an der Zeit, einen Blick auf die Pipeline zu werfen, denn es gibt eine Einschränkung, die wir wahrscheinlich entschärfen/ausnutzen können. Aber Metriken sind nur Werkzeuge. Verlieren Sie sich nicht darin und beginnen Sie auf keinen Fall mit der Planung auf eine bestimmte Kennzahl hin. Überlegen Sie, was Sie als Team leisten und wie Sie von Natur aus arbeiten, und bauen Sie dann das System rund um die Menschen auf. Anhand der Kennzahlen können Sie erkennen, wie Ihr System die Arbeit aller Mitarbeiter unterstützt. Oder auch nicht“, schlussfolgerte Dave Cerra, ein Entwickler von Videospielen .
