So schätzen Sie eine Programmieraufgabe, wenn Sie keine Erfahrung damit haben [geschlossen]

Ich habe Schwierigkeiten mit dem Management, nach Schätzungen für Programmieraufgaben zu fragen, bei denen Steuerelemente von Drittanbietern verwendet werden, mit denen ich noch keine Erfahrung habe.

Ich verstehe definitiv, warum sie die Schätzungen wollen würden, aber ich habe das Gefühl, dass jede Schätzung, die ich gebe, entweder a) zu kurz ist und mich schlecht aussehen lässt oder b) zu lang und mich schlecht aussehen lässt.

Welche Schätzung oder Antwort könnte ich dem Management geben, um sie von meinem Rücken zu nehmen, damit ich meine Arbeit fortsetzen kann!

Die beste Antwort, die Sie geben können, besteht darin, nach Zeit zu fragen, um einen schnellen Prototyp zu erstellen, damit Sie eine genauere Schätzung abgeben können. Ohne einige Erfahrung mit einem Werkzeug oder ein Problem, jede Schätzung Sie geben , ist im Wesentlichen bedeutungslos.

Abgesehen davon gibt es sehr selten ein Problem damit, eine zu lange Schätzung abzugeben. Unerwartete Probleme treten auf, Prioritäten ändern sich und Anforderungen werden "aktualisiert". Selbst wenn Sie nicht die von Ihnen gewünschte Zeit verwenden, haben Sie mehr Testzeit oder können "früh" veröffentlichen.

Ich war in meinen Schätzungen immer viel zu optimistisch, und es kann viel Stress in Ihr Leben bringen, besonders wenn Sie ein junger Programmierer sind, der nicht die Erfahrung und das Selbstvertrauen hat, den Chefs unangenehme Wahrheiten zu sagen.

Ich werde dich in ein Geheimnis einweihen. Selbst wenn Sie ein Experte mit dieser Technologie wären, ist Ihre Schätzung wahrscheinlich sehr ungenau. Es liegt in der Natur des Tieres, etwas zu tun, das von Natur aus eine F & E-Aufgabe ist. Leider versucht das Management häufig, ein Fertigungsmodell anzuwenden und genaue Schätzungen zu verlangen. Betrachten Sie zur Veranschaulichung meines Standpunkts die Schwierigkeit, die folgenden zwei Bemühungen genau abzuschätzen:

A) Stellen Sie weitere 11K-Regenschirme her, die genau den 2K-Regenschirmen entsprechen, die Sie im letzten Monat hergestellt haben. B) Entwerfen Sie eine neue Art von Regenschirm und bauen Sie den ersten.

Softwareentwicklung ist B, aber sie fragen nach einer Schätzung unter der Annahme von A.

Das Beste, was Sie tun können, ist, die Aufgabe in möglichst kleine Teile zu zerlegen (jeweils nicht mehr als einen halben Tag) und dann die endgültige Zahl zu verdreifachen, die Sie sich ausgedacht haben. (Spolsky-Methode)

Alternativ hat Steve McConnell ein ganzes Buch (wohl mehrere) zu diesem Aspekt der Softwareentwicklung. http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351

Steve McConnell (und andere) sprechen über den Kegel der Unsicherheit . Grundsätzlich geben Sie eine Schätzung an, die ungefähr so ​​aussieht:

Die Arbeit wird zwischen 3 und 9 Wochen dauern, wobei 4 Wochen am wahrscheinlichsten sind.

Im Verlauf des Projekts können Sie Ihre Schätzung verfeinern. Wenn Sie mehr arbeiten und den erforderlichen Aufwand besser verstehen, können Sie Ihre Schätzung genauer verfeinern.

Es hat bei mir funktioniert, aber es kann einige Anstrengungen erfordern, um andere Stakeholder im Projekt dazu zu bringen, den Prozess zu verstehen.

Vielleicht möchten Sie sowohl eine Schätzung als auch ein Konfidenzniveau angeben, dh es ist 50/50, dass es 3-6 Monate oder 6-9 Monate dauert, oder eine 75% ige Chance, in 9 Monaten fertig zu sein, und 90%, dass Sie es sein werden in einem Jahr fertig.

