Wenn Sie zu Google gehen und suchen “Messung der Produktivität von Softwareentwicklern” Sie werden eine ganze Menge nichts finden. Ernsthaft — nichts.
Nick Hodges, Messen der Entwicklerproduktivität

Das sollten wir mittlerweile alle wissen Wir wissen nicht, wie man die Produktivität von Programmierern misst.

Es gibt kein klarer Weg zu messen welche Programmierer machen einen besseren oder schnelleren Job, oder um die Produktivität zwischen Teams zu vergleichen. Wir „wissen“, wer die Stars in einem Team sind, auf wen wir uns verlassen können, und wer hat zu kämpfen. Und wir wissen, ob ein Team in den Arsch tritt – oder seinen Hintern zieht. Aber wie beweisen wir es? Wie können wir es quantifizieren??

Alle möglichen dummen und bösen Dinge können passieren, wenn du Versuchen Sie, die Produktivität der Programmierer zu messen.

Aber machen wir es trotzdem.

Wir schreiben mehr Code, also müssen wir produktiver sein

Entwickler werden dafür bezahlt, Code zu schreiben. Warum also nicht messen, wie viel Code sie schreiben – wie viele Codezeilen geliefert bekommen?

Denn wir haben seit den 1980er Jahren bekannt dass dies eine lausige Methode ist, um die Produktivität zu messen.

Codezeilen können nicht über Sprachen hinweg verglichen werden (selbstverständlich), oder sogar zwischen Programmierern, die dieselbe Sprache verwenden, die in verschiedenen Frameworks arbeiten oder verschiedenen Stilen folgen. Weswegen Funktionspunkte erfunden wurden – ein Versuch, den Umfang der Arbeit in verschiedenen Umgebungen zu standardisieren und zu vergleichen. Hört sich gut an, aber Funktionspunkte habe es nicht geschafft in den Mainstream, und wahrscheinlich nie – sehr wenige Leute wissen, wie Funktionspunkte funktionieren, wie man sie berechnet und wie sie verwendet werden sollten.

Das grundlegendere Problem besteht darin, dass die Messung der Produktivität anhand von Linien (oder Funktionspunkte oder andere Ableitungen) getippt macht keinen sinn. Viel wichtige Arbeit in der Softwareentwicklung, die wichtigste arbeit, beinhaltet Denken und Lernen – nicht tippen.

Die besten Programmierer verbringen viel Zeit damit, schwierige Probleme zu verstehen und zu lösen, oder anderen Menschen helfen, schwierige Probleme zu verstehen und zu lösen, statt tippen. Sie finden Wege, Code zu vereinfachen und Duplikate zu vermeiden. Und ein Großteil des Codes, den sie schreiben, zählt sowieso nicht, während sie durch Experimente iterieren und Prototypen bauen und alles wegwerfen, um zu einer optimalen Lösung zu gelangen.

Die Mängel dieser Maßnahmen sind offensichtlich, wenn wir die idealen Ergebnisse betrachten: möglichst wenige Codezeilen, um ein Problem zu lösen, und die Erstellung vereinfachter, gemeinsame Prozesse und Kundeninteraktionen, die die Komplexität in IT-Systemen reduzieren. Unsere produktivsten Leute sind diejenigen, die geniale Wege finden, um überhaupt keinen Code schreiben zu müssen.
Jez bescheiden, Das schlanke Unternehmen

Dies ist eindeutig einer der Fälle, in denen die Größe keine Rolle spielt.

Wir machen (oder sparen) mehr Geld,
also müssen wir besser arbeiten

Wir könnten versuchen, die Produktivität auf einem hohen Niveau zu messen, indem wir die Rentabilität oder die finanzielle Rendite der Leistung jedes Teams verwenden, oder eine andere geschäftliche Kennzahl, z. B. wie viele Kunden das System verwenden – wenn Entwickler mehr Geld für das Unternehmen verdienen (oder mehr Geld sparen), sie müssen etwas richtig machen.

Der Einsatz finanzieller Maßnahmen scheint auf der Führungsebene eine gute Idee zu sein, vor allem jetzt, wo“Jedes Unternehmen ist ein Softwareunternehmen”. Dies sind organisatorische Maßnahmen, an denen Entwickler teilhaben sollten. Aber sie sind keine wirksamen – oder fairen – Messgrößen für die Entwicklerproduktivität. Es gibt zu viele Geschäftsfaktoren, die außerhalb der Kontrolle des Entwicklungsteams liegen. Manche Produkte oder Dienstleistungen sind erfolgreich, auch wenn die Leute, die sie liefern, einen lausigen Job machen, oder scheitern, auch wenn das Team einen tollen Job gemacht hat. Insbesondere die Konzentration auf Kosteneinsparungen führt dazu, dass viele Manager Personal abbauen und versuchen, „mit weniger mehr zu erreichen“, anstatt in echte Produktivitätsverbesserungen zu investieren.

