Als Teil eines größeren Unternehmens müssen Softwareentwicklungs-Teams in der Lage sein, ihre Arbeit zu planen. Außerdem müssen sie häufig Budgetanträge begründen und Leistungsindikatoren (Key Performance Indicators, KPIs) vorlegen. KPIs ermöglichen es auch abteilungsfremden Personen zu verstehen, wie zum Erfolg des Unternehmens beigetragen wird. Die Diskussion rund um Leistungsindikatoren hat zu zahlreichen und viel diskutierten Bemühungen geführt, verschiedene Aspekte des Softwareentwicklungsprozesses zu messen.
In diesem Artikel konzentriere ich mich auf eine der weniger umstrittenen Metriken: Developer Velocity (Entwicklergeschwindigkeit). Ich erkläre, was das bedeutet, wie Developer Velocity üblicherweise gemessen wird und wofür diese Metrik sinnvoll verwendet werden kann.
Was ist Developer Velocity?
Developer Velocity ist eine Kennzahl. Sie versucht darzustellen, wie viel Arbeit Entwickler_innen innerhalb einer bestimmten Zeit erledigen. “Versucht”, weil die Messung nicht so einfach ist.
Die Herausforderungen bei der Messung der Developer Velocity
Die Messung ist vor allem schwierig, weil Softwareentwicklung eine komplexe Aktivität ist. Es geht in dieser Arbeit oft um schwierige Probleme, deren Lösung Einfallsreichtum und Kreativität erfordert. Wenn Entwickler_innen mit der Arbeit an einer Aufgabe beginnen, ist oft nicht klar, wie diese Aufgabe abgeschlossen werden kann. Daher ist es schwierig, die Zeit abzuschätzen, die für eine bestimmte Aufgabe benötigt wird.
Es gibt aber bewährte und in der Branche verwendete Methoden zur Messung der Geschwindigkeit. Diese Messungen umgehen das Problem der Schätzung einzelner Aufgaben oder die Messung der Produktivität einzelner Entwickler_innen, indem sie Schätzungen über Personen und Aufgaben hinweg zusammenfassen.
Wie man Developer Velocity misst
Die gängigste Methode zur Messung der Developer Velocity sind Story-Points. Story-Points sind eine Metrik, die absichtlich auf die Angabe von ganz spezifischen Zeitangaben verzichtet. Stattdessen sollen Story-Points die relative Schwierigkeit einer Aufgabe im Vergleich zu anderen Aufgaben erfassen.
Story-Points werden am häufigsten im Rahmen von Scrum oder Scrum-ähnlichen Methoden zur Organisation der Entwicklungsarbeit verwendet. Softwareentwicklung erfolgt dabei in Sprints. Die Sprints haben eine feste Länge, in der Regel 1-4 Wochen.
In jedem Sprint arbeiten Entwickler_innen an ihren Aufgaben. Für jede Aufgabe werden Story-Points geschätzt. Entwickler_innen schätzen die Story-Points gemeinsam als Team. Jedes Teammitglied kann eine Zahl für eine Aufgabe vorschlagen. Die Zahl wird im Team diskutiert, bis ein Konsens erreicht ist. Das dient dazu, ein gemeinsames Verständnis für die Komplexität einer Aufgabe zu bekommen, die bei der Zuweisung von Story Points diskutiert wird.
Es kann aber nicht jede beliebige Anzahl von Story Points einer Aufgabe zugewiesen werden. Stattdessen werden nur Zahlen gewählt, die in der Fibonacci-Reihe vorkommen: 0, 1, 2, 3, 5, 8, 13, 21, 34, … Dies geschieht aus zwei Gründen:
(a) um unrealistische Illusionen über die Genauigkeit zu vermeiden und
(b) um die zunehmende Ungenauigkeit der Schätzung bei komplexeren Aufgaben zu erfassen.
Generell ist es so, dass jede Aufgabe, die eine Schätzung von 13 oder mehr Story Points aufweist, als einzelne Aufgabe zu groß ist und in kleinere Teilaufgaben aufgeteilt werden sollte. Dies hängt, wie schon erwähnt, damit zusammen, dass große oder komplexe Aufgaben nur schwer zu schätzen sind. Die Aufteilung von Aufgaben in kleinere, greifbare Teilaufgaben verbessert die Qualität der Schätzungen.
Das bedeutet, dass die meisten Aufgaben in einem Sprint Story-Point-Schätzungen von 1, 2, 3, 5 oder 8 haben. Wenn das Team die Aufgaben miteinander vergleicht, entscheidet es
- welche Aufgaben komplexer sind und eine höhere Story-Point-Schätzung erhalten
- und welche einfacher sind und eine niedrigere Schätzung erhalten.
Eine andere gängige Methode ist die Verwendung von T-Shirt-Größen für Schätzungen, wobei Aufgaben einfach mit S, M oder L bezeichnet werden. Dies hat den großen Vorteil, dass man sich noch weniger auf Zeiteinheiten beziehen kann als auf Zahlen.
Die Geschwindigkeit wird dann für das gesamte Team und für ganze Sprints aggregiert. In einem zweiwöchigen Sprint kann ein Team zum Beispiel durchschnittlich 50-60 Story Points fertigstellen. Dies wird dann als Team-Velocity bezeichnet.
Bei Teams, die bereits seit einigen Sprints zusammenarbeiten, stabilisiert sich die Team-Velocity in der Regel über die Sprints hinweg. Im Gegensatz dazu schwankt die Geschwindigkeit einzelner Entwickler_innen in der Regel sehr viel stärker als die Gesamtgeschwindigkeit des Teams.
Die Messung der Teamgeschwindigkeit anhand von Story Points hat sich als Industriestandard etabliert und gilt als die zuverlässigste und am weitesten verbreitete Methode zur Messung der Entwicklergeschwindigkeit. Sie umgeht die vielen Herausforderungen der Geschwindigkeitsmessung, indem sie
- nicht die Zeit zur Fertigstellung einer Aufgabe, sondern die Aufgabenkomplexität geschätzt wird, die leichter zu erfassen ist,
- nicht die absolute Komplexität, sondern die Komplexität von Aufgaben im Verhältnis zueinander schätzt,
- nicht die Geschwindigkeit einzelner Entwickler_innen, sondern die Geschwindigkeit des Teams messen,
- nicht die Messung einzelner Aufgaben, sondern die Aggregation von Messungen über einen ganzen Sprint.
Ein Großteil der Ungenauigkeit der Schätzung gleicht sich über die Entwickler_innen und Aufgaben hinweg aus, was zu einer recht stabilen Metrik führt.
Warum sollte die Developer Velocity gemessen werden?
Die Team-Velocity wird in der Regel für die Planung verwendet, d. h. um zu wissen, wie viele Aufgaben ein Team innerhalb eines Sprints voraussichtlich erledigen kann. Dafür wird die Prognose von Story Points vorgenommen.
Die Team-Velocity ist auch eine Metrik, die man im Laufe der Zeit im Auge behalten sollte. Eine Verlangsamung kann auf Probleme im Entwicklungsprozess hinweisen, während ein Anstieg darauf hindeuten kann, dass Hindernisse beseitigt wurden. Allerdings werden Änderungen in der Teamgeschwindigkeit meist erst nach mehreren Sprints deutlich und können von vielen Faktoren beeinflusst werden.
Eine Sache, die Team-Velocity nicht leisten kann: Führungskräfte über die Effektivität ihres Entwicklungsteams zu informieren. Die Team-Velocity ist keine standardisierte Kennzahl. Es ist nicht möglich, Teams miteinander zu vergleichen, da jedes Team andere Schätzungen vornimmt. Es ist auch nicht möglich, einzelne Entwickler_innen miteinander zu vergleichen oder eine Renditeberechnung für ein Entwicklungsteam oder eine Abteilung vorzunehmen.
Developer Velocitvy ermöglicht aber die Planung und gibt einen Eindruck davon, wie sich die Geschwindigkeit eines Entwicklungsteams im Laufe der Zeit entwickelt.
Wenn Sie mehr über das „Big Picture“ hinsichtlich der Steigerung von Produktivität und Zufriedenheit im Entwicklungsteam erfahren möchten, lesen Sie unseren Artikel über Developer Experience.
Fallstricke
Es gibt zwei häufige Fallstricke, die ähnlich wie bei vielen anderen Metriken auch bei der Developer Velocity auftreten: Erstens wird Developer Velocity oft fälschlicherweise für eine absolute Kennzahl der Entwicklerproduktivität oder Teameffektivität gehalten, und zweitens bietet die Messung der Developer Velocity einen Anreiz zur Maximierung dieser Kennzahl, was zu unerwarteten Nebeneffekten führen kann.
Developer Velocity ist keine standardisierte Kennzahl und eignet sich nicht als KPI
Selbst wenn dieselbe Methode zur Messung der Geschwindigkeit verwendet wird, werden zwei Teams unterschiedliche Schätzungen vornehmen, was zu unterschiedlichen Geschwindigkeiten führt. Die Team-Velocity ist daher nicht geeignet, um Teams miteinander zu vergleichen, da es sich nicht um eine standardisierte Kennzahl handelt. Die Velocity eines Teams ist eine Zahl, die an sich nicht viel Information enthält. Sie ist nur wertvoll, wenn sie über einen längeren Zeitraum hinweg betrachtet wird und als Werkzeug dient, um festzustellen, wie viele Aufgaben innerhalb eines Sprints erledigt werden können.
Als solche ist sie auch nicht als KPI geeignet, da sie nichts über die Qualität der geleisteten Arbeit, die Effizienz der Ressourcennutzung oder die Übereinstimmung der geleisteten Arbeit mit den Unternehmenszielen aussagt.
Wie jede Metrik kann auch die Developer Velocity manipuliert werden
Die Festlegung der Geschwindigkeit als KPI kann den unerwünschten Effekt haben, dass Entwickler_innen versuchen, diese zu maximieren. Und zwar in einer Art und Weise, die eigentlich keine echte Geschwindigkeitssteigerung widerspiegelt. So beginnen Teams beispielsweise, ihre Schätzungen zu erhöhen und weisen einzelnen Aufgaben einfach mehr Story-Points zu, wenn sie für die Fertigstellung vieler Story-Points belohnt werden.
Wie bei allen Metriken, die sich nur auf einen Aspekt der Arbeit konzentrieren, kann dies dazu führen, dass Entwickler_innen Tickets so schnell wie möglich abschließen und Kompromisse bei der Codequalität, den Tests und der Dokumentation eingehen.
Bei der Verwendung von Fibonacci-Zahlen für Story-Point-Schätzungen, ist es außerdem häufig der Fall, dass fünf 1-Story-Point-Tickets schneller abgeschlossen werden können als ein 5-Story-Points-Ticket. Anreize für Schnelligkeit können dann dazu führen, dass Entwickler_innen lieber an kleinen Aufgaben arbeiten.
Solche Verzerrungen lassen sich am besten dadurch vermeiden, dass die Developer Velocity nicht als KPI verwendet wird, wofür sie ohnehin schlecht geeignet ist, sondern als Werkzeug für das Team selbst, um einen Sprint zu planen.
In diesem Whitepaper erfahren Sie, wie Sie mit RDEs die Produktivität Ihres Teams und die Qualität der Softwareentwicklung in Ihrem Unternehmen verbessern.
Download nowFazit
Die Developer Velocity ist eine Kennzahl. Sie zeigt, wie viel ein Softwareentwicklungsteam in einer bestimmten Zeitspanne erreichen kann.
Die Messung der Entwickler_innen-Gschwindigkeit ist schwierig, weil Softwareentwicklung eine komplexe Tätigkeit ist: Der Umfang von Softwareentwicklungsaufgaben wird oft erst während der Arbeit an ihnen deutlich.
Dennoch gibt es eine gängige Methode zur Messung der Geschwindigkeit: Man misst die Story Points, die in einem Sprint für ein ganzes Team abgeschlossen werden und erhält so eine Metrik für die Team-Velocity. Diese Methode umgeht die inhärenten Herausforderungen bei der Messung der Entwickler_innen-Velocity, indem sie kleine individuelle Aufgaben schätzt, die Schätzung im Team durchführt und die Velocity über Personen und Aufgaben hinweg aggregiert.
Die Team-Velocity ist nützlich für die Planung des Umfangs eines Sprints und kann als Indikator für Probleme oder Verbesserungen bei Entwicklungswerkzeugen und -prozessen verwendet werden, wenn sie über einen längeren Zeitraum beobachtet wird. Sie ist jedoch nicht als KPI geeignet, da die Team-Velocity keine standardisierte Kennzahl ist und nichts über die Qualität oder Effektivität eines Teams aussagt.
Jetzt den Cloudomation-Newsletter abonnieren
Werden Sie Cloudomation-Insider. Immer am Ende des Monats neue News zum Thema „Remote Development Environments“ und „DevOps“ erhalten.
