it-swarm.com.de

Ich mache 4-5x mehr Story-Punkte als der Durchschnitt, produziere aber Fehler mit der halben Rate. Grafiken sagen, dass es 2x mehr Fehler gibt, wie man damit umgeht?

Es ist daher allgemein anerkannt, dass Top-Tier-Programmierer eine Größenordnung mehr/besseren Code erzeugen können als ihre durchschnittlicheren Kollegen.

Es ist auch allgemein anerkannt, dass die Fehlerrate im Code für Programmierer relativ konstant ist .

Stattdessen wird es tendenziell von den Prozessen beeinflusst, die beim Schreiben des Codes und nach dem Schreiben des Codes verwendet werden. (So ​​wie ich es verstehe) Menschen neigen dazu, Fehler mit einer ziemlich konstanten Rate zu machen - bessere Programmierer bemerken einfach mehr von ihnen und können sie schneller beheben.

  • Beachten Sie, dass beide obigen Behauptungen aus Code Complete von Steve McConnell stammen - es handelt sich also nicht um unterschiedliche Perspektiven.

Ich habe dies kürzlich in meinem Code gesehen. Ich kann ungefähr 4-5x so viel Code wie viele meiner Kollegen (gemessen an den vom Team geschätzten Story-Punkten) mit höherer Qualität (basierend auf Leistungsmetriken und der Anzahl der nach dem Einchecken vorgenommenen Änderungen) herausarbeiten. Aber ich mache immer noch Fehler. Zwischen besseren Unit-Tests, einem besseren Verständnis der Funktionsweise des Codes und einem besseren Auge für Probleme bei der Codeüberprüfung produziere ich nicht das 4-5-fache der Anzahl der Fehler.

Aber ich produziere immer noch ungefähr zweimal so viele Fehler, die von der Qualitätssicherung gefunden wurden wie andere Entwickler in meinem Team. Wie Sie sich vorstellen können, verursacht dies einige Probleme mit nicht-technischen Leuten, die metrische Messungen durchführen (lesen Sie: mein Chef).

Ich habe versucht darauf hinzuweisen, dass ich Fehler mit der halben Rate meiner Kollegen produziere (und doppelt so viele behebe), aber es ist ein schwerer Verkauf, wenn es Grafiken gibt, die besagen, dass ich doppelt so viele Fehler produziere.

Wie kann man mit der Tatsache umgehen, dass eine höhere Produktivität zu einer erhöhten Anzahl von Fehlern führt?

43
Telastyn

Ich denke, Sie mischen Ihre Bedenken. Und es gibt nichts auf Ihrer Seite, was Sie ändern müssen.

Produktivität ist ein Hinweis darauf, wie schnell ein Projekt abgeschlossen sein wird. Projektmanager und alle anderen möchten wissen, wann das Projekt geliefert wird. Höhere oder schnellere Produktivität bedeutet, dass das Projekt früher geliefert wird.

Die Fehlerrate hängt nicht von der Produktivität ab, sondern von der Größe des Projekts. Beispielsweise können Sie N Fehler pro Y Codezeilen haben. In dieser Metrik gibt es nichts, was sagt (oder interessiert!), Wie schnell diese Codezeilen geschrieben werden.

Wenn Sie eine höhere Produktivität haben, werden Sie sehen, dass die Fehler schneller geschrieben werden. Aber Sie würden sowieso diese Anzahl von Fehlern haben, da dies an die Größe des Projekts gebunden ist.

Wenn überhaupt, bedeutet eine höhere Produktivität, dass Sie am Ende des Projekts mehr Zeit haben, um diese Fehler zu finden, oder der Entwickler kann die von ihm erstellten Fehler schneller finden.1


Um die persönlicheren Aspekte Ihrer Frage anzusprechen.

Wenn Ihr Chef die Anzahl der von Ihnen verursachten Fehler im Gegensatz zur Anzahl der von Ihnen verursachten Fehler genau betrachtet, ist eine Schulungssitzung angebracht. Die Anzahl der erstellten Fehler ist ohne Sicherungsrate bedeutungslos.

Um dieses Beispiel auf das Äußerste zu bringen, sagen Sie bitte Ihrem Chef, dass ich Ihr Gehalt verdoppeln möchte. Warum? Ich habe absolut keine Fehler für Ihr Projekt erstellt und bin daher ein viel überlegener Programmierer als Sie. Was? Er wird ein Problem haben, dass ich keine einzige Codezeile erstellt habe, die Ihrem Projekt zugute kommt? Ah. Jetzt haben wir Verständnis dafür, warum die Rate wichtig ist.

Es hört sich so an, als ob Ihr Team über die Metriken verfügt, um Fehler pro Story-Punkt zu bewerten. Wenn nichts anderes, ist es besser, als an der rohen Anzahl der erstellten Fehler gemessen zu werden. Ihre besten Entwickler sollten mehr Fehler erstellen, weil sie mehr Code schreiben. Lassen Sie Ihren Chef diese Grafik wegwerfen oder zumindest eine weitere Serie dahinter werfen, die zeigt, wie viele Story-Punkte (oder welchen Geschäftswert Sie messen) neben der Anzahl der Fehler. Diese Grafik wird eine genauere Geschichte erzählen.


1Dieser besondere Kommentar hat weitaus mehr Aufmerksamkeit auf sich gezogen, als beabsichtigt war. Seien wir also etwas pedantisch (Überraschung, ich weiß) und konzentrieren wir uns wieder auf diese Frage.

Die Wurzel dieser Frage liegt darin, dass ein Manager die falschen Dinge betrachtet. Sie betrachten die Gesamtzahl der Fehler, wenn sie die Generierungsrate im Verhältnis zur Anzahl der erledigten Aufgaben betrachten sollten. Lassen Sie uns nicht davon besessen sein, an "Codezeilen" oder Story Points oder Komplexität oder was auch immer zu messen. Das ist nicht die Frage, und diese Sorgen lenken uns von der wichtigeren Frage ab.

Wie in den Links des OP dargelegt, können Sie eine bestimmte Anzahl von Fehlern in einem Projekt allein anhand der Größe des Projekts vorhersagen. Ja, Sie können diese Anzahl von Fehlern durch verschiedene Entwicklungs- und Testtechniken reduzieren. Auch das war nicht der Punkt dieser Frage. Um diese Frage zu verstehen, müssen wir akzeptieren, dass für ein Projekt mit einer bestimmten Größe und Entwicklungsmethodik eine bestimmte Anzahl von Fehlern auftritt, sobald die Entwicklung "abgeschlossen" ist.

Kommen wir also endlich zu diesem Kommentar zurück, den einige völlig missverstanden haben. Wenn Sie zwei Entwicklern Aufgaben mit vergleichbarer Größe zuweisen, erledigt der Entwickler mit einer höheren Produktivität seine Aufgabe vor dem anderen. Dem produktiveren Entwickler steht daher am Ende des Entwicklungsfensters mehr Zeit zur Verfügung. Diese "zusätzliche Zeit" (im Vergleich zum anderen Entwickler) kann für andere Aufgaben verwendet werden, z. B. für die Bearbeitung der Fehler, die durch einen Standardentwicklungsprozess sickern.

Wir müssen das OP beim Wort nehmen, dass sie produktiver sind als andere Entwickler. Nichts in diesen Behauptungen deutet darauf hin, dass das OP oder andere produktivere Entwickler in ihrer Arbeit schlampig sind. Wenn Sie darauf hinweisen, dass es weniger Fehler geben würde, wenn Sie mehr Zeit mit der Funktion verbringen würden, oder wenn Sie darauf hinweisen, dass das Debuggen nicht Teil dieser Entwicklungszeit ist, verpassen Sie die Fragen. Einige Entwickler sind schneller als andere und produzieren vergleichbare oder qualitativ bessere Arbeiten. Siehe auch die Links, die das OP in seiner Frage enthält.

41
user53019

Verbringen Sie einen Teil dieser zusätzlichen Zeit damit, Ihren Code zu reinigen, zu polieren und zu testen. Es wird immer noch Fehler geben, aber es wird weniger geben. Das braucht Zeit. Ihre Code-Ausgaberate wird sinken, aber Ihre fehlerfreie Code-Ausgabe wird zunehmen, was zu einer besseren Produktivität führt. Weil Bugs teuer sind.

Können Sie Ihren Code in einem Zweig oder einer Testumgebung aufbewahren, bis Sie ihn herumwerfen und mehr Fehler entdecken? Fehler in einem Zweig verursachen im Allgemeinen weniger Wellen als Fehler im Produktionscode.

Aber ich grabe nicht genau Ihre Behauptungen, die zu Ihrer Frage führen. Und vielleicht ist es auch Ihr Chef nicht.

Ich denke nicht, dass jeder Codierer die gleiche Fehlerrate erzeugt. Ihr zweiter Link ist eigentlich völlig unangebracht, da er verschiedene Sprachen vergleicht, nicht verschiedene Fähigkeiten der Programmierer. Code complete erwähnt einige Messungen mit großen Stichproben, die sich eher auf den Prozess als auf die Fähigkeiten der Codierer beziehen. Und wenn sie sagen, dass Top-Tier-Codierer mehr/besseren Code produzieren, bedeutet ein Teil davon, dass es weniger Fehler gibt. Kommt auf die Anwendung an. Also, ja, ich denke es ist IS eine Frage unterschiedlicher Perspektive.

Am Ende, wenn der Chef saubereren Code will, geben Sie ihm saubereren Code.

21
Philip

Ich werde auf die Beine gehen und der Anwalt des Teufels sein. Das heißt nicht, dass ich nicht mit Ihrer Notlage sympathisiere, aber mein Mitgefühl wird Ihnen nicht helfen. Erlauben Sie mir also, Philipps Perspektive hinzuzufügen:

Ihr Chef kümmert sich um die Qualität des Produkts, teilweise, weil sein Name und sein Ruf damit verbunden sind. Ein Teil der Qualität ist die wahrgenommene Anzahl von Fehlern. Wenn Sie einen fantastischen Bohrer verkaufen, der viermal schneller als alle anderen Bohrer bohrt, aber auch doppelt so oft ausfällt, haben Sie einen schlechten Ruf. Selbst wenn es fraglich ist, ob der Bohrer eine bessere Leistung erbringt, gewöhnen sich die Leute an die Geschwindigkeit, aber sie werden sich an die Pannen erinnern.

Im Nachhinein sind die meisten Fehler offensichtlich vermeidbar. Wenn Sie nur etwas vorsichtiger wären, würde Ihr Chef das Gefühl haben, Sie könnten diese Probleme vermeiden und alle notwendigen Reinigungsarbeiten durchführen -oben. Aus seiner Sicht ist das eine triviale, sinnliche Frage, und jeder Streit, den Sie darüber führen, wird nicht funktionieren und Sie schlecht aussehen lassen.

Er kann Ihre überlegene Produktivität nicht messen. Sie behaupten eine höhere Produktivität basierend auf einer überprüfbaren Metrik. Wie stehen Ihre Kollegen dazu? Stimmen sie vielleicht widerwillig zu, dass Sie ein produktiverer Programmierer sind, oder sind Sie Ihrer Meinung nach allein? Sie werden einen stärkeren Punkt machen, wenn Sie andere Leute haben, die Ihre Behauptungen stützen.

Das ist für die Perspektive. Wie können Sie diese frustrierende Situation, in der Sie sich befinden, „beheben“?

Verlangsamen Sie etwas. Erwähnen Sie explizit, wer Aufgaben verteilt, die Sie versuchen werden, die Fehlerrate (*) zu senken, damit sie ' Sie sind nicht überrascht von Ihrer geringeren Aufnahme. Wenn überhaupt, verringert eine Verlangsamung die Anzahl der Fehler, die Ihnen aufgrund mangelnder Versorgung zugewiesen wurden.

(*) Es gibt einen Unterschied zwischen einerseits der Bestätigung, dass sind Fehler in Ihrem Namen und dass Sie versuchen, diesen Betrag zu verringern, und andererseits zuzugeben, dass Sie habe zu viele Fehler in deinem Namen und sollte Maßnahmen ergreifen.

Versuchen Sie nicht, Ihren Chef zu überzeugen , weil es nicht funktioniert. Auch das bedeutet nicht, dass Sie zugeben müssen Ihren Punkt; Sie können einen Kontrapunkt präsentieren und Ihre Meinung vertreten, ohne seine Bedenken auszuräumen. Denn wenn Sie den Punkt argumentieren und Ihre überlegene Produktivität nicht zufriedenstellend beweisen können (und selbst wenn Sie können), riskieren Sie, Ihre Kollegen zu beleidigen oder sie abzulehnen. Du willst nicht dieser Typ sein.

21
JvR

Angenommen, Sie würden in 20% der Zeit dieselbe "Menge" an Code wie Ihre Kollegen produzieren, könnten Sie viermal so viel dafür ausgeben, den Code wirklich zu debuggen und zu perfektionieren, was Ihre Fehlerrate noch weiter reduzieren würde. Dann könnten Sie sich einen guten Programmierer nennen.

Die größte Frage ist, warum Sie fünfmal so viel codieren wie die anderen, anstatt Qualität anzustreben. Ist das etwas, was dein Ego dir diktiert oder zwingt dich dein Chef?

Außerdem müssen Sie die Kosten für die Behebung eines Fehlers berücksichtigen. Wenn Sie es früh finden, befinden Sie sich möglicherweise noch "genug" im Code, um es schnell zu beheben. Wenn es erst nach einem weiteren Monat der Entwicklung erscheint, kann es schwierig sein, Sie zu finden oder sogar zu zwingen, große Teile des bereits programmierten Codes zu ändern.

Sie scheinen die Fähigkeiten zu haben, Code zu produzieren, und Sie könnten es großartig machen, wenn Sie sich auf Qualität anstatt auf Geschwindigkeit konzentrieren. Probieren Sie es eine Weile aus, ich denke, es wird Ihnen gefallen.

Das nächste Problem ist dann, die Bestätigung (sprechen Sie Geld) für Ihre bessere Leistung zu erhalten. Sprechen Sie mit Ihrem Chef und fragen Sie ihn, wie er vorgehen soll. Es ist schließlich seine Firma und sein Geld. Wenn er möchte, dass Sie weniger Fehler produzieren, sollte er auch entscheiden, auf welche Weise dies geschieht.

20
awsm

Entwickler können intelligent und sogar genial sein und die Fähigkeit besitzen, Solo zu verstehen und zu codieren, ohne gute Entwickler zu sein. Ein guter Entwickler schafft ein qualitativ hochwertiges Stück Arbeit und verbessert das gesamte Projekt.

Ich sage nicht, dass Sie das sind, aber einer der frustrierendsten Programmierer, mit denen ich je zusammengearbeitet habe, hat mehr Code geschrieben als jeder andere im Team, und wir hatten gute Leute im Team. Wir haben Commits mit einer Ranking-Software verfolgt, daher war es für einige Leute fast ein Wettbewerb. Er produzierte Code-Schwaden, hinterließ NULL-Dokumentation und undurchdringliche Wälder und machte es mir tatsächlich schwer, einen Teil meines eigenen Codes zu verstehen (das kann ich alleine tun, vielen Dank!). Schließlich hätte er das Projekt fast entgleist, weil er zu einer Ein-Mann-Show wurde. Die Leute konnten ihm nicht folgen. Wir waren als Team nicht synchron. Wir haben einige seiner Funktionen Jahre später neu geschrieben, um die Wartbarkeit wiederherzustellen.

Das, was ich von ihm wollte, war, langsamer zu werden und mehr Zeit zu verbringen: 1) Verbesserung der Qualität der Codebasis 2) Kommunikation mit dem Team 3) Arbeiten an Dingen, die anderen geholfen haben und ihm helfen, Features/Storys fertigzustellen 4) Reparieren Fehler

Ich bin nicht damit einverstanden, die Produktivität anhand von Codezeilen zu messen, aber es ist eine Schlüsselmetrik. Enthält Ihr Codezähler Kommentare? In diesem Fall gibt es eine einfache Möglichkeit, die Leitungsausgabe beizubehalten und gleichzeitig die "Fehlerquote" zu verringern. Erhöhen Sie einfach die Qualität und Quantität der Kommentare, die Sie schreiben. Kommentare haben selten Fehler (obwohl sie können) und im Allgemeinen haben wir nicht genügend Qualitätskommentare. Ich bin nicht Duldung der Code-Inflation, aber das Kommentieren ist wie eine Mini-Code-Überprüfung, es zwingt Sie zum Nachdenken, Umgestalten und Verbessern.

8
codenheim

Der Versuch, das Management aufzuklären, ist kein Anfänger. Es gibt ein altes Klischee: "Wirst du mir oder deinen Lügenaugen glauben?" Was Ihre Chefs betrifft, sind die Fehlerzahlen. Keine Rationalisierung wird ihnen sagen, dass es akzeptabel ist. Es ist mehr als doppelt so riskant. Darüber hinaus sind Sie nicht der einzige, der von Ihrer Fehleranzahl betroffen ist. QA hat doppelt so viel Arbeit, um Ihre Fehler zu identifizieren. Das Management möchte daher, dass Sie weniger davon machen.

Die beste Lösung ist, die Anzahl der von Ihnen verursachten Fehler zu reduzieren, Punkt. Das Management wird nicht nur glücklicher sein, sondern auch Sie. Willst du nicht? Denn ich bin mir ziemlich sicher, so sehr Sie es genießen, sich zu rühmen, dass Sie Ihre Kollegen um den Faktor vier übertreffen, würden Sie Liebe sagen, dass Sie es tun, indem Sie die gleiche Anzahl oder sogar weniger machen. Bugs als sie.

Wie Sie sagten, "... wird die Fehlerrate im Code ... tendenziell durch die Prozesse beeinflusst, die beim Schreiben des Codes und nach dem Schreiben des Codes verwendet werden." Wenn Sie die Rate ändern möchten, mit der Sie Fehler erzeugen, müssen Sie die Prozesse ändern, die Sie zum Schreiben von Code verwenden.

Programmierer verwenden Produktionsmethoden, um Code zu erzeugen, ähnlich wie eine Fertigungslinie Methoden verwendet, um ein Massenprodukt zu erzeugen. Okay, die Praktiken der Softwareindustrie ähneln eher dem Schnickschnack von Ästen im Wald. Da wir jedoch Maschinen produzieren, sollten wir die gleiche Sorgfalt und Disziplin anwenden, die für die Hochgeschwindigkeitsmaschinen der Massenproduktion verwendet wird.

Dazu gehören dieselben Techniken, die in der Massenproduktion zur Reduzierung der Fehlerrate verwendet werden: Ursachenanalyse, um festzustellen, warum Fehler auftreten, und Änderung des Prozesses, damit dies nicht der Fall ist. Oder zumindest, dass Sie vor der Qualitätssicherung fangen.

  1. Erstellen Sie eine Liste Ihrer Fehler. Sie haben wahrscheinlich schon einen Dank an die QA-Leute. Möglicherweise auch kategorisiert. Art des Fehlers, Schweregrad, der Punkt, an dem der Fehler in den Code eingefügt wurde usw.

  2. Wählen Sie die größte Kategorie von Fehlern. Da Ihr Volumen so hoch ist, sollten Sie zuerst auf diese Kategorie abzielen. Andere Kategorien sind die am einfachsten zu findenden und die am einfachsten zu erstellenden.

  3. Wenn Sie wissen, wo diese Fehler in den Code eingefügt werden, sollten Sie in dieser Phase (und früher) Änderungen vornehmen, die verhindern, dass diese Fehler auftreten, und Möglichkeiten finden, sie in dieser Phase leichter zu erkennen.

  4. Achten Sie darauf, dass Sie nicht programmierbezogene Nebeneffekte berücksichtigen, da diese die Qualität Ihrer Arbeit beeinträchtigen können. Hintergrundmusik, Unterbrechungen, Mahlzeiten, zu lange Arbeit ohne Pause, Hunger usw.

Was Sie finden, kann dazu führen, dass Sie langsamer werden. Auf der anderen Seite kann es Ihnen helfen, noch schneller zu produzieren, da Sie weniger Dinge überarbeiten müssen, die Sie bereits hinter sich gelassen haben. So wie es ist, ist viermal so viel Code nicht annähernd eine Größenordnung besser als Ihre Kollegen, daher ist eine Änderung Ihres Prozesses definitiv der richtige Weg.

4
Huperniketes

Ändern Sie Ihr Ziel von der Erstellung des meisten Codes zu der Unterstützung des Unternehmens bei der Weiterentwicklung.

Da Sie anscheinend viele Kollegen und zusätzliche Zeit zur Verfügung haben, können Sie Ihre Kollegen am besten bei einer schnelleren Bereitstellung von Funktionen und Fehlerkorrekturen unterstützen.

Helfen Sie Ihren Kollegen durch

  • verwenden von Codeüberprüfungen zur Verbesserung der Codequalität und -erziehung.
  • prozessautomatisierung schaffen, um ihre Arbeit schneller und ihr Leben einfacher zu machen.
  • bessere Tests mit ihnen schreiben
  • angriff auf technischen Code zur Verbesserung der Codebasis
  • der Ansprechpartner zu sein, der immer zur Verfügung steht, um anderen zu helfen.
  • schreiben/Verbessern von Tools, die die Entwicklerproduktivität steigern
  • wenn Sie mehr Einfluss haben, sollten Sie sich beim Management für bessere Werkzeuge/Geräte/Arbeitsbedingungen für Ihre Mitarbeiter einsetzen.
  • vorbereitung und Leitung von Schulungssitzungen zum Schreiben von besserem Code.
  • demut üben
3
Michael Durrant

Wie kann man mit der Tatsache umgehen, dass eine höhere Produktivität zu einer erhöhten Anzahl von Fehlern führt?

Ihr Chef ist die einzige Person, die dies in Ihrem Fall beantworten kann. Sprechen Sie mit ihm, weisen Sie auf Ihr besseres Verhältnis hin und lassen Sie ihn entscheiden. Wenn seine Entscheidung keinen Sinn ergibt, ist es Zeit, nach einem Unternehmen mit Ihrer Denkweise zu suchen.

Als Profi sollten Sie in der Lage sein, mit bestimmten Kundenbedingungen zu arbeiten. Stellen Sie nur sicher, dass diese die Konsequenzen verstehen. Ein schönes Bug/Stories-Diagramm kann Ihrem Chef helfen, zu verstehen, wie stark Ihre Produktivität sinken wird, wenn Sie sich die Zeit nehmen, weniger Bugs zu produzieren.

Sie müssen auch diese Punkte berücksichtigen:

  • komplexität von Geschichten, zum Beispiel einfache Getter/Setter-Wrapper im Vergleich zu statistischen Berechnungen oder Echtzeitprogrammierung oder sogar statistischen Echtzeitdaten ...
  • schwere der Fehler, kleine Tippfehler in Textfeldern oder falsche Berechnungsergebnisse, Programmabstürze
  • kosten, um die Fehler zu beheben, sowohl wenn Sie es jetzt, später tun oder wenn jemand anderes Ihren Code verstehen muss, weil Sie gegangen sind
1
Marten Storm

Die Situation ist, dass Sie viermal so schnell arbeiten wie ein durchschnittlicher Programmierer, aber in einer bestimmten Zeit doppelt so viele Fehler machen. Im Verhältnis zu Ihrer Arbeit machen Sie tatsächlich die HÄLFTE so viele Fehler wie "durchschnittlich".

Sie könnten versuchen, auf Ihr geringes Verhältnis von Fehlern zu Arbeit oder sogar auf Fehler zum fertigen Produkt hinzuweisen (die Sie in einem Viertel der normalen Zeit erledigen können). Die meisten Chefs werden das akzeptieren.

Es gibt einige Chefs, die dies nicht tun, weil sie mit einer "zulässigen" Einstellung zu Fehlern pro Zeit arbeiten. Dann können Sie Ihr Arbeitstempo verlangsamen, innerhalb einer bestimmten Zeit ZWEIMAL so viel Arbeit wie der Durchschnitt erledigen und dieselben (oder weniger) Fehler machen, weil Sie mehr Zeit haben, Ihre Arbeit zu überprüfen.

0
Tom Au

Wertschöpfung messen

Argumentieren Sie, dass es wirklich auf den Wert ankommt, den Sie hinzufügen. Dann führen Sie eine grobe (manuelle) Messung ein:

  • Schätzen Sie den Wert der von Ihnen produzierten Funktionalität
  • Subtrahieren Sie Ihr Gehalt
  • Subtrahieren Sie die geschätzten Kosten Ihrer Fehler (zumindest die Kosten für deren Behebung).
  • Subtrahieren Sie die geschätzten Kosten aller anderen von Ihnen produzierten technischen Schulden

Der Rest ist Ihre Wertschöpfung. Ebenso für alle anderen.

Diese Schätzungen sind schwierig, aber auch grobe können den Punkt machen. Der bloße Prozess der Erörterung dieser Schätzungen ist für das Team und das Projekt nützlich.

0
Lutz Prechelt

Wenn Ihr Chef möchte, dass Sie die Qualität Ihrer Arbeit verbessern, verbessern Sie die Qualität Ihrer Arbeit.

Sie sollten auf null Fehler abzielen und nicht nur doppelt so viele produzieren wie der nächstbeste Programmierer.

0

Sie sollten Ihrem Chef mitteilen, dass die von ihm verwendeten Metriken ziemlich fehlerhaft sind. Wenn Sie sich die Umsätze der Wachen in der NBA ansehen, werden Sie feststellen, dass sie tendenziell höhere Zahlen als Stürmer haben. Aber das liegt daran, dass sie mehr mit dem Ball umgehen. Wenn ein nicht startender Wächter 1/5 so viel spielt wie ein startender Wächter und den Ball durchschnittlich dreimal umdreht .vs. Ein Startschutz, der den Ball sieben Mal pro Spiel umdreht - auf den ersten Blick sieht es möglicherweise so aus, als wäre der Startschutz schlechter. Wenn Sie jedoch die Anzahl der Umsätze durch die Anzahl der gespielten Minuten dividieren, hat der Startschutz eindeutig viel bessere Zahlen, basierend auf den gespielten Minuten.

Ebenso haben Sie viel bessere Zahlen, wenn die Anzahl der Fehler durch die Anzahl der abgeschlossenen Story-Punkte geteilt wird. Das würde ich Ihrem Manager vorschlagen. Ändern Sie die Metrik in die Anzahl der Fehler geteilt durch die abgeschlossenen Story-Punkte, oder fügen Sie zumindest eine neue Metrik hinzu, wenn die Gesamtzahl der Fehler pro Entwickler benötigt wird. Da jedoch einige Story-Punkte viel schwieriger und komplexer sind als andere Story-Punkte, kann und wird es erhebliche Abweichungen geben, die auch vom Manager berücksichtigt werden müssen.

Ich denke nicht, dass Sie langsamer fahren sollten.

0
Bob Bryan