Und als Martin Fowler weist darauf hin es gibt eine zeitverzögerung, insbesondere in großen Organisationen – es kann manchmal Monate oder Jahre dauern, bis echte finanzielle Ergebnisse aus einem IT-Projekt erzielt werden, oder aus Produktivitätsverbesserungen.

Wir müssen woanders suchen, um aussagekräftige Produktivitätskennzahlen zu finden.

Wir sind schneller, also müssen wir produktiver werden

Entwicklungsgeschwindigkeit messen – Geschwindigkeit in Agile – sieht aus wie eine andere Möglichkeit, die Produktivität auf Teamebene zu messen. Letztendlich, Der Sinn der Softwareentwicklung besteht darin, funktionierende Software zu liefern. Je schneller ein Team liefert, desto besser.

Aber Geschwindigkeit (wie viel arbeit, gemessen in Story Points oder Feature Points oder idealen Tagen, die das Team in einer bestimmten Zeit liefert) ist wirklich ein Maß für Vorhersagbarkeit, nicht Produktivität. Velocity soll von einem Team verwendet werden, um zu messen, wie viel Arbeit es übernehmen kann, um ihre Schätzungen zu kalibrieren und ihre Arbeit vorauszuplanen.

Sobald sich die Geschwindigkeit eines Teams stabilisiert hat, du kannst Geschwindigkeitsänderungen messen innerhalb des Teams als relatives Maß für die Produktivität. Wenn sich die Geschwindigkeit des Teams verlangsamt, es könnte ein Indikator für Probleme im Team, im Projekt oder im System sein. Oder Sie können die Geschwindigkeit verwenden, um die Auswirkungen von Prozessverbesserungen zu messen, um zu sehen, ob Schulungen oder neue Tools oder neue Praktiken die Arbeit des Teams tatsächlich messbar beschleunigen.

Aber du wirst es müssen Veränderungen im Team berücksichtigen, wenn Leute beitreten oder gehen. Und Sie müssen bedenken, dass Geschwindigkeit ein Maß ist, das nur innerhalb eines Teams Sinn macht – das Sie können die Geschwindigkeit zwischen Teams nicht vergleichen.

Obwohl dies die Leute nicht davon abhält, es zu versuchen. Einige Shops verwenden die Idee einer bekannten Referenzgeschichte, die alle Teams in einem Programm verstehen und auf der sie ihre Schätzungen der Story-Punkte basieren. Solange Teams nicht viel Freiheit bei der Erstellung von Schätzungen haben, und solange die Teams an demselben Projekt oder Programm mit denselben Einschränkungen und Annahmen arbeiten, Sie können möglicherweise einen groben Vergleich der Geschwindigkeit zwischen den Teams durchführen. Aber Mike Cohn warnt davor

Wenn Teams den geringsten Hinweis darauf verspüren, dass die Geschwindigkeiten zwischen den Teams verglichen werden, wird es eine allmähliche, aber konsistente „Punkteinflation“ geben.

ThoughtWorks erklärt das Geschwindigkeit <> Produktivität in ihrem neuesten Technologieradar:

Wir sehen weiterhin, dass Teams und Organisationen Geschwindigkeit mit Produktivität gleichsetzen. Bei richtiger Anwendung, Velocity ermöglicht die Einbindung des „Wetters von gestern“ in den internen Iterationsplanungsprozess eines Teams. Der Schlüssel hier ist, dass Geschwindigkeit ein internes Maß für ein Team ist, es ist nur eine Kapazitätsschätzung für dieses bestimmte Team zu einem bestimmten Zeitpunkt. Organisationen und Manager, die interne Geschwindigkeit mit externer Produktivität gleichsetzen, beginnen, Geschwindigkeitsziele festzulegen, vergessen, dass die funktionierende Software in der Produktion wirklich zählt. Geschwindigkeit als Produktivität zu behandeln, führt zu unproduktivem Teamverhalten, das diese Kennzahl auf Kosten der tatsächlich funktionierenden Software optimiert.

Bleib einfach beschäftigt

Ein Manager, den ich kenne, sagt das, anstatt zu versuchen, die Produktivität zu messen

„Wir bleiben einfach beschäftigt. Wenn wir damit beschäftigt sind, wie Verrückte zu arbeiten, Wir können nach Problemen und Engpässen Ausschau halten und sie beheben und weitermachen.“.

In diesem Fall würden Sie messen – und optimieren für – Zykluszeit, wie in der Lean Manufacturing.

Zykluszeit – Durchlaufzeit oder Änderungsvorlaufzeit, Von dem Zeitpunkt an, an dem das Unternehmen um etwas bittet, bis es es in die Hände bekommt und sieht, dass es funktioniert – ist etwas, das dem Unternehmen wichtig ist, und etwas das jeder kann sehen und messen. Und wenn du anfängst genau hinzusehen, Verschwendung und Verzögerungen werden angezeigt, wenn Sie die Wartezeit/Leerlaufzeit messen, Mehrwert vs. nicht wertschöpfende Arbeit, und Prozesszykluseffizienz (Gesamtwertschöpfungszeit / Gesamtzykluszeit).

„Es ist nicht wichtig, Produktivität zu definieren, oder um es zu messen. Viel wichtiger ist es, unproduktive Aktivitäten zu identifizieren und auf null zu reduzieren.“
Erik Simmons, Intel

Teams können verwenden Kanban Überwachung – und Begrenzung – laufender Arbeiten und Identifizierung von Verzögerungen und Engpässen. Und Wertstromanalyse um die Schritte zu verstehen, Warteschlangen, Verzögerungen und Informationsflüsse, die optimiert werden müssen. Effektiv sein, Sie müssen den End-to-End-Prozess von der ersten Anfrage bis zur Auslieferung und Ausführung betrachten, und optimieren den ganzen Weg, nicht nur die Arbeit in der Entwicklung. Dies kann bedeuten, dass die Prioritäten des Unternehmens geändert werden, wie Entscheidungen getroffen werden und wer die Entscheidungen trifft.

In fast allen Fällen, die wir gesehen haben, Die Effizienzsteigerung eines Prozessblocks hat nur minimale Auswirkungen auf den gesamten Wertstrom. Da Nacharbeit und Wartezeiten zu den größten Anteilen an der Gesamtlieferzeit beitragen, Einführung „agiler“ Prozesse innerhalb einer einzigen Funktion (wie Entwicklung) hat im Allgemeinen wenig Einfluss auf den gesamten Wertstrom, und damit auf Kundenergebnisse.
Jezz bescheiden, Das schlanke Unternehmen

Die Kehrseite der Gleichsetzung von Liefergeschwindigkeit mit Produktivität? Die Optimierung der Taktzeit/Liefergeschwindigkeit allein kann auf Dauer zu Problemen führen, denn das regt die Leute dazu an, kurzfristig zu denken, und um Abstriche zu machen und technische Schulden aufzunehmen.

Wir schreiben bessere Software, also müssen wir produktiver sein

„Das Paradoxe ist, dass wenn Manager sich auf die Produktivität konzentrieren, langfristige Verbesserungen werden selten gemacht. Auf der anderen Seite, wenn Führungskräfte auf Qualität setzen, die Produktivität verbessert sich kontinuierlich.“
John Seddon, quotiert in Das schlanke Unternehmen

Wir wissen das Fehler später beheben kostet mehr. Ob es 10x oder 100+x, es ist egal. Und das Projekte mit weniger Fehlern werden schneller geliefert – zumindest bis zu sinkenden Renditen für sicherheits- und lebenskritische Systeme.

Und wir wissen, dass die Kosten von Bugs und Fehlern in der Software für das Unternehmen erheblich sein können. Nicht nur Entwicklungs-Nacharbeitskosten und Wartungs- und Supportkosten. Aber direkte Kosten für das Unternehmen. Ausfallzeit. Sicherheitsverstoss. Verlorene IP. Verlorene Kunden. Geldbußen. Klagen. Geschäftsversagen.

Es ist einfach zu messen dass Sie gute – oder schlechte – Software schreiben. Fehlerdichte. Fehler-Fluchtraten (insbesondere Mängel – einschließlich Sicherheitslücken – die in die Produktion gelangen). Statische Analysemetriken auf der Codebasis, mit Tools wie SonarQube.

Und wir wissen, wie man gute Software schreibt – oder wir sollten es inzwischen wissen. Aber reicht die Softwarequalität aus, um Produktivität zu definieren??

Devops – Messen und Verbessern der IT-Leistung

