it-swarm-eu.dev

Metrik, nach der Entwickler zur Rechenschaft gezogen werden sollen

Ich stellte eine Frage in Codezeilen pro Stunde und bekam eine neue zerrissen. Meine ausgereifte Folgefrage lautet also:

Wenn nicht Codezeilen, was ist dann eine gute Metrik, um die Effektivität von Remote-Programmierern (nach Stunde/Tag/Zeiteinheit) zu messen?

72
Kyle

In 16 Jahren habe ich nie eine brauchbare Metrik gefunden, nach der Sie suchen.

Um nützlich zu sein, müsste alles messbar, repräsentativ und nicht messbar sein (das heißt, das System kann nicht von cleveren Entwicklern gespielt werden). Es gibt einfach zu viele Variablen in der Softwareentwicklung, um sie auf diese Weise als Einzelstück messbar zu machen.

Der nächste Schritt ist der Fortschritt gegenüber Schätzungen - das heißt, wie viele Aufgaben werden innerhalb der vereinbarten Schätzungen ausgeführt. Der Trick dabei ist (a) gute und faire Schätzungen zu erhalten und (b) zu verstehen, wo Schätzungen aus guten Gründen überschritten wurden, für die der Entwickler nicht verantwortlich gemacht werden kann/sollte (das war wirklich komplexer als erwartet). Wenn Sie die Entwickler zu stark pushen, werden Sie wahrscheinlich feststellen, dass Schätzungen allmählich auf ein Niveau ansteigen, bei dem sie immer erfüllt werden, nicht aufgrund der gesteigerten Produktivität, sondern aufgrund gepolsterter Zeitskalen.

Gehen Sie in Bezug auf die Schätzungen zu viel in die andere Richtung (reduzieren Sie sie, um Druck zu erzeugen), und Sie erstellen falsche Fristen, von denen Studien gezeigt haben, dass sie die Produktivität nicht steigern und wahrscheinlich die Teammoral beeinflussen (weitere Informationen finden Sie unter Peopleware ).

Aber im Wesentlichen frage ich mich, ob Sie ein etwas falsches Problem betrachten. Warum unterscheiden sich Remote-Programmierer von anderen Programmierern, wenn es um die Messung der Produktivität geht? Wie messen Sie die Produktivität von Nicht-Remote-Programmierern?

Wenn es darum geht, ihnen nicht zu vertrauen, dass sie remote arbeiten, ist dies im Grunde ein größeres Vertrauensproblem. Wenn Sie nicht darauf vertrauen, dass sie von zu Hause aus arbeiten, müssen Sie entweder dieses Vertrauen aufbauen, sie nicht von zu Hause aus arbeiten lassen oder sich davon überzeugen, dass sie tatsächlich arbeiten, wenn sie es sollen.

101
Jon Hopkins

Metriken funktionieren am besten in Fabriken, und Programmierer arbeiten nicht am Fließband.

Ich verstehe den Wunsch, die Produktivität zu messen, vollkommen.

Aber würden Sie dieselbe Metrik für einen Hausarzt und einen Herzchirurgen verwenden? Wie wäre es mit Michelangelo, der die Sixtinische Kapelle malt, und einem Mann in Mexiko, der Elvis-Gemälde aus schwarzem Samt herauskurbelt?

Louis de Broglie schrieb eine Doktorarbeit, die so kurz war, dass die Prüfer sie ablehnen würden - außer dass de Broglie ein hochrangiger Aristokrat war und sie eine gute Entschuldigung brauchten. Also schickten die Prüfer es an Einstein, der es nicht nur nicht ablehnte, sondern an das Nobelkomitee verwies, und de Broglie erhielt dafür fünf Jahre später den Nobelpreis für Physik.

Numerische Maßnahmen eignen sich am besten für sich wiederholende Arbeiten wie Gusseisen oder Schrauben an Autotüren. Wenn Sie jedoch zuvor wiederholten Code wiederholen, benötigen Sie keinen Programmierer, sondern nur ein Kopieren und Einfügen. Das Programmieren ist im Grunde eine kreative Disziplin, und die Produktivität hängt ganz davon ab, was Sie tun.

An manchen Tagen starte ich 1000 Codezeilen. Heute werde ich Fehler in der Koordinatengeometrie beheben, und der Code wird möglicherweise kleiner. Wenn ich einen Fehler in einem Linux-Kerneltreiber beheben müsste, würde ich möglicherweise den ganzen Tag mit dem Debuggen verbringen und keine neue Codezeile schreiben.

Die Messung der Programmiererproduktivität ist sehr, sehr, sehr subjektiv.

Wenn Sie wissen möchten, ob Joe produktiv ist, suchen Sie Sally und Ralph, die wissen, was Joe tut und sich in denselben Bereichen auskennt, und fragen Sie sie.

Das beste numerische System, das ich je gesehen habe, war Agiles Planung von Pokerpunkten. Das ist nur eine ausgefallene Art, Joe, Sally und Ralph zu fragen, wie schwer sie glauben, dass Joes bevorstehender Job wahrscheinlich sein wird. Anschließend können Sie die Produktivität pro Woche für jedes Teammitglied messen. Aber selbst dann dauert es eine Weile, bis die Schätzungen eines Teams kalibriert sind, und die Zahlen sind unscharf und können leicht verworfen werden.

Viele Menschen möchten Produktivitätsschätzungen, damit sie eine Zeitplanung durchführen können. Es ist eine Art Theorie "Stecken Sie es in MS Project ein, sehen Sie sich den kritischen Pfad an und es gibt Ihr Versanddatum". Ich habe diese Arbeit noch nie gesehen - es gibt einfach zu viele Unbekannte. Wenn Sie das möchten, verwenden Sie Waterfall, entwerfen Sie alles im Voraus, lassen Sie keine Änderungsaufträge zu und lassen Sie sich trotzdem enttäuschen.

48
Bob Murphy

Die einzige Metrik, die ich benutze, ist die Menge an funktionierender Software, die er für einen bestimmten Betrag an Geld produziert, den ich investiert habe.

Unabhängig vom Zeitplan, ob sie/er remote arbeitet oder nicht, Anzahl der Pausen, Methoden, Methoden/Anzahl der Arbeitsstunden.

Mit funktionierende Software meine ich:

Liste der vom Benutzer/Kunden definierten Funktionen, die das erforderliche Qualitätsniveau erfüllen

Von Geldbetrag:

Wie viel der Benutzer/Kunde für die definierten Funktionen + Wartungskosten bezahlt hat

Es hat also einen direkten Einfluss darauf, wie es aufgebaut ist und wie die Qualität der Arbeit produziert wird, ist jedoch nicht an Metriken für Quellcodezeilen gebunden.

42
user2567

Sie benötigen einen erfahrenen Entwickler oder Teamleiter (der nicht mit diesen Remote-Programmierern verbunden ist), um abzuschätzen, wie lange eine Aufgabe dauern kann, und die Effektivität wird gemessen, indem die erforderliche Zeit mit den Schätzungen verglichen wird. Um sicherzugehen, dass die Schätzungen gut sind, können Sie einige Aufgaben nach dem Zufallsprinzip auswählen und von einem internen Team ausführen lassen, das Sie unter Kontrolle haben.

23
user281377

Eine weitere interessante Methode zur Messung der Produktivität wäre die Zählung automatisierbarer Tests, die von einem Manager pro Tag überprüft werden. Der Entwickler erhält:

  • ein Punkt zum Schreiben eines automatisierbaren Tests (und zum Bestehen einer Überprüfung) und zum Hinzufügen zur Regressionstestsuite,
  • ein Punkt, an dem sie bestanden werden, ohne dass andere Regressionstestfehler auftreten.

Entwickler und Manager können das System gemeinsam verbessern, indem sie:

  • gemeinsame Einigung über die wichtigen Bereiche der Entwicklung und Erprobung
  • unabhängige Überprüfung und Ausführung der Testsuite.
  • die Entscheidung, keine Funktion zu erstellen, die nur einen begrenzten geschäftlichen Nutzen hat, jedoch viele Entwicklungs- und Testarbeiten erfordert, um diese Funktion bereitzustellen. (Die produktivste Codezeile ist eine, die Sie nicht geschrieben haben, weil sie keinen geschäftlichen Nutzen bringt.).
  • partitionierung des Systems in eine Architektur (z. B. Model-View-Controller), die die schrittweise Entwicklung von Funktionen erleichtert, ohne das gesamte System zu beschädigen.

Der Entwickler kann die Metrik nicht spielen, weil:

  • redundante Tests werden durch die Überprüfung durch den Manager blockiert.
  • feinkörnige Tests können durch die Überprüfung durch den Manager blockiert werden.
  • feinkörnige Tests verbessern die Qualität des Systems.

Der Manager kann die Metrik nicht spielen, weil:

  • das Ablehnen zu vieler Tests führt zu Entwicklerabrieb.
  • wenn Sie zu viele Tests anfordern, wird es schwierig, eine spätere Frist abzulehnen.

Der Entwickler kann den Manager nicht schrauben, weil

  • Jede mit Tests gelieferte Funktionseinheit muss auch die Regressionssuite bestehen. Dies zwingt den Entwickler, sich sorgfältig zu entwickeln, ohne anderen Code zu brechen.
  • Jeder Anspruch auf Arbeit muss durch Bestehen neuer Tests und Regressionstests nachgewiesen werden können.

Der Manager kann den Entwickler da nicht verarschen.

  • Jede angeforderte Funktionseinheit muss wichtige Testfälle und eine Schätzung der Anzahl der Testfälle enthalten, die zum Abschluss der Arbeit erforderlich sind.
  • Es ist schwer, nach einem aggressiven Zeitplan und/oder freien Überstunden zu fragen, wenn Sie offensichtlich viel Arbeit verlangen.

Ein weiterer großer Vorteil für den Manager besteht darin, dass er neue Entwickler gewinnen kann und weiß, dass sie keinen Code liefern können, der das System stillschweigend zerstört (weil die Regressionstestsuite dies abfängt).

Der große Nachteil des Managers besteht darin, dass er zugeben muss, dass sein System komplexer ist, als es auf der 1-seitigen Beschreibung der Funktion erscheint. Der andere Nachteil ist, dass die Transparenz dieser Methode es schwierig macht, Entwickler für Geschäftsausfälle verantwortlich zu machen.

7
Jay Godse

Es ist sicherlich möglich, alle Arten von komplizierten Metriken zu entwickeln, um die Leistung zu bewerten, aber letztendlich muss ein wesentlicher Teil Ihres Urteils auf Subjektivität und Eingaben von Personen beruhen, die der Codebasis nahe stehen.

Zum Beispiel ist es für einige Teams durchaus möglich, intern abscheulichen, nicht wartbaren Slop mit einer sehr schnellen Geschwindigkeit herauszuholen, und dies könnte sogar die erforderliche Frist und Spezifikation einhalten. Aber ist die technische Verschuldung, die sich aus dieser Art von Arbeitsstil ergibt, schlimmer, als wenn das Team etwas Robustes und Wartbares produziert hätte, aber die Frist um einige Wochen verschoben hätte? Es hängt davon ab, ob.

Wenn der Zweck der Frage darin besteht, ein Produktivitätsproblem zu lösen, würde ich sagen, dass was der Manager tatsächlich tut, um die Arbeit des Teams zu erleichtern, ist genauso oder wichtiger als jede Messtechnik, die zur Bewertung des Teams verwendet wird. Es ist eine Einbahnstraße. Mit anderen Worten, ich sage, dass Metriken in Ordnung sind, aber wenn Sie mehr aus einem Team herausholen möchten, ist die ultimative Frage, ob der Manager alles tut, um sicherzustellen, dass das Team produktiv ist.

Dies geht weit über das Schreiben einer Spezifikation, das Finden eines Teams, das Werfen der Spezifikation "über die Mauer" und das Klicken auf eine Stoppuhr hinaus.

6
Angelo

Einige Ideen:

  1. funktionen implementiert
  2. fehler behoben (auch für Fehler, die später von der Qualitätssicherung wieder geöffnet wurden)
  3. benutzerbeschwerden behoben (beachten Sie, dass es nicht dasselbe ist wie 2 - ein schwerwiegender Fehler kann Nackenschmerzen sein, während 100 Tippfehler möglicherweise nicht so wichtig sind)

Vielleicht möchten Sie auch verfolgen:

  1. Codeabdeckung durch Tests
  2. Codeabdeckung durch interne Dokumentation
  3. Funktionsabdeckung durch externe (Benutzer-) Dokumentation
2
StasM

Messen Sie genauso, wie Sie vom Kunden gemessen werden. In Bezug auf Funktionscode, aber in kleinerem Maßstab.

Machen Sie kurze Ziele - ein oder zwei Wochen - und prüfen Sie, ob die Programmierer die Ziele erreichen, und zwar auf zufriedenstellende Weise.

Ich würde dringend empfehlen, den Code einer Peer-Review zu unterziehen, da Sie so schlechten Code im Voraus erkennen können.

2
user1249

Wie wäre es mit der Umsatzrate des Produkts/der Dienstleistung?.

Manchmal habe ich gehört, dass es eine Provision/ein Prozentsatz des Bruttos genannt wird

Die Leute kaufen gute Produkte, nicht wahr?

Das Unternehmen möchte das Produkt verkaufen (oder vielleicht Service, der gleiche Unterschied dazu)

Wenn Sie das möchten, messen Sie es.

Ein bisschen wie zu sagen, dass Leute, die ein Auto entwerfen, das gute Bewertungen bekommt und sich gut verkauft, wirklich gute Arbeit geleistet haben.

Nehmen Sie nun diese Metrik an und das Programmierteam möchte aus zwei Gründen mit dem Verkäufer interagieren.

  • Promsing underliverable

  • Produkt nicht effektiv an Kunden verkaufen

1
Tim Williscroft

Das Schreiben von Code/Programmieren ist nicht so, als würde man einen Hammer auf einen Nagel setzen. Ähnlich wie beim "Schreiben" im Allgemeinen können Sie meiner Meinung nach auch keine typischen Metriken anwenden.

Könnten Sie sich nicht einfach ihre Check-Ins ansehen oder was sie durch Peer-Review oder Code-Review gemacht haben?

Oder wissen Sie, ob sie tatsächlich Arbeitscode und Lösungen produzieren, die Probleme beheben?

0
Jack Marchetti