Eine andere Sache, die Sie vielleicht in Betracht ziehen sollten, ist die Verwendung des Ansatzes " Weisheit der Menge ". Gehen Sie herum und fragen Sie 25-50 Personen, wie lange sie glauben, dass es dauern wird, und mitteln Sie ihre Schätzungen. Mike Cohns Planning Poker ist dem sehr ähnlich, obwohl es schwierig ist, es mit nur einem Entwickler zu planen.

Teilen Sie Ihre Schätzung auf in:

• Bekannte bekannte ; Wie lange wird es dauern, das zu tun, was Sie wissen? Sie sollten in der Lage sein, diese Schätzung mit einem hohen Maß an Sicherheit abzugeben.
• Bekannte Unbekannte ; Wie lange wird es wohl dauern, bis Sie das tun, was Sie nicht wissen? Sie können eine Methode wie die von Dacracot verwenden, um ein unterschiedliches Maß an Vertrauen in diese Schätzung zu erhalten.
• Unbekannte Unbekannte ; Dies ist das Schwarze Loch in Echtzeit. Dies sind die Dinge, die sich zu den ungünstigsten Zeiten aufrichten und dich in den Arsch beißen. Geben Sie einen Bereich für die Schätzung mit Begründung an, der auf den von Ihnen erwarteten Risiken basiert.

Bieten Sie an, die Schätzung und bestimmte Meilensteine ​​auf dem Weg anzupassen. Alle unbekannten Unbekannten werden zu bekannten Unbekannten, die bekannten Unbekannten sollten zu bekannten Bekannten werden, wenn Sie Erfahrung sammeln, und die Schätzung Ihrer bekannten Bekannten kann basierend auf dem bisherigen Fortschritt angepasst werden. Sie können eine erste Schätzung vornehmen und dann erneut schätzen, wenn Sie ungefähr 25% fertig sind, dann wieder bei 50%, dann wieder bei 85%. Bei jedem Meilenstein sollte Ihre Schätzung auf die tatsächliche Zeit konvergieren, die die Aufgaben benötigen.

Ich verwende für meine Schätzungen ein bestimmtes Kennzeichnungssystem ... Klasse A, Klasse B und Klasse C.

Die Schätzung der Klasse C ist die erste, die sie erhalten. Es wird offen als plus oder minus 50% aufgrund von Unbekannten angegeben. Wenn sie wollen, dass ich ihnen weiterhin eine Klasse B gebe, dann brauche ich Geld für die Forschung.

Die Klasse B beträgt plus oder minus 25%. Manchmal ist das gut genug und sie geben mir das Geld zum Bauen. Wenn nicht, weniger Geld und mehr Forschung.

Die Klasse A ist plus oder minus 10%, das Finale und Go oder No Go. Wenn es ein Versuch ist und ich zu weit von der Schätzung entfernt bin, gestehe ich oft und früh.

Ich denke, wenn Sie den Ausdruck "die Steuerelemente von Drittanbietern verwenden, mit denen ich noch keine Erfahrung habe" entfernen, haben Sie möglicherweise eine bessere Beschreibung Ihres größeren Problems.

Wenn "Agile" uns etwas beigebracht hat, ist es so, dass, wenn das Management erwartet, dass Sie Projekte auf diese Weise fortlaufend schätzen, Sie "schlecht aussehen", wenn Sie sagen, dass es nicht bereitgestellt werden kann, weil Sie es nicht haben Genug Informationen, Sie sind auf der Autobahn nach FAIL.

Das größte Problem werden die Probleme sein, über die Sie keine Kontrolle haben und die Sie noch nicht einmal identifiziert haben. Wie oft haben Sie zurückgeschaut und sich gesagt: "Nun, ich habe meine Schätzung direkt auf den Knopf gedrückt - beim dritten Versuch, nachdem ich herausgefunden hatte, dass ... und dass ich eine Version brauchte ... und dass die dba eingeschaltet sein würde Urlaub für eine Woche und dass der Projektmanager mich für ... für eine Woche brauchen würde und dass meine Frau schwanger war und ... ".

Ich würde mich sehr bemühen zu sagen: "Ich kann die kritischen Risikofaktoren identifizieren und eine Checkliste mit Ergebnissen erstellen, um sie in xx Tagen zu testen. An diesem Punkt werde ich Ihnen eine weitere inkrementelle Schätzung geben."

Und es wäre wirklich schön, wenn Sie vorschlagen könnten, dass sie "Bitte bestehen Sie darauf, dass ich nie versuche, Ihnen in Zukunft eine glaubwürdige Schätzung dieses Typs zu geben. Entlassen Sie mich, wenn ich es versuche."

(Überbewertet, aber nur geringfügig.)

Versuchen Sie nicht einmal zu schätzen. Ihre Schätzung ist auf keinen Fall korrekt. Es ist immerhin nur eine Schätzung.

Ich würde stattdessen empfehlen, dass Sie die Funktion in kleine Teile aufteilen (nicht mehr als 1-2 Tage) und versuchen, diese Teile als funktionierenden, vollständigen, testbaren und wertvollen Code an den Kunden / Manager zu liefern. Auf diese Weise kann er sich täglich von Ihren Fortschritten überzeugen. Dies bedeutet auch, dass er tatsächlich entscheiden kann, die Entwicklung zu stoppen, sobald sie zufrieden ist, und sie als abgeschlossen zu betrachten, obwohl sie möglicherweise nicht alle Ziele erreicht hat.

Weitere Informationen zu diesem Ansatz finden Sie in den agilen Methoden "Release Planning" und "Iteration Planning".

Denken Sie daran, wenn Sie nach einer größeren Zeitschätzung fragen, diese aber im Laufe der Zeit vornehmen, sieht sie viel besser aus als wenn Sie eine Schätzung schätzen und eine Verlängerung beantragen müssen.

Ich würde versuchen, einen Prototyp zu verspotten, damit Sie eine bessere Vorstellung davon haben, wie lange es dauern wird. Seien Sie ehrlich zu Ihrem Management, damit es unerwartete Verzögerungen in der Lernkurve einplanen kann.

BEARBEITEN: Möglicherweise sehen Sie auch, ob Sie eine "iterativere" Frist erhalten können. In "Pragmatisches Denken und Lernen" betont Andy Hunt, dass Menschen Projektexperten sind, die näher am Ende des Projekts stehen und am Anfang am wenigsten über Kenntnisse verfügen. Es macht nicht viel Sinn, alle Ihre Entwurfs- und Zeitschätzungen zu Beginn durchzuführen, wenn alle am wenigsten über das Projekt Bescheid wissen. Wenn Sie die Fristen "iterieren" und das Problem in Stücken lösen, werden Sie mehr Erfolg haben.

Eine Menge genauer Schätzung ist Selbsterkenntnis. Wenn Sie viel Code geschrieben haben, wenn Sie viele APIs lernen mussten, bekommen Sie ein Gefühl für Fragen wie:

• Wie lange brauche ich, um eine neue API zu lernen?
• Wie lange brauche ich, um eine neue Sprache zu lernen?
• Wie lange brauche ich, um ein neues Toolset (Compiler / Linker / IDE) zu lernen?
• Wie lange brauche ich, um eine typische Aufgabe zu implementieren?
• Wie lange brauche ich, um meine Arbeit zu testen?
• Wie lange brauche ich, um meine Arbeit bereitzustellen?

Währenddessen sollten Sie sich ein Bild von folgenden Dingen machen:

• Wie viele typische Fehler erstellen Sie und wie werden sie kategorisiert (dh einfach, schwer, unmöglich)?
• Wie viele Komplikationen treten auf (dh müssen aufgrund fehlender API von Drittanbietern oder fehlerhafter API umgestaltet werden; müssen aufgrund von Missverständnissen der Funktionen neu gestaltet werden; nicht standardmäßige Tools / Build-Prozesse)
• Wie viel Zeit geht aufgrund von Unterbrechungen / externen Problemen verloren?

Basierend auf all diesen Dingen können Sie ein Gefühl dafür entwickeln, wie lange etwas dauern wird, und Ihre Annahmen ("Vorausgesetzt, die API ist vernünftig ...") auch angesichts kläglich unvollständiger Informationen angeben.

Schätzen Sie, wie lange Sie brauchen, um genug zu lernen, um eine bessere Schätzung vorzunehmen, zum Beispiel: "Ich weiß nicht: Ich habe noch nie damit gearbeitet. Ich werde wahrscheinlich Ihre Schätzung hier einfügen , um herauszufinden, was Sie müssen etwas darüber lernen, was ich wissen muss, bevor ich Ihnen einen guten Kostenvoranschlag für die Fertigstellung Ihres Projekts geben kann . "

Beim Programmieren habe ich immer das genommen, was ich wirklich dachte, und das mit 3 multipliziert, um eine Schätzung zu erhalten. Wenn ich denke, dass ich in 1 Woche einen Job machen kann, sage ich dem Kunden, dass es 3 dauert - wenn ich denke, dass ich wirklich 3 Wochen brauche, sage ich dem Kunden 9 Wochen.

Auf diese Weise stelle ich mich auf "unter Versprechen, überliefern" ein - wenn Sie dies erfolgreich tun können, wird Ihr Leben viel besser und Ihre Kunden werden äußerst glücklich sein.

In Ihrem Fall möchten Sie sicherlich zumindest EINIGES Verständnis dafür bekommen, worauf Sie sich einlassen, bevor Sie eine Schätzung abgeben. Möglicherweise müssen Sie sogar eine Schätzung abgeben, wie lange es dauern wird, bis eine Schätzung vorliegt. Mit 3 multiplizieren macht die Kunden zufrieden.

Teilen Sie es in Dinge auf, mit denen Sie Erfahrung haben. Wenn Sie es zerhacken, erhalten Sie eine bessere Vorstellung davon, was Sie wissen und was Sie nicht wissen.

Sobald die Teile klein genug sind, um als einzelne definierte Aufgaben angesehen zu werden, sind einige von ihnen völlig unvorhersehbar. Für diese, entweder zuerst Prototyp oder lassen Sie sich nur eine angemessene Zeit, abhängig von der Größe des Stücks. Wenn Sie feststellen, dass Sie unschätzbare Teile haben, die länger als 2 bis 4 Wochen dauern, zerkleinern Sie sie zuerst.

Irgendwann werden Sie einige sehr seltsame technologische Lösungen finden (von denen Sie denken, dass sie funktionieren sollten, aber nicht sicher wissen), und eine Menge Arbeit, die getan werden muss, um dieses Zeug zu sichern, sobald es funktioniert. Es wird ein paar Teile des fehlenden Designs geben, für die es am besten ist, eine bekannte Bibliothek oder einen sehr einfachen Algorithmus für die ursprüngliche Version auszuwählen.

Wenn Sie die Aufgaben nicht aufschlüsseln können, sollten Sie jemanden mit ausreichender Erfahrung einstellen, der dies kann (da Ihr Mangel an Erfahrung Sie auch auf andere Weise verfolgen wird). Wenn Sie niemanden einstellen können, sollten Sie nur für einen zufällig langen Zeitraum (6 Monate bis 2 Jahre) verhandeln und direkt in einen chaotischen Prototyp einsteigen (bis Sie es geschafft haben, sich genug Erfahrung zu verschaffen, um zu wissen, was richtig ist und was falsch). Aber wenn Sie am Ende damit herumwirbeln, ist es wichtig, sich nicht zu täuschen und zu denken, dass Sie es richtig "machen". Prototypen sollten weggeworfen werden. Wenn der Prototyp-Countdown abgeschlossen ist, können Sie ihn hoffentlich real erstellen.

Paul.

Sie erraten nur eine externe Zahl und beginnen sofort mit der Auswertung. Lassen Sie sie wissen, dass zukünftige Informationen Ihre Schätzungen beeinflussen können, dass Sie sie jedoch auf dem neuesten Stand halten.

Halten Sie sie bei der Bewertung auf dem Laufenden - entweder durch ein im Internet veröffentlichtes Dokument oder durch wöchentliche Aktualisierungen, geben Sie jedoch immer ein aktualisiertes "geschätztes Enddatum" und gegebenenfalls Gründe für Erweiterungen an.

Die meisten Manager sollten das verstehen - wenn sie nach Enddaten fragen, sagen sie wirklich: "Geben Sie uns eine Vorstellung davon, wie wir unseren Zeitplan planen können" und "Nehmen Sie nicht einfach ewig".

Wenn Sie am Ende mehr als ein- oder zweimal verlängern, bewerten Sie Ihren gesamten Zeitplan neu, basierend auf Ihrem neuen Wissen, das Sie beim Schätzen scheuen.

Ich würde zu dem, was RB gesagt hat, hinzufügen, wenn ich mich in dieser Situation befinde, schätze ich, wie lange es mit den mir vertrauten Werkzeugen dauern würde, und verdopple dann diese Schätzung, um eine Lernkurve aufzubauen.

Der wichtige Teil ist an das Management kommuniziert , dass die Schätzung a guess , wenn sie für eine genauere Schätzung drücken oder wenn sie versuchen, - lieber Gott - verkaufen Sie ein Zeitlimit (sicherlich wird es nur nehmen Sie 2 Tage , den Starship zu bauen Unternehmen, Sie sind gut, Sie sind) Halten Sie sich an Ihre Waffen , gefährden Sie nicht Ihre Schätzung oder die Tatsache, dass es unzuverlässig ist.

Wenn das Management Sie überschreibt und die Aufgabe mit der Zeitbox überschreibt, z. B. "Nun, es muss in 2 Tagen erledigt sein", teilen Sie ihnen erneut mit, dass dies ihre Schätzung ist, die genau so zuverlässig ist wie Ihre eigene.

Schreiben Sie das alles schriftlich auf.

Ich beschäftige mich in meinem Job ziemlich viel mit Einschätzung und es ist eine echte Herausforderung. Eine meiner größten Herausforderungen besteht darin, abzuschätzen, wie lange ein anderer Entwickler benötigt, um eine Aufgabe zu erledigen, ohne zu wissen, wie gut dieser Entwickler sein wird.

Während Sie möglicherweise erste Erfolge mit der Methode "Unter Versprechen, Überlieferung" erzielen, werden Sie feststellen, dass Sie im Laufe der Zeit von anderen Personen überboten werden, die der Denkschule "Überversprechen, Unterlieferung" folgen. Mangelnde Genauigkeit wird Sie in beide Richtungen beißen. Die Genauigkeit hängt sehr stark vom Erleben und Begrenzen der Anzahl von Unbekannten mit der Technologie ab.

Eine Sache, die ich vorschlagen würde, ist eine Vorstellung davon zu bekommen, gegen welche Art von Budget Ihre Schätzung arbeiten wird. Wenn Sie ein kleines Budget haben, sollten Sie nicht mit ungewohnter Technologie verrückt werden und sich an das halten, was Sie wissen. Wenn Ihr Budget etwas flexibler ist, können Sie es sich leisten, ein wenig zu experimentieren.

Beachten Sie auch, dass es einige Aufgaben geben wird, bei denen Sie lediglich eine Wild Ass Guess (WAG) bereitstellen können. Für diese sollten Sie eine Mindestzeit für Ihre Schätzung festlegen und klarstellen, dass Sie nicht wissen, wie hoch die maximale Zeit ist. Oft ist diese Art der Schätzung Grund genug, bestimmte Funktionen / Anforderungen vom Management auszuschließen.

Das ist eine unverzichtbare Fähigkeit, die sowohl Projektmanager als auch Programmierer haben können (und natürlich beherrschen können!). Ich fand einen Artikel mit dem Titel " Schätzen von Softwareentwicklungsaufgaben, die (ein bisschen) einfacher gemacht wurden" , den ich für eine bessere Einschätzung der Projektaufgaben erwarten kann.

Alle oben genannten Antworten haben so ziemlich alles abgedeckt, was die Erstellung der Schätzung selbst betrifft.

Eine Sache, die ich hervorheben möchte, ist, Ihre Schätzung im Auge zu behalten (eine kleine Excel-Tabelle a la Joel oder sogar ein Notepad-Dokument, wenn es sehr einfach ist) und diese am Ende eines jeden Tages auf die genauesten Zahlen zu aktualisieren, die Sie jetzt bereitstellen können . Selbst wenn Sie dies nicht an Ihre Vorgesetzten zurückgeben müssen, erhalten Sie durch die Aktualisierung eine bessere Vorstellung davon, wie sich die Dinge entwickeln, und vor allem erhalten Sie ein gutes Gefühl dafür, warum sich Ihre Schätzung im Verlauf der Arbeit ändert .

Auf diese Weise können Sie in Zukunft besser einschätzen, sowohl für diese spezielle Technologie als auch für andere, die Sie zuvor noch nicht verwendet haben, einfach weil Sie auf einer bestimmten Ebene feststellen müssen, wann sich Ihre Erwartungen in regelmäßigen Abständen ändern, und herausfinden, warum dies passiert ist .

Die Einschätzung, wie lange etwas dauern wird, gehört zu Ihrem Job. Solange es sich eher um eine Schätzung als um eine Frist handelt, sollten Sie sich keine Sorgen machen müssen. Es gibt niemanden, der besser in der Lage ist, eine Schätzung abzugeben, als die Person, die den Code schreiben wird. Wenn Sie keine gute Schätzung abgeben können, müssen Sie das Management auf das mit Ihrer schlechten Schätzung verbundene Risiko aufmerksam machen, damit es erneut prüfen kann, ob es sich lohnt, das Risiko der Programmierung gegen diese unbekannten Kontrollen von Drittanbietern einzugehen.

Das ist eine sehr häufige Situation: die Notwendigkeit, mit dem Unbekannten umzugehen. Ein nützlicher Weg, um dies in Angriff zu nehmen, ist die Erkenntnis, dass Sie neben den eigentlichen Programmieraufgaben noch etwas zu lernen haben - und das Management sollte sich dessen bewusst sein.

Wenn Sie sich in einer solchen Situation befinden, wird das Projekt plötzlich zu einem F & E-Projekt, und eine längere Zeit als normal lässt Sie nicht schlecht aussehen, da Sie Programme lernen und produzieren. Ich weiß nicht, wie schnell Sie lernen oder welche Ressourcen Sie benötigen, um Probleme zu lösen (Stapelüberlauf ist eine der Optionen, die Sie haben).

Ich würde sagen, dass Sie wie gewohnt schätzen und dann entweder mit 1,5 multiplizieren sollten (wenn Sie schnell lernen und Zugang zu Ressourcen haben, um Ihre Fragen zu lösen) oder mit 2,5, wenn Sie ein durchschnittlicher Lernender sind und sich nur auf sich selbst verlassen.

Ich hoffe das hilft!

Versuchen Sie nach Kräften, die Aufgabe in überschaubare Teile aufzuteilen. Mit etwas Glück gibt es bestimmte Aufgaben, die sich auf die betreffende Komponente eines Drittanbieters beziehen, und andere, die weniger gekoppelt sind (und daher leichter abzuschätzen sind). Geben Sie dem Management die aufgeteilten Schätzungen und zeigen Sie auf, wo die unsichersten Schätzungen liegen.

Ich stimme voll und ganz dem zu, der vorgeschlagen hat, herumzuspielen und einige Prototypen zu erstellen. Legen Sie eine feste Zeitbox für die Prototyping-Aktivität fest. ("Ich brauche zuerst zwei Tage, um diesen Teil meiner Schätzung zu verbessern.")

Können Sie eine Reichweite angeben? 40-60 Stunden, so etwas?

Je kleiner die Aufgaben sind, desto schwieriger ist es. Wenn Sie sie gruppieren können, haben Sie einen etwas größeren "Slop", da sich die Fehler am Ende des Projekts ausgleichen können.

Schauen Sie sich jeden Bereich an, mit dem Sie Erfahrung haben, und verwenden Sie ihn als Leitfaden. "Das letzte Mal, als ich eine Funktion erstellen musste, die die Datenbank geändert hat, brauchte ich X". Viel Glück.