Devops-Teams, die Systeme aufbauen/warten und betreiben/supporten, erweitern die Produktivität von der Entwicklung in den Betrieb. Sie messen die Produktivität in zwei Dimensionen, die wir bereits betrachtet haben: Liefergeschwindigkeit, und Qualität.

Aber Devops beschränkt sich nicht nur auf das Erstellen und Bereitstellen von Code – stattdessen betrachtet es Leistungskennzahlen für die End-to-End-IT-Servicebereitstellung:

1. Lieferdurchsatz: Bereitstellungsfrequenz und Vorlaufzeit, Maximierung des Arbeitsflusses in die Produktion
2. Servicequalität: Fehlerrate ändern und MTTR

Es geht nicht nur darum, Software schneller oder besser zu liefern. Dev und Ops arbeiten zusammen, um Services besser und schneller bereitzustellen, ein Gleichgewicht zwischen zu schnellen Bewegungen oder dem Versuch, zu viel auf einmal zu tun, finden, und übermäßige Bürokratie und übermäßige Vorsicht, die zu Verschwendung und Verzögerungen führen. Entwickler und Operations müssen Verantwortung und Rechenschaftspflicht für das Ergebnis teilen, und zur Messung und Verbesserung von Produktivität und Qualität.

Wie ich in erwähnt habe ein früherer Beitrag das macht Betriebskennzahlen wichtiger als Entwicklermetriken. Entsprechend aktuelle Studien, Erfolg bei der Erreichung dieser Ziele führt zu einer Verbesserung des Geschäftserfolgs: nicht nur Produktivität, aber Marktanteil und Profitabilität.

Ergebnisse messen, nicht Ausgabe

Im Das schlanke Unternehmen (was man merkt, dass ich gerade zu Ende gelesen habe), Jez Jumble spricht darüber, wie wichtig es ist, die Produktivität anhand des Ergebnisses zu messen – das Messen von Dingen, die für das Unternehmen von Bedeutung sind – nicht der Leistung.

„Es spielt keine Rolle, wie viele Geschichten wir abschließen, wenn wir nicht die Geschäftsergebnisse erreichen, die wir uns in Form von Zielbedingungen auf Programmebene vorgenommen haben.“.

Hör auf zu versuchen zu messen individuelle Entwicklerproduktivität. Es ist Zeitverschwendung.

• Jeder kennt die Top-Performer. Richte sie in die richtige Richtung, und mach sie glücklich.
• Jeder kennt die Menschen, die es schwer haben. Holen Sie sich die Hilfe, die sie brauchen, um erfolgreich zu sein.
• Jeder weiß, wer nicht reinpasst. Verschiebe sie raus.

Messung und Verbesserung der Produktivität im Team oder (besser) Organisationsebene wird Ihnen viel sinnvollere Erträge bringen.

Wenn es um Produktivität geht:

1. Messen Dinge die wichtig sind – Dinge, die für das Team oder die Organisation einen Unterschied machen. Maßnahmen, die klar sind, wichtig, und das ist nicht einfach zu spielen.
2. Verwenden Sie Metriken für das Gute, nicht zum Bösen – um Lernen und Verbesserung voranzutreiben, Ergebnisse zwischen Teams nicht zu vergleichen oder Personen einzustufen.

Ich kann verstehen, warum das Messen von Produktivität so verführerisch ist. Wenn wir das könnten, könnten wir Software viel einfacher und objektiver beurteilen als jetzt. Aber falsche Maßnahmen machen die Sache nur schlimmer.
Martin Fowler, Kann die Produktivität nicht messen

Über den Autor

Jim Bird ist ein erfahrener Softwareentwicklungsmanager, Projektleiter und derzeit CTO bei einem Finanzdienstleistungsunternehmen. Sein Fokus liegt auf harten Problemen in der Softwareentwicklung und -wartung, Softwarequalität und Sicherheit. Für das letzte 15 Jahre hat er Teams geleitet, die leistungsstarke Finanzsysteme aufbauen und betreiben. Sein besonderes Interesse gilt der Frage, wie kleine Teams am effektivsten echte Software bauen können: hohe Qualität, sichere Systeme an den äußersten Grenzen der Zuverlässigkeit, Performance, und Anpassungsfähigkeit. Software die funktionieren muss, das ist richtig gebaut, und für die Ewigkeit gebaut. Dieser Artikel wurde ursprünglich in seinem eigenen Blog veröffentlicht Reale Software erstellen.

Ein Blogbeitrag repräsentiert die persönliche Meinung des Autors
und muss nicht unbedingt mit den offiziellen Nesma-Richtlinien übereinstimmen.