Programmierer-Produktivität – messbar oder doch nicht?
Kommentare

Höher, schneller, weiter, besser. In der Geschäftswelt herrscht Erfolgsdruck, jeder muss Leistung erbringen und sich mit anderen vergleichen lassen. Das gilt auch für Programmierer. Doch wie misst man die Produktivität eines Entwicklerteams?

Ideen dazu gibt es viele, die meisten erweisen sich in der Praxis jedoch als wenig hilfreich, stellt Jim Bird fest. So ist am Ende ja nicht zwingend derjenige produktiver, der mehr Code geschrieben hat – eine elegantere Lösung für das gleiche Problem kann mit viel weniger Zeilen Code auskommen.

Das Produktivitäts-Dilemma

Das einfache Beispiel der Codezeilen zeigt bereits das Dilemma hinter der Frage nach der Produktivität von Programmierern. Gerade bei komplexen Problemen kommt es oft auf mehr an, als nur auf ein schnelles Ergebnis oder eine hohe Zeilenzahl. Auch der finanzielle Erfolg eines Projekts ist zu sehr von äußeren Faktoren abhängig, um als Maßstab für die Bewertung eines Teams zu gelten.

Insofern ergibt sich die nächste Frage fast von selbst: Wie sinnvoll ist es überhaupt, die Produktivität von Programmierern messen zu wollen? Innerhalb eines Teams ist offensichtlich, welcher Kollege besser ist, ganz ohne objektiven Maßstab. Teamübergreifend wird es allerdings umso schwieriger, überhaupt eine Basis für einen Vergleich zu finden – dazu sind die Projekte und Ziele einfach zu verschieden.

Optimierung statt Vergleich

Sinnvoller ist es, nicht nur eine Wertung abgeben zu wollen, sondern nach Problemen im Arbeitsfluss zu suchen und diese zu lösen. Das erhöht die Leistung innerhalb eines Teams. Durch die Messung der Arbeitsgeschwindigkeit, in der agilen Softwareentwicklung Velocity genannt, kann anhand eines einmal bestimmten Wertes erkannt werden, ob ein Projekt wie geplant voran schreitet. Sollte das nicht der Fall sein, kann eingegriffen werden.

Ähnliches gelingt mit Hilfe der Betrachtung der Cycle Time, also der Zeit, die zwischen Auftrag und Ergebnis vergeht. Mit Hilfe von Kanban-Methoden können hierbei Abläufe optimiert werden, was am Ende viel Zeit spart. Vorsicht ist allerdings geboten, wenn der Fokus zu sehr auf die reine Arbeitszeit gelegt wird um daran die Produktivität eines Teams festzumachen. Das geht nämlich häufig zu Lasten der Qualität.

Wenn Quantität die Qualität verdrängt

Wenn die Qualität nicht stimmt, kann nicht mehr von einer hohen Produktivität gesprochen werden. Denn ein Ergebnis, das zwar schnell vorliegt, dafür aber umso mehr Bugs enthält, stellt keinen Kunden zufrieden. Ebenso wird der Kunde allerdings nicht glücklich, wenn das Produkt zwar qualitativ gut ist, aber erst viel zu spät fertig wird.

Diese beiden Aspekte lassen sich am Besten mithilfe von DevOps-Maßnahmen vereinen. Hier eröffnet sich die Möglichkeit, sowohl Abläufe zu optimieren, als auch die Fehlerquote in die Wertung mit einfließen zu lassen. Das klingt erst einmal sehr vielversprechend. In einem nach den DevOps-Grundsätzen arbeitenden Team wird allerdings schnell mehr Zeit auf die operativen Vorgänge verwendet als auf die eigentliche Programmierung. Obwohl sich hier also interessante Bewertungsmöglichkeiten eröffnen, ist dieser Ansatz nicht für jedes Team geeignet.

Am Ende gibt es also keinen absolut objektiven Bewertungsmaßstab für die Produktivität von Programmierern. Es kommt immer auf die Umstände und Fragestellung an, ob ein Ansatz dazu geeignet ist, eine Wertung abzugeben – und ob die dann aussagekräftig ist. Auch, wenn es sich viele Chefs vielleicht anders wünschen würden: Am Besten lassen sich Entwicklerteams immer noch daran bewerten, ob sie ihre Ziele erreichen. Ist das der Fall, ist es vielleicht gar nicht mehr so wichtig, ob sie besser oder schlechter darin sind als die Konkurrenz.

Aufmacherbild: Measuring productivity via Shutterstock.com / Urheberrecht: Pixelbliss

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -