Sollte ein Entwickler eine von einem Excel-Makro durchgeführte Workload-Schätzung akzeptieren?

12

In einem neuen Projekt musste ein Freund Tests schreiben, bei denen die zum Schreiben erforderliche Zeit von einem Excel-Makro berechnet wurde, das von seinem Nicht-Entwickler-Manager geschrieben wurde.

Sollte ein Entwickler unter solchen Umständen die Verantwortung übernehmen, die Tests in der berechneten Zeit zu schreiben und auszuführen? Sind die Ergebnisse dieser Tests vertrauenswürdig?

Zur Information, mein Freund lehnte es ab, für Schätzungen verantwortlich zu sein, die er nicht gemacht hatte, und fragte, ob es gelingen würde, an einem anderen Projekt zu arbeiten.

project-management productivity testing

— Nelstaar
quelle

7

Was bedeutet es, eine "Schätzung" zu "akzeptieren"? Wenn ich schätze, dass ich 30 Tage brauche, um etwas zu tun, was passiert, wenn ich es "akzeptiere"? Was kümmert es mich, wie lange ich Ihrer Schätzung nach etwas tun muss? Sie können davon ausgehen, dass ich es in einer Minute tun werde, wenn es mich interessiert, Sie werden sich irren, nicht ich.

— David Schwartz

2

@David Das Akzeptieren einer Schätzung bezieht sich im Allgemeinen auf das Überprüfen der Schätzungen und das Sicherstellen eines Konsenses. Wenn zum Beispiel ein parametrisches Schätzwerkzeug verwendet wird, überprüfen die Projektingenieure diese Daten, um die Konsistenz sicherzustellen, und verwenden möglicherweise eine zweite Methode wie Wideband Delphi.

— Thomas Owens

12

Klingt nach etwas, das Scott Adams für einen Dilbert-Cartoon geschickt werden sollte.

— MetalMikester

1

Solange es eine Überprüfung gibt. Ich dieses spezielle Beispiel gab es keine.

— Nelstaar

5

Denken Sie daran: Eine Schätzung, eine Verpflichtung, ein Ziel und ein Plan zur Erreichung eines Ziels sind vier verschiedene Dinge. Stellen Sie sicher, dass allen klar ist, was diese Dinge sind und welche der vier Dinge die Excel-Ausgabe ist.

— Nlawalker

14

Es hängt davon ab, wie vernünftig sie für den Entwickler sind und auf welchen Daten / Logik sie basieren. (sie könnten auf statistische Daten über mehrere Jahre gesammelt basieren , wie viel Zeit erforderlich war - dieses Entwicklers selbst und / oder durch andere - ähnliche Aufgaben in der Vergangenheit zu lösen ... oder sie vielleicht ganz auf seine Managers basieren - richtig oder falsch - Annahmen.)

Im Idealfall sollte er mit seinem Vorgesetzten besprechen, dass nicht zu erwarten ist, dass man sich für eine von jemand anderem geschätzte Aufgabe einsetzt und Verantwortung dafür übernimmt.

Wenn er sich schlichtweg weigert, sich auf die Schätzungen zu verpflichten, kann dies in der Tat dazu führen, dass er umgehend ersetzt wird. Es ist daher besser, einen weicheren Ansatz zu wählen und direkte Konfrontationen zu vermeiden, wenn dies möglich ist.

— Péter Török
quelle

7

Vermutlich verarbeitet das Makro irgendeine Art von Eingabedaten, es ist nicht nur ein Zufallszahlengenerator? Um Ihre Frage beantworten zu können, müssen wir wissen, was die Eingabedaten sind und was das Makro bewirkt. Ohne dies ist jede Antwort ziemlich bedeutungslos.

Oder geht es bei Ihrer Frage wirklich darum, Schätzungen zu akzeptieren, die von einem Manager ohne einschlägige Erfahrung erstellt wurden? In diesem Fall lautet die Antwort "Nein". Sie (oder Ihr Freund) sollten ihre eigenen Schätzungen erstellen und diese dem Manager vorlegen. Wenn die beiden Zahlen nicht übereinstimmen, müssen sie zusammenarbeiten, um den besten Weg nach vorne zu finden. Vielleicht müssen sie sich darauf einigen, weniger Tests zu schreiben, oder es dauert länger, sie alle zu schreiben.

Punktuelle Ablehnung hilft niemandem, und es macht auch keinen Spaß, an einem Zeitrahmen zu arbeiten, den man nicht einhalten kann. Die Lösung besteht darin, professionell vorzugehen und einen Kompromiss zu finden, der es ermöglicht, die Arbeit fortzusetzen.

— Steve
quelle

Die Tests sind in Unterabschnitte unterteilt (fast atomar) und man erhält eine kleine Schätzung.

— Nelstaar

Ich denke, mit dieser Methode kann der endgültige Tester das Gesamtbild nicht sehen / testen.

— Nelstaar

1

"Vermutlich verarbeitet das Makro irgendeine Art von Eingabedaten, es ist nicht nur ein Zufallszahlengenerator." Es könnte genauso gut zufällig sein, da es nicht möglich ist, JEDE Variable zu erfassen, die einen solchen Algorithmus genau machen würden.

— maple_shaft

1

@maple_shaft: Deshalb nennen sie es eine Schätzung - es wird nicht (oder sollte nicht) erwartet, dass es genau ist. Es spielt keine Rolle, ob Sie mit Excel-Berechnungen oder mit Bleistift und Papier rechnen. Die Verwendung von Excel für Schätzungen ist viel sinnvoller als einige andere 'Techniken', die ich in der

— Praxis

@Treb-Schätzungen sollten so genau sein, wie es die bereitgestellten Daten und der aktuelle Projektstatus angesichts der Unsicherheitsschwelle zulassen.

— Thomas Owens

5

Ganz bestimmt NEIN.

Ein kleines Programm, auch ein großes, kompliziertes Programm, kann unmöglich abschätzen, wie lange ein Programmiervorgang dauern wird. Die Gründe dafür finden Sie unter Mathematische Grenzen der Softwareschätzung . Ein längerer, von Experten geprüfter Artikel mit dem Titel " Große Grenzen für die Softwareschätzung" ist ebenfalls verfügbar.

Ich würde auch meine Meinung zum fraglichen Manager überdenken: Warum glaubt er oder sie, dass ein Tabellenkalkulationsmakro in der Vergangenheit nicht ausprobiert wurde, da in der Vergangenheit alles andere versucht wurde, die Dauer von Softwareaufgaben abzuschätzen.

— Bruce Ediger
quelle

1

Ich habe diese Artikel (noch) nicht vollständig gelesen, aber seit mehr als 20 Jahren werden häufig parametrische Methoden verwendet, um Softwareprojekte innerhalb von 15% abzuschätzen, vorausgesetzt, die Eingabedaten sind gültig. Darüber hinaus können (und wurden) kollaborative Methoden wie Wideband Delphi verwendet, um die Genauigkeit parametrischer Modelle zu bestätigen. In Software Engineering Economics (Boehm) finden Sie Informationen zu parametrischen Methoden und zur Anwendung von Wideband Delphi in Softwareprojekten (sowohl mit als auch ohne paremetrische Modelle).

— Thomas Owens

Ich stimme Thomas zu. Während Sie nicht jede einzelne Aufgabe für ein gesamtes Projekt genau vorhersagen können, können Sie im Verlauf eines Projekts historische Daten für eine bestimmte Organisation verwenden. Einige Aufgaben werden länger und einige kürzer dauern, aber am Ende sind sie durchschnittlich. Insbesondere, wenn das Projekt den bereits von der Organisation durchgeführten Projekten ähnelt. Vor diesem Hintergrund können Schätzungen nicht wirklich schlimme unerwartete Dinge erklären, wie beispielsweise, dass die Hardware / Software nicht wie angekündigt funktioniert, neue Technologien viel schwieriger sind als erwartet, Entwicklermangel, schlechte Führung und schlechtes Management.

— Dunk

1

Sie müssen das Papier lesen und verstehen. Ein einfaches Tabellenkalkulationsmakro hat keine Chance auf eine korrekte Schätzung. Software ist Mathematik, und mathematische Systeme unterliegen manchmal einem kleinen Problem, das als Unvollständigkeit bekannt ist. Ich garantiere Ihnen, dass der betreffende Manager sich selbst betrügt und dass die Ergebnisse des Makros nicht mit der Realität korrelieren.

— Bruce Ediger

1

@Bruce: Nachdem ich erfolgreich Formeln (einschließlich Excel-Tabellen) für die Projektschätzung verwendet habe, kann ich mit Sicherheit behaupten, dass weder Thomas noch der Manager oder ich uns selbst zwangsläufig etwas vormachen. Wie ich bereits sagte, wird jede einzelne Aufgabe unterschiedlich sein, aber im Laufe eines Projekts gleichen sie sich tendenziell aus. Ich habe festgestellt, dass die Verwendung von Formeln (die im Laufe der Zeit entwickelt und geändert wurden) weitaus genauer war als die Schätzungen einzelner Entwickler. Generell sind Entwickler zu optimistisch oder zu pessimistisch. Natürlich funktionieren die Formeln nur, wenn vernünftige Daten vorliegen. Geschicklichkeit ist sicherlich ein Faktor.

— Dunk

Ich habe diese Papiere letzte Nacht gelesen. Sie sprechen gegen über 40 Jahre Erfahrung im Projektmanagement und über 30 Jahre Erfahrung im Softwareprojektmanagement. Siehe iiasa.ac.at/Admin/PUB/Documents/RM-75-071.pdf und sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html

— Thomas Owens

4

Pfui!

Dies ist ein gigantischer "Jobgeruch". Das ist ein unglaubliches Mikromanagement.

Wenn sie nicht darauf vertrauen können, dass ihre Mitarbeiter eine Schätzung abgeben, womit vertrauen sie Ihnen sonst nicht?

— ozz
quelle

1

99% der Entwickler können nicht einmal schlechte Schätzungen abgeben, die auf objektiven oder gar genauen Schätzungen beruhen. Ich sehe also nichts, was auf "Arbeitsgeruch" hindeutet, weil jemand anderes eine Schätzung erstellt hat. Insbesondere wenn sie tatsächliche Daten zur Rechtfertigung ihrer Zahlen verwendeten. Wenn die Leute zur Rechenschaft gezogen werden, um die Schätzung für jede Aufgabe zu erfüllen, ist dies ein Problem mit dem Arbeitsgeruch. Wenn das Tool jedoch alle Aufgaben bei weitem unterschätzt, würden alle Entwickler die Schätzungen vermissen. OTOH, wenn alle anderen die meisten Schätzungen zu erfüllen scheinen und ein anderer Entwickler dies nie tut, dann ist das ein Problem mit dem Entwicklergeruch.

— Dunk

@Dunk - Mein Standpunkt ist, dass Mikromanagement in diesem Ausmaß bei der Entwicklung von Software ein "Job-Geruch" ist und ich dort nicht arbeiten möchte.

— ozz

1

Was Sie Mikromanagement nennen, ist die einzige Möglichkeit, in vielen Branchen Geschäfte zu machen. Wenn Sie keine vernünftigen Kosten- und Zeitvoranschläge für große Projekte erstellen können, wird es für Ihr Unternehmen sehr schwierig sein, Verträge zu erhalten. Im Gegensatz zum Agile-Ideal werden sich Kunden in vielen Branchen nicht auf zweistellige Millionen-Dollar-Verträge festlegen, wenn sie nicht wissen, was sie am Ende bekommen werden. Sie wären nicht glücklich mit der Idee, dass ihr Geld weg ist, sie haben ein funktionierendes Produkt, aber es macht nur 50% von dem, was sie brauchen oder wollen.

— Dunk

@dunk - Wenn Sie mit der Erstellung von Schätzungen durch das Management zufrieden sind, fahren Sie fort. Ich möchte lieber, dass das Entwicklungsteam Schätzungen erstellt. Laut Schätzungen des Managements (zusammen mit den sich ständig ändernden Anforderungen, eine ganz andere Diskussion) liefern viele Softwareprojekte nicht pünktlich und im geplanten Budget. Ich vertraue lieber den Leuten, die die Arbeit machen.

— ozz

Es geht nicht darum, dass das Management Schätzungen vornimmt oder die Personen, die mit den Schätzungen beauftragt sind. Es ist eine Frage des Herausziehens von Schätzungen aus Ihrem Hintern oder des Versuchs, Ihre Schätzungen auf einige objektive Daten zu stützen. Nach meiner Erfahrung führt der Vergleich von Managementschätzungen mit Entwicklerschätzungen dazu, dass Managementschätzungen in der Regel zu längeren Ausführungszeiten führen. Entwickler neigen dazu, optimistisch zu sein .....

— Dunk

3

Definitiv nein.

Ich verspreche Ihnen, dass Manager nicht so getäuscht sind, dass sein Excel-Makro Schätzungen genau vorhersagen kann. Ich streite nicht einmal darüber, was wohlbekannt sein sollte, dass es zu viele Variablen gibt, um so etwas in einem Algorithmus genau vorherzusagen. Wenn er einen solchen Algorithmus erfunden hat, sollte er ihn patentieren und meiner Meinung nach Millionen verdienen.

Was hier wirklich passiert, ist, dass der Manager dieses vermeintliche Excel-Makro als eine kaum verhüllte Verkleidung verwendet, um die Tatsache zu verbergen, dass er unrealistische Erwartungen und übermäßigen Druck auf seine Entwickler ausübt.

Er weiß, dass es sich um BS handelt, und es ist ihm egal, es ist eine Ausrede, Ressourcen zu überbuchen und zu versuchen, Dinge schneller zu erledigen, indem alle seine "wertlosen" Entwickler ständig auf "SPÄT" gesetzt werden.

Dieser Manager klingt wie ein ausbeuterischer Idiot.

— maple_shaft
quelle

1

Nur weil der Manager Schätzungen für die Entwickler erstellt, heißt das nicht, dass sie ungenau sind und wir diese Schlussfolgerung nicht ohne weitere Informationen ziehen können. Wenn der Manager kompetent ist, sollte er realistisch sein und unrealistisch leicht Dinge entsprechend anpassen können.

— rjzii

1

@Rob, Du vergisst den entscheidenden Punkt, den das OP gemacht hat, dass sie an diesen Schätzungen festgehalten werden (strikt angenommen, weil der vorherige Entwickler im Team erwähnt hat, dass "nicht an den Schätzungen festgehalten werden wollte" und neu zugewiesen wurde). An Schätzmodellen ist nichts auszusetzen, aber sie sollten eine grobe Richtlinie und nichts sein, an dem Entwickler festgehalten werden sollten, was das Management leider vielen Menschen angetan hat.

— maple_shaft

2

Hier bestand das Problem darin, dass diese Schätzungen direkt in die Rechnung des Kunden verschoben wurden. Warum nennen manche Manager es immer wieder Schätzungen?

— Nelstaar

@maple_shaft - Ohne zu wissen, wie hoch die Schätzungen sind, ist es schwer zu sagen, ob sie unvernünftig waren und daher Einwände gegen ihre Einhaltung gültig waren. Wenn es sich um faire Schätzungen handelte (dh "Acht Stunden, um Hello World zu schreiben"), ist es kein Problem, über die Philosophie hinaus daran festzuhalten.

— rjzii

3

In einem neuen Projekt musste ein Freund Tests schreiben, bei denen die zum Schreiben erforderliche Zeit von einem Excel-Makro berechnet wurde, das von seinem Nicht-Entwickler-Manager geschrieben wurde.

Es gibt parametrische Schätzmodelle zur Schätzung der Fertigstellungszeit von Projekten, einschließlich Softwareprojekten. Normalerweise bezieht sich die Schätzung auf Produktionscode, aber ich verstehe nicht, warum es nicht hochgerechnet werden kann, um abzuschätzen, wie lange es dauern wird, Testcode zu schreiben. Diese Schätzungen sind jedoch nur so gut wie die Daten, die in sie eingespeist werden.

Angenommen, die verwendete Methode ist ein gültiges Schätzmodell und die Daten sind genau und gültig, gibt es keinen Grund, warum eine gute Schätzung nicht aus einem Excel-Makro stammen kann, das von einem Nicht-Entwickler-Manager geschrieben wurde.

Sollte ein Entwickler unter solchen Umständen die Verantwortung übernehmen, die Tests in der berechneten Zeit zu schreiben und auszuführen?

Unter keinen Umständen sollte eine Schätzung blind akzeptiert werden. Keine Schätzung ist jemals perfekt, unabhängig davon, wie sie generiert wird. Es ist Aufgabe des Ingenieurs, alle Schätzungen zu überprüfen, potenzielle Probleme zu identifizieren, deren Auswirkungen zu bewerten und die Schätzung nach Bedarf zu diskutieren und zu verfeinern.

Sind die Ergebnisse dieser Tests vertrauenswürdig?

Tests sind nur so gut wie der Aufwand, sie zu entwerfen und umzusetzen. Wenn ein Tester minderwertige Tests durchführt, rutschen die Fehler durch die Tests und gelangen in eine spätere Phase des Projekts. Es liegt auf der Hand, dass der Zeitplandruck zu Tests mit geringer Qualität führen wird. Wenn die Zeit also nicht ausreicht, um die entsprechenden Testfälle zu entwerfen und diese dann zu implementieren, wären die Tests nicht so nützlich.

— Thomas Owens
quelle

3

Klingt so, als würden Sie zwei verschiedene Fragen stellen:

Sind die Ergebnisse dieser Tests vertrauenswürdig?

Excel ist ein Tool wie jedes andere, mit dem wir arbeiten, und was in den Berechnungen geschrieben wurde, sollte eigentlich keinen Einfluss auf die Ergebnisse des Algorithmus selbst haben. Die Tatsache, dass die Schätzung von einem Excel-Makro stammt, spielt keine Rolle, ob die Ergebnisse der Berechnung (dh die Gültigkeit der Schätzung) gültig sind oder nicht. Wenn Sie im zugrunde liegenden Modell falsche Annahmen haben, spielt es keine Rolle, was Sie für die Berechnung verwenden, da die zugrunde liegenden Annahmen falsch sind.

Sollte ein Entwickler unter solchen Umständen die Verantwortung übernehmen, die Tests in der berechneten Zeit zu schreiben und auszuführen?

Wenn die Forderung, dass der Entwickler die Arbeit in der angegebenen Zeit erledigt, in ihrem Kontakt steht, können sie nicht viel dagegen tun, solange die Schätzungen angemessen sind. Was zum nächsten Punkt führt: Wenn die Berechnungen einen angemessenen Zeitraum angeben und den Schätzungen entsprechen, die sich der Entwickler selbst geben würde, besteht kein Grund, keine Einwände gegen die angegebenen Fristen zu erheben. Tatsächlich könnte dies für die Entwickler von Vorteil sein, da sie möglicherweise die im Modul verwendeten Annahmen beeinflussen können, im Gegensatz dazu, wenn ihnen eine willkürliche Zeitachse zugewiesen wird.

Wenn die Zeitpläne für den erforderlichen Arbeitsaufwand undurchführbar erscheinen, sollten sie dieses Problem offensichtlich ansprechen und versuchen, mit dem Manager zusammenzuarbeiten, um realistischere Zeitpläne zu erhalten. Wenn die Zeitpläne jedoch durchführbar sind, werden sie Schwierigkeiten haben, Einwände dagegen zu erheben.

In Bezug auf das Projektmanagement und die Schätzung von Zeitplänen ist dies zwar möglich, hängt jedoch in hohem Maße von der Art der ausgeführten Arbeit ab. Sie werden wahrscheinlich genauere Schätzungen für die zum Schreiben von Unit-Test-Code erforderliche Zeit sehen (vorausgesetzt, der Entwickler versteht das Framework und hat sie zuvor geschrieben) als für das Schreiben von neuem Code in Bezug auf die Anwendungsfälle, in denen der Test-Code geschrieben wird zum.

— rjzii
quelle

Ich bin damit einverstanden, dass diese Methode angewendet werden kann / könnte, solange ein Dialog zwischen den Akteuren des Projekts stattfindet.

— Nelstaar

1

@Nelstaar - Zu so ziemlich allem, was ich jemals über Projektmanagement und -schätzung gelesen habe, gehört ein laufender Dialog und die Abstimmung der Dinge im Laufe der Zeit. Mit den zuverlässigsten Schätzungen ist in der Regel eine Wahrscheinlichkeit in Bezug auf die Wahrscheinlichkeit verbunden, dass das angegebene Ziel erreicht wird (dh eine Wahrscheinlichkeit von 90%, dass die Aufgabe 8 Stunden dauert).

— rjzii

2

Ich möchte Schreibtests nicht herunterspielen, aber das Projekt hat wahrscheinlich schon mehrere Entwickler dazu veranlasst, sie zu schreiben. Wenn Schätzungen auf diesen Daten basieren, sind diese möglicherweise genauer als von Ihrem Freund angenommen. Da Ihr Freund das Projekt verlassen hat, keinen Versuch unternommen hat, gegenteilige Schätzungen zu erstellen oder zu prüfen, ob diese wie vorhergesagt abgeschlossen werden können, werden wir es nie erfahren.

Alles, was er tun musste, war ein oder zwei Tests abzuschließen, um festzustellen, wie genau die Schätzung war, und mit einer berechtigten Argumentation an den Manager zurückzukehren. Möglicherweise gibt es andere Teammitglieder, die Feedback zur Zuverlässigkeit der Schätzungen oder zu den Folgen eines Versäumnisses hätten geben können. Manchmal muss ein Manager seinem Chef etwas geben, um alle zufrieden zu stellen. Entwickler betrachten dies als falsches Sicherheitsgefühl. Wenn Entwickler veranlasst würden, Schätzungen vorzulegen und die Bereitschaft zu zeigen, Dinge zu erledigen, könnte das Management möglicherweise mehr Vertrauen entwickeln.

Ich vermute, wenn er die Tests in kürzerer Zeit abschließen könnte, würde er nichts dazu sagen. Andererseits kann die Entschuldigung einer Praxis, an die er nicht glaubt, auf ein hohes Maß an Integrität hindeuten.

— JeffO
quelle

+1 für Feedback während der Bearbeitung der Aufgaben in Bezug auf die Schätzungen.

— rjzii

1

Einfache und kurze Antwort:

Es ist dir egal, woher die Schätzung kommt.

Was Sie wirklich interessiert, ist die Schätzung selbst. Stimmen Sie dem zu oder stimmen Sie nicht zu und erklären Sie warum und wie viel Sie schätzen würden. Das ist das Wichtigste.

— Clement Herreman
quelle

1

Sie sollten sich darum kümmern, woher die Schätzung kommt. Ein parametrisches Modell mit gültigen und vernünftigen Eingaben, ein Zufallszahlengenerator, ein Informatikstudent im ersten Jahr, ein Softwareingenieur mit 5 Jahren Erfahrung mit weniger als 6 Monaten Erfahrung und ein Softwareingenieur, der zum Projektmanager mit 25 Jahren Erfahrung wurde in der Domäne haben alle eine unterschiedliche Fähigkeit, eine effektive Schätzung zu erstellen. Dies geht auch auf einen Kommentar zurück, den ich zu einer früheren Antwort über die ethische / berufliche Verantwortung eines Software-Ingenieurs abgegeben habe, Schätzungen angemessen darzustellen, zu verteidigen und herauszufordern.

— Thomas Owens

Genau: Das Wichtigste ist, die Schätzung zu diskutieren. Ich würde gerne Excel-Makros verwenden, wenn die vorgenommenen Schätzungen häufiger zutreffen als die eines 25-jährigen erfahrenen Ingenieurs. Was wichtig ist, ist die Einschätzung und die Erklärung, die dazu geführt hat (Arbeitsaufwand, verfügbare Ressourcen, Schwierigkeiten), nicht von wem oder was angekündigt wurde.

— Clement Herreman

Sie stimmen mir zu, dass Ihre Antwort falsch ist? Bei gleichen Inputs (wie Arbeitsbelastung, Ressourcen, Schwierigkeitsgrad usw.) ist das Wer genauso wichtig wie das Was und Warum. Es kommt auf einen Vertrauensfaktor an. Ich vertraue COCOMO (erstellt und gepflegt von einigen führenden Köpfen in der Softwarekostenschätzung) mehr als einem Excel-Makro (erstellt von jemandem mit begrenzten Erfahrungen und Kenntnissen in der Kostenschätzung, geschweige denn der Anwendungsdomäne). Es dreht sich alles um das Ganze, um festzustellen, wie vertrauenswürdig diese Schätzung ist.

— Thomas Owens

Nein, nein, ich glaube, ich bin nicht klar genug. Es ist wirklich nicht wichtig, wer die Schätzung vorgenommen hat. Wichtig ist die Genauigkeit der Schätzung. Wenn ich eine Schätzung erhalte, vergleiche ich sie mit meiner Schätzung und diskutiere sie dann mit meinem Projektmanager, ob ich damit einverstanden bin oder nicht. Wenn ihre Argumentation gut genug ist, stimme ich ihnen zu und akzeptiere die Schätzung. Sehen? Ich habe nie darüber gesprochen oder darüber nachgedacht, wer geschätzt hat.

— Clement Herreman

Wie bestimmen Sie die Genauigkeit, wenn Sie nicht wissen, wer geschätzt hat und welche Methoden sie verwendet haben? Ich könnte die gleichen Daten an zwei Personen weitergeben: Die eine ist ein Student der Softwaretechnik im ersten Jahr, der gerade an seinem ersten Informatikkurs teilnimmt, und die andere ist ein leitender Softwaretechniker mit 15 Jahren Erfahrung und 5 in diesem Bereich. Beide verwenden die gleichen Schätzmethoden (nicht vergessen - häufig sind Eingaben auch Schätzungen). Der Student kann sagen, dass es 6 Monate dauern wird, mit einem 95% igen Vertrauen. Der leitende Ingenieur kann sagen, dass es mit 80% igem Vertrauen 15 Monate dauern wird. Ich würde dem leitenden Ingenieur mehr vertrauen.

— Thomas Owens

1

Theoretisch sollte ein Entwickler niemals eine Schätzung akzeptieren, die von einer anderen Person erstellt wurde, unabhängig davon, wie sie erstellt wurde. Ein Grund dafür ist, dass bei einer längeren Schätzung, mit der Ihr Manager vertraut ist, sofort ein potenzielles Zeitplanproblem oder möglicherweise ein Missverständnis über den Umfang der auszuführenden Arbeiten aufgedeckt wird.

In der Regel ist die Schätzung der Programmierzeit noch schwieriger als die Programmierung selbst. Wenn Ihr Manager also ein Excel-Makro schreiben kann, kann dies behoben werden erstellen dieses Problem zu , kann er wahrscheinlich ein Makro zum Schreiben des Codes erstellen (unwahrscheinlich).

Wenn Sie nun in der Praxis die Arbeit verstehen und die Schätzungen als vernünftig erachten, ist es sinnvoll, im Nachhinein einige Bedenken hinsichtlich der Methodik auszudrücken und dann vorläufig zuzustimmen, ob Sie diese erfüllen können. Später, wenn die Arbeit länger dauert als erwartet, sollten Sie Ihre Vorgesetzten zum frühestmöglichen Zeitpunkt darauf aufmerksam machen. Bereiten Sie sich darauf vor, die genauen Gründe auf der Grundlage Ihrer tatsächlichen Implementierungserfahrung zu besprechen. Hoffentlich ist Ihr Manager zu diesem Zeitpunkt nicht unvernünftig und besteht weiterhin darauf, dass Sie an mechanisch erstellten Schätzungen arbeiten.

— PeterAllenWebb
quelle

-1

Eine der neuesten Methoden zur Softwareentwicklung ist agil , und eines der bekannten agilen Frameworks ist agil Scrum . Bei dieser Methode müssen Entwickler (Scrum-Team) jedoch die erforderliche Zeit berechnen, um eine Aufgabe zu erledigen oder eine User Story zu implementieren.

Sage ich definitiv NEIN . Weil:

Ein Manager, der kein Entwickler ist, kann die erforderliche Zeit für die Ausführung eines Auftrags nicht abschätzen
Das Abschätzen der für die Erledigung einer Aufgabe erforderlichen Zeit erfordert menschliche Intelligenz, über die Excel nicht verfügt
Indem Manager solche Arbeitspraktiken akzeptieren, gewöhnen sie sich zunehmend daran, Entwickler in abschätzenden Zeiten zu ersetzen. Dies kann zu einer Katastrophe führen. Stellen Sie sich dieses Szenario vor, in dem Ihr Manager Folgendes sagt:

Ich möchte ein neues Projekt für den Online-Verkauf von Fahrrädern starten und ich weiß, dass Sie und John 3 Wochen brauchen, um dies zu erreichen.

— Saeed Neamati
quelle

5

Das OP erwähnt das Team seines Freundes nicht, das agile Methoden einsetzt. Ich denke nicht, dass agile Regeln für Teams relevant sind, die andere (oder gar keine) Methoden anwenden. Der gesunde Menschenverstand sollte jedoch :-) Darüber hinaus ist es offensichtlich, dass nicht Excel über die Schätzungen entschied, sondern nur einige Berechnungen basierend auf einigen (uns unbekannten) Annahmen und Daten (von denen jede richtig oder falsch sein kann) durchführte. . Wenn ich Schätzungen für eine bestimmte Aufgabe von jedem unserer Teammitglieder eingebe, dann setze Excel, um den Durchschnitt dieser zu berechnen. Macht Excel die Schätzung?

— Péter Török

3

1 und 2 sind offensichtlich falsch. Parametrische Schätzmodelle sind im Software-Projektmanagement weit verbreitet und bestehen seit weit über 20 Jahren. Jeder mit Projektmanagement-Ausbildung (Software-Ingenieur oder nicht) kann für die Verwendung dieser Tools geschult werden, vorausgesetzt, sie (oder vorzugsweise die Projektingenieure) ) sind in der Lage, genaue Schätzungen der Eingaben zu liefern.

— Thomas Owens

3

-1 - Dies beantwortet die Frage nicht, weist offensichtliche Fehler auf ("... neueste Softwareentwicklungsmethoden sind agil") und scheint nichts Relevantes hinzuzufügen. Ich bin mir nicht sicher, wofür die Upvotes oder die akzeptierte Antwort waren.

— Morgan Herlocker

1

Wir wissen aus der Frage nicht, ob parametrische Schätzungen die Norm in diesem Unternehmen sind und / oder ob sie auf einer guten Unternehmensgeschichte beruhen. Wenn dies der Fall ist, ist es unklug, sich zu weigern, seine Arbeit in Übereinstimmung mit den von der Organisation akzeptierten Betriebsverfahren zu verrichten (ohne einen vernünftigen Weg der Befragung zu verfolgen).

— StevenV

2

@Thomas Ich stimme zu, ich denke nur, es gibt zu viel, was wir nicht über die Situation wissen, um kategorisch mit Ja oder Nein zu antworten. Auf jeden Fall ist eine pauschale Ablehnung ohne eine gute Diskussion, um sicherzustellen, dass die Situation und die Argumentation verstanden werden, selten ein Problem Guter Karriereschritt.

— StevenV