Umgang mit unrealistischen Leistungserwartungen [geschlossen]

Welche Fakten und Quellen kann ich verwenden, um einen Manager, mit dem ich derzeit zusammenarbeite, davon zu überzeugen, dass das Umschreiben eines Projekts mit ~20.000 Codezeilen in einem Monat ein völlig unrealistischer Plan ist und dass das Schreiben von ~5.000 Zeilen funktionalen Code darin 3 Wochen sind eigentlich ein gutes Ergebnis?

Wie wäre es, wenn Sie damit beginnen, wie Sie zu Ihren eigenen Schätzungen gekommen sind? Wo sind Ihre unterstützenden Daten dafür?
@CodeGnome, nur meine subjektive Erfahrung. Deshalb frage ich nach Fakten und Quellen.
Keiner von Ihnen hat tatsächlich unterstützende Daten, beide Zahlen sind im Wesentlichen erfunden. Fragen Sie, ob Sie sehen können, wie viel Sie in einer Woche liefern können, und rechnen Sie dann hoch.
@Nathan Cooper, gib mir dann solche Daten. Es macht mir nichts aus, wenn ich falsch liege – mit Fakten.
@XenoMind Es ging darum, Ihre eigenen Daten zu erstellen, da Daten von anderen Teams nicht Ihr Team sind und für Sie nicht die Realität widerspiegeln .
@XenoMind und diese Realität ist, dass keine zwei Teams die gleiche Arbeit in der gleichen Zeit erledigen werden.
@RubberDuck, und keine zwei Autos können mit 1 Liter Benzin die gleiche Strecke zurücklegen ...
Mögliches Duplikat von Was sind akzeptable SLoC-Raten?

Antworten (3)

Eine frühere Antwort, die ich hier auf Project Management Stack Exchange geschrieben habe, bietet hohe/niedrige/nominale Werte für Quellcodezeilen, die basierend auf dem Projekttyp pro Mitarbeitermonat geschrieben wurden. Spezifischere Daten sind immer besser – die Verwendung historischer Daten aus Ihren vergangenen Erfahrungen oder früheren Projekten in Ihrem Unternehmen ähnlicher Größe und Reichweite wäre relevanter. Wie Sie diesen Daten entnehmen können, liegen sogar 5000 SLOC/Personalmonat weit außerhalb der nominalen Bereiche für jeden Anwendungstyp und jede Anwendungsgröße.

Bei der Schätzung/Evaluierung eines Projekts geht es um mehr als nur um die Codezeilen, die erstellt/geändert werden müssen (oder wurden). Größe und Art der Änderung/Hinzufügung, Komplexität des Codes, Wiederverwendung des Codes, Programmiersprache, Ausführlichkeit des Codes (eine Zeile kann genau das Gleiche tun wie fünf Zeilen – und das kann gut oder schlecht sein, je nachdem Situation und Meinung) und Verwendung externer Pakete, um nur einige zu nennen. Und viele davon werden sich ändern, nicht nur von Team zu Team, sondern von Projekt zu Projekt .

Die einzigen Menschen, die angesichts all dieser Faktoren wirklich in der Lage sind, eine vernünftige und realistische Einschätzung abzugeben, sind die Menschen, die die Arbeit tatsächlich erledigen.Wenn ein Manager versucht zu schätzen, was „realistisch“ ist, wird seine Schätzung von anderen Faktoren – wie Zeitplänen und anderen Einschränkungen – beeinflusst, die solche Schätzungen verfälschen würden, selbst wenn der Manager die Möglichkeit hätte, die Arbeit anderweitig richtig einzuschätzen.

Ein effektiveres System besteht darin, dass die Entwickler die Schätzung vornehmen, der Manager auf die Fähigkeit des Entwicklers vertraut , Schätzungen vorzunehmen (wenn der Manager dies nicht tut, ist dies ein separates Problem, das angegangen werden muss), und dann muss der Manager eine Entscheidung treffen ob der durch die Arbeit geschaffene Mehrwert den geschätzten Aufwand wert ist, der dafür aufgewendet wird.

Da Sie über Codezeilen sprechen, können Sie die Diagramme eines beliebten Github-Projekts überprüfen, um zu sehen, wie viele Zeilen in ähnlichen Zeiträumen festgeschrieben werden

https://github.com/Microsoft/dotnet/graphs/contributors

1. Open-Source-Entwicklung geschieht in Schüben. 2. Sie haben Microsoft, Microsoft als Benchmark genannt? Ich bin bereit zu wetten, dass nur sehr wenige Unternehmen mit der Abwanderungsrate von MS mithalten können.
1. Sie können einzelne Mitwirkende überprüfen, die kontinuierlich für einen bestimmten Zeitraum an dem Projekt arbeiten. 2. Überprüfen Sie erneut einzelne Mitwirkende, um den Effekt aufzuheben, dass Unternehmen mehr Entwickler haben
Umgang mit unrealistischen Leistungserwartungen [geschlossen]
AntwortenHierDatenschutz-Bestimmungen1y, 0v