it-swarm-eu.dev

Wie kann ich reagieren, wenn Sie nach einem Kostenvoranschlag gefragt werden?

Wir als Programmierer werden ständig gefragt, wie lange es dauern wird.

Und Sie wissen, die Situation ist fast immer so:

  • Die Anforderungen sind unklar. Niemand hat alle Implikationen eingehend analysiert.
  • Die neue Funktion wird wahrscheinlich einige Annahmen brechen, die Sie in Ihrem Code getroffen haben, und Sie denken sofort an alle Dinge, die Sie möglicherweise umgestalten müssen.
  • Sie haben andere Aufgaben aus früheren Aufgaben zu erledigen und müssen einen Kostenvoranschlag erstellen, der diese anderen Arbeiten berücksichtigt.
  • Die Definition "erledigt" ist wahrscheinlich unklar: Wann wird sie durchgeführt? "Fertig" wie in der gerade abgeschlossenen Codierung oder "Fertig" wie in "Die Benutzer verwenden es"?
  • Egal wie bewusst Sie sich all dieser Dinge sind, manchmal lässt Sie Ihr "Programmierstolz" kürzere Zeiten geben/akzeptieren, als Sie ursprünglich angenommen haben. Besonders wenn Sie den Druck von Fristen und Managementerwartungen spüren.

Viele davon sind organisatorische oder kulturelle Probleme, die nicht einfach und leicht zu lösen sind. Letztendlich werden Sie jedoch nach einem Kostenvoranschlag gefragt und erwarten von Ihnen eine vernünftige Antwort. Es ist Teil Ihres Jobs. Man kann nicht einfach sagen: Ich weiß es nicht.

Infolgedessen gebe ich immer Schätzungen ab, die ich später nicht erfüllen kann. Es ist unzählige Male passiert und ich verspreche immer, dass es nicht wieder passieren wird. Aber es tut.

Was ist Ihr persönlicher Prozess für die Entscheidung und Abgabe eines Kostenvoranschlags? Welche Techniken haben Sie nützlich gefunden?

665
Sergio Acosta

Von Der pragmatische Programmierer: Vom Gesellen zum Meister :

Was zu sagen ist, wenn nach einer Schätzung gefragt wird

Sie sagen: "Ich melde mich bei Ihnen."

Sie erzielen fast immer bessere Ergebnisse, wenn Sie den Prozess verlangsamen und einige Zeit mit den in diesem Abschnitt beschriebenen Schritten verbringen. Schätzungen, die an der Kaffeemaschine abgegeben wurden, werden (wie der Kaffee) zurückkommen, um Sie zu verfolgen.

In diesem Abschnitt empfehlen die Autoren den folgenden Prozess:

  • Bestimmen Sie die Genauigkeit, die Sie benötigen. Basierend auf der Dauer können Sie die Schätzung mit unterschiedlicher Genauigkeit angeben. "5 bis 6 Monate" zu sagen ist anders als "150 Tage" zu sagen. Wenn Sie ein wenig in den 7. Monat schlüpfen, sind Sie immer noch ziemlich genau. Aber wenn Sie in den 180. oder 210. Tag schlüpfen, nicht so sehr.
  • Stellen Sie sicher, dass Sie verstehen, was gefragt wird. Bestimmen Sie den Umfang des Problems.
  • Modellieren Sie das System. Ein Modell kann ein mentales Modell, Diagramme oder vorhandene Datensätze sein. Zerlegen Sie dieses Modell und erstellen Sie Schätzungen aus den Komponenten. Weisen Sie jedem Wert Werte und Fehlerbereiche (+/-) zu.
  • Berechnen Sie die Schätzung basierend auf Ihrem Modell.
  • Verfolgen Sie Ihre Schätzungen. Notieren Sie Informationen zu dem von Ihnen geschätzten Problem, Ihrer Schätzung und den tatsächlichen Werten.
  • Andere Dinge, die in Ihre Schätzung einbezogen werden müssen, sind das Entwickeln und Dokumentieren von Anforderungen oder Änderungen an Anforderungsspezifikationen, das Erstellen oder Aktualisieren von Konstruktionsdokumenten und -spezifikationen, das Testen (Einheit, Integration und Akzeptanz), das Erstellen oder Aktualisieren von Benutzerhandbüchern oder READMEs mit den Änderungen. Wenn zwei oder mehr Personen zusammenarbeiten, entsteht ein zusätzlicher Kommunikationsaufwand (Telefonanrufe, E-Mails, Besprechungen) und das Zusammenführen des Quellcodes. Wenn es sich um eine lange Aufgabe handelt, berücksichtigen Sie bei der Auswahl eines Liefertermins andere Aufgaben, Freizeit (Feiertage, Urlaub, Krankheitszeiten), Besprechungen und andere Gemeinkosten.
395
Thomas Owens

Die Softwareschätzung ist die schwierigste Einzelaufgabe in der Softwareentwicklung - eine knappe Sekunde ist die Ermittlung von Anforderungen.

Es gibt viele Taktiken, um sie zu erstellen, die alle darauf basieren, zuerst gute Anforderungen zu erhalten. Aber wenn dein Rücken an der Wand steht und sie sich weigern, dir bessere Details zu geben, Fake It:

  1. Sehen Sie sich Ihre Anforderungen genau an.
  2. Treffen Sie Annahmen, um die Lücken zu füllen, basierend auf Ihrer besten Vermutung, was sie wollen
  3. Schreibe alle deine Annahmen auf
  4. Lassen Sie sie sich hinsetzen, lesen und Ihren Annahmen zustimmen (oder, wenn Sie Glück haben, sie dazu bringen, nachzugeben und Ihnen echte Anforderungen zu stellen).
  5. Jetzt haben Sie detaillierte Anforderungen, anhand derer Sie abschätzen können.

Es ist, als hätte meine Mutter als Kind gedroht: "Beeil dich und such dir ein paar Klamotten aus, oder ich suche sie für dich aus!"

172
Fishtoaster

Ich habe für einen Mann entwickelt, der sehr darauf bedacht war, genaue Schätzungen zu wollen. Wir haben uns für Folgendes entschieden, was sehr gut funktioniert hat:

  • Ich habe die ganze Zeit in Rechnung gestellt, die ich mit Schätzen verbracht habe. Es kam zu ungefähr 20-25% von dem, was ich in Rechnung stellte.
  • Ich habe die Aufgaben sehr detailliert untersucht. Kein Schießen aus der Hüfte. Ich ging in den Code und fand heraus, welche Zeilen geändert werden mussten, welche anderen Teile des Programms davon betroffen waren und wie viele Tests ich durchführen musste, um sicherzustellen, dass die Dinge noch funktionierten. Ich würde jedes Stück in Einheiten von 0,1 Stunden (6 Minuten) schätzen.
  • Ich schickte ihm meinen Kostenvoranschlag für jede Aufgabe zusammen mit dieser detaillierten Aufschlüsselung.

20-25% der Abrechnung klingt nach viel.

Aber er würde mich bitten, XYZ zu ändern, weil er dachte, es würde ungefähr 2 Stunden dauern. In einer Stunde detaillierter Schätzung würde ich feststellen, dass es 8,5 Stunden dauern würde. Also würde er entscheiden, ob es 8,5 Stunden Lohn wert war. Wenn nicht, dann sparte er 7,5 Stunden gegenüber dem, was es ihn gekostet hätte, wenn ich es ohne Schätzung getan hätte.

Und wenn er tat die 8,5 Stunden investieren wollte, war die Detailarbeit, die ich für die Schätzung gemacht habe, Arbeit, die ich sowieso hätte tun müssen.

Ich stellte fest, dass ich mit dieser Methode die meisten Aufgaben pünktlich oder sogar früh erledigen konnte, ohne sie stark überschätzen zu müssen. Weil die Zeit so klein war, konnte ich früh erkennen, ob ich ausrutschte. Wenn ich auf Straßensperren stoße, damit ich nach 3 Stunden feststellen kann, dass meine 8,5-Stunden-Aufgabe 12 Stunden dauern wird, kann ich mit ihm darüber sprechen, bevor mehr Zeit vergeht, damit er die Funktion neu bewerten und herausziehen kann, wenn er über die Kosten besorgt ist .

War er Nickel und dunkel? Nein, ich sah es so an, als würde er sein Geld dort einsetzen, wo er den größten Nutzen sah. Und ich war froh, Erfahrungen mit Schätzungen zu sammeln, bei denen ich immer schrecklich gewesen war.

145
Kyralessa

Wir werden oft um eine "Schätzung des Baseballstadions" bei Besprechungen gebeten, bei denen wir sehr umfassende und genaue Vorstellungen davon erhalten, was sie tun möchten. Ich sage immer: "Wenn Sie heute eine Antwort wünschen, sind es ein Jahr und eine Million Dollar. Wenn Sie mir viel mehr Details und etwas Zeit geben möchten, um sie zu überprüfen, kann ich diese Zahlen für Sie verfeinern."

Sie verstehen fast immer den Punkt.

65
Walter

Dies hängt davon ab, wofür die Schätzung gilt.

Für eine erste Schätzung auf hoher Ebene für einen Geschäftsfall sind die wichtigsten Dinge:

  1. Geschwindigkeit. Welche Methode Sie auch verwenden, sie muss schnell sein. Der springende Punkt ist, dass die Stakeholder nicht sicher sind, ob es sich überhaupt lohnt, das Projekt durchzuführen - weshalb sie die Zahlen für den Business Case benötigen. Wenn der Business Case solide wäre, würden sie Ihre Schätzungen nicht benötigen. Der Großteil dieser Projekte wird nicht durchgeführt, daher ist es wichtig, dass nicht zu viel Aufwand für die Bereitstellung der Schätzung aufgewendet wird.
  2. Geben Sie einen Bereich an. Mach es breit. Sie hatten keine Zeit, Anforderungen zu analysieren, Workshops mit Stakeholdern durchzuführen und Annahmen zu validieren. Ein breites Spektrum sagt dem Empfänger der Schätzung: "Softwareprojekte sind von Natur aus komplex und riskant. Wenn Sie eine ordnungsgemäße Schätzung wünschen, müssen Sie mir mehr Details und mehr Zeit geben." Das Problem bei der Angabe einer einzelnen Zahl oder eines engen Bereichs besteht darin, dass Sie in eine Ecke geraten, indem Sie Erwartungen festlegen, bevor eine echte Analyse durchgeführt wird.

Ich finde die beste Technik, um ein vergleichbares Projekt auszuwählen, das sich genauso "anfühlt". "Feel" ist völlig subjektiv - aber mit dieser Art von Schätzung sagt mir meine Erfahrung, dass Sie keine objektiven Messungen finden werden. Dann bieten Sie eine große Auswahl. Ich habe einige Bücher gelesen, die sagen, dass ein Bereich von -50% bis + 100% gut ist, aber es hängt von vielen Faktoren ab.

Für eine detaillierte Schätzung auf niedriger Ebene:

  1. Sie benötigen eine Grundlinie. Wenn die Basislinie nicht stabil ist, ist die Schätzung bedeutungslos.
  2. Bottom up ist am besten. Holen Sie sich eine detaillierte Arbeitsaufschlüsselung, schätzen Sie jede Komponente und rollen Sie sie dann zu einer größeren Anzahl zusammen. Ich finde, dass das Planen von Poker hier eine großartige Technik ist.
  3. Kontingenz dokumentieren. Stellen Sie klar, wo Eventualverbindlichkeiten (falls vorhanden) hinzugefügt werden. Wird es jeder Werbebuchung hinzugefügt? Oder zur ganzen Schätzung? Oder auf bestimmte Risiken? Oder gibt es keine?
  4. Geben Sie Ihre Annahmen an. Validieren Sie so viele wie möglich im Zeitrahmen.
  5. Geben Sie explizit an, was in der Schätzung enthalten und ausgeschlossen ist. Ist beispielsweise eine Überprüfung enthalten? Sind technische Verzögerungen enthalten?
55
darreljnz

Einige Ratschläge von der dunklen Seite von jemandem, der auf die harte Tour gelernt hat.

Die Anforderungen sind unklar. Niemand hat alle Implikationen eingehend analysiert.

Machen Sie an dieser Stelle keine Schätzung. Man schätzt nicht, wie viele Soldaten benötigt werden, um eine Schlacht zu gewinnen, ohne eine Ahnung von den feindlichen Zahlen zu haben. Die Schätzung erfolgt nach dem Scouting. Es sei denn, Sie haben diesen Feind bereits bekämpft.

Die neue Funktion wird wahrscheinlich einige Annahmen brechen, die Sie in Ihrem Code getroffen haben, und Sie denken sofort an alle Dinge, die Sie möglicherweise umgestalten müssen.

Es liegt in Ihrer Verantwortung, dies zu berücksichtigen, es sei denn, Sie erwarten, dass andere über das Fachwissen in diesem Bereich verfügen.

Sie haben andere Aufgaben aus früheren Aufgaben zu erledigen und müssen einen Kostenvoranschlag erstellen, der diese anderen Arbeiten berücksichtigt.

Das Gleiche gilt wie oben, auch für unerwartete Arbeiten, die von einem Slob-Teamkollegen neben Ihnen mit einem nahezu nicht vorhandenen Testverfahren erstellt wurden, bei dem Ihr Code fehlerhaft wird, was Sie nicht im Voraus perfekt vorhersagen können. Es ist eine Wettervorhersage.

Die Definition "erledigt" ist wahrscheinlich unklar: Wann wird sie durchgeführt? "Fertig" wie in der gerade abgeschlossenen Codierung oder "Fertig" wie in "Die Benutzer verwenden es"?

Verstehen Sie die Benutzeranforderungen hier und denken Sie wie ein Benutzer. Tun Sie nicht das, was Ihre Kollegen tun, wenn sie schätzen, dass etwas "erledigt" werden soll, nur weil einige grundlegende Funktionen mit einem Barebone-Workflow, die kein Benutzer möglicherweise tolerieren kann, das sind, was sie als "erledigt" betrachten. Betrachten Sie es vom Standpunkt des Benutzers aus, denn das ist alles, was der Kunde, für den Sie die Schätzung vornehmen, normalerweise versteht. Schätzen Sie auf die vollständigen Anforderungen des Benutzers und nicht auf die technischen Anforderungen des Barebones. Und stellen Sie fest, dass Ihre Kunden, die nach Schätzungen fragen, hier völlig ungenau sind, wie sie Dinge formulieren und die technischen Aspekte Ihrer Aussagen verstehen.

Egal wie bewusst Sie sich all dieser Dinge sind, manchmal lässt Sie Ihr "Programmierstolz" kürzere Zeiten geben/akzeptieren, als Sie ursprünglich angenommen haben. Besonders wenn Sie den Druck von Fristen und Managementerwartungen spüren.

Tu das nicht! Sie klingen wie ein selbstmotivierter harter Arbeiter und möglicherweise einer, der leicht dem Zwang nachgibt.

Das Problem hierbei ist folgendes: Nehmen wir an, Sie und Joe haben Zeitschätzungen für dieselbe Aufgabe vorgenommen (jedoch zwischen zwei getrennten Mitarbeitern, die beide Schätzungen nicht gleichzeitig kennen). Sie schätzen tapfer, "eine Woche". Es ist in Ordnung, wenn Sie denken, Sie werden mehr als 100 Stunden pro Woche arbeiten, unbezahlte Überstunden. Jetzt bist du drei Tage zu spät.

Inzwischen schätzt Joe 5 Monate. Du denkst, das ist lächerlich, du denkst, du kannst das in einer Woche schaffen. Wie viel arbeitet Joe? 10 Stunden pro Woche? ... außer dass er in genau 5 Monaten pünktlich fertig ist.

Ratet mal, wer als Esel wahrgenommen wird? Das stimmt, du. Joe scheint ein großartiger Arbeiter zu sein, Sie scheinen jetzt unzuverlässig zu sein. Es ist nicht so wichtig, dass Sie in ~ 7% der Zeit, die Joe benötigt hat, ein noch besseres Ergebnis erzielt haben. Was zählt, ist, dass Sie nach einer Schätzung von einer Woche 3 Tage frei hatten.

Niemals auf der Seite der engeren Schätzung irren. Err auf der Seite der loseren Schätzung. In Ihrem Unternehmen muss ein Ruf aufgebaut werden, der nicht so sehr auf der Länge Ihrer Schätzungen basiert wie auf der Genauigkeit Ihrer Schätzungen. Es ist einfach, mit einer zu langen Schätzung genau zu sein. Sie haben einfach mehr Zeit, um an dem Problem zu arbeiten und es besser zu lösen. Eine zu kurze Schätzung lässt überhaupt keinen Raum zum Atmen, Sie treffen sie entweder verzweifelt oder Sie sind geschraubt.

28
user204677

"Zwei Wochen!"

Ernsthaft. Meine erste Schätzung ist immer zwei Wochen. Weil ich eine Art bizarre mentale Blockade habe, die mich denken lässt, dass alles so klingt, als würde es zwei Wochen dauern.

Ich versuche es zu umgehen, versuche es wirklich überlegen darüber, wie lange ich denke, dass etwas dauern wird, und versuche, alle potenziellen Problemstellen und Bits zu identifizieren, die zu schwarz aussehen, als dass ich sie genau einschätzen könnte. Und versuchen Sie zu erkennen, dass ich es wahrscheinlich versäumt habe, wenn meine Antwort "Zwei Wochen!" Lautet.

So ziemlich jeder gute Manager, den ich hatte, hat gelernt, "zwei Wochen!" Zu erkennen. als Antwort, die einen milden verbalen Zuhälter-Schlag als Antwort erfordert.

18
BlairHippo

Es gibt einen Blogeintrag , der beschreibt, wie Sie aufzeichnen können, wie genau Ihre vorherigen Schätzungen sind. Wenn Sie dann das nächste Mal jemandem sagen, dass es zwei Wochen dauern werden, können Sie sich Ihre ansehen Vorgeschichte und sehen Sie, wie lange es tatsächlich gedauert hat, als Sie das letzte Mal gesagt haben "es werden zwei Wochen sein".

Ich habe es nicht selbst versucht, aber ich möchte sehen, wie genau meine Schätzungen sind.

17
Richard

Dies hängt von der Organisation und der Verwendung der Schätzungen ab.

Wenn die Schätzung nur eine allgemeine Vorstellung davon geben soll, wann sie fertig sein wird, kann ich aufgrund meiner Erfahrung im Allgemeinen eine schnelle Schätzung vornehmen. Oft werde ich Unsicherheiten oder mögliche Abweichungen in die Schätzung einbeziehen, zusammen mit den Auswirkungen der Änderungen auf andere Bereiche des Systems und dem Umfang der erforderlichen Regressionstests.

Wenn die Schätzung für vertragliche Zwecke oder in einem Szenario verwendet wird, in dem ein genaueres Timing erforderlich ist, mache ich eine vollständige Arbeitsaufschlüsselung. Dies ist mehr Arbeit und erfordert ein gründlicheres Nachdenken über das Design und Änderungen am System, ist jedoch viel genauer, insbesondere für größere Arbeiten.

In beiden Fällen ist die fortlaufende Kommunikation der Schlüssel. Wenn Sie auf etwas Unerwartetes stoßen, machen Sie es zu diesem Zeitpunkt bekannt, anstatt bis zum Stichtag zu warten. Wenn die Anforderungen nicht klar sind, stellen Sie sicher, dass Sie Ihr Verständnis für sie und die Funktionen, die Sie bereitstellen möchten, dokumentieren. Dies ist auch hilfreich, wenn Sie Annahmen treffen. Und was konkurrierende Prioritäten angeht, so ist klar, wie sich dies auf den Zeitplan auswirkt, wenn eine Arbeit gegen eine andere stößt.

11
g .

Schätzungen für was? Kleine Aufgaben oder Komplettlösungen.

Letzteres mache ich selten, aber dann rate ich einfach, füge ein bisschen hinzu, lasse den Manager ein bisschen hinzufügen und mache es zu einem Bereich, daneben eine kleine Notiz, die besagt, dass das Obige eine Vermutung ist.

Kleine Aufgaben - Planning Poker Ich habe festgestellt, dass es wirklich gut funktioniert (nicht perfekt, einige 1pt-Aufgaben haben viel länger gedauert und einige 5pt-Aufgaben haben Minuten gedauert, aber am Ende gleicht sich alles aus).

9
mlk

Präsentieren Sie ein Sortiment basierend auf dem, was Sie heute wissen. Verwenden Sie Kegel der Unsicherheit , um den Bereich um Ihre anfänglichen Schätzungen anzugeben.

Berechnen Sie jede Woche, wie viel noch zu tun ist, und schätzen Sie anhand Ihrer Kenntnisse neu. Wenn Sie genug von einer Stichprobengröße haben, wie viel Arbeit Sie pro Woche erledigen, geben Sie ein 90% -Konfidenzintervall für das, was übrig bleibt, um einen (normalerweise) immer enger werdenden Datumsbereich im Verlauf des Projekts und den verbleibenden Arbeitsaufwand (hoffentlich) anzugeben ) schrumpft.

7
Paddyslacker

Zuversichtlich. Ich kann Ihnen nicht sagen, wie oft ich ein erstes Treffen mit einem Kunden verpfuscht habe, indem ich bei der Abgabe eines Kostenvoranschlags keine Professionalität gezeigt habe. Selbst wenn Sie Zahlen aus dem Nichts blasen - stellen Sie sicher, dass Sie immer eine Schätzung in der Nähe haben. Achten Sie jedoch darauf, sich nicht in ein Loch einzuschätzen. Unterschiedliche Dinge erfordern unterschiedlich viel Zeit, Mühe und Ressourcen, um sie zusammenzustellen. Hier ist ein guter Weg, dies zu tun:

Them : Wie viel kostet es?

Ich : Es hängt davon ab, was ich tun soll. Im Allgemeinen starte ich diese Art von Projekt bei etwa X $.

7
Moshe

Manchmal wird das Schätzen zu einer enormen Herausforderung für Sie und Ihr Team, insbesondere wenn es um das Schätzen von Softwareprojekten geht.

Nachdem wir uns entschlossen hatten, unsere Erfahrungen und unser Wissen über den Software-Schätzprozess zu teilen und definierten vier verschiedene Arten von Schätzungen :

  • grobe Schätzung
  • service-Schätzung
  • merkmalsschätzung
  • komponentenschätzung

Natürlich sind diese Typen verschieden. Ballpark wird oft als "Schätzung" bezeichnet. Es handelt sich also um eine ungefähre Anzahl oder einen ungefähren Bereich, der eine allgemeine Vorstellung von den Kosten vermittelt und einem potenziellen Kunden bei der Entscheidung helfen kann, ob er die Diskussion weiterführen möchte.

Kunden benötigen in der Regel zu Beginn des Projekts eine Baseball-Figur. Und unser Rat ist: Die Diskussion des Projekts und die Bereitstellung von Baseball-Zahlen sollten nur ein guter Schritt sein, um eine Komponentenschätzung zu erhalten (die flexibel ist und von der man Gebrauch machen kann) Schätzung des Komponententyps für den gesamten Entwicklungsprozess. Sie müssen nicht von Grund auf neu schätzen, wenn Sie Funktionen, Dienste usw. hinzufügen, entfernen oder ersetzen möchten.

Jeder sollte die Risiken berücksichtigen, die mit der Schätzung der Softwareentwicklung verbunden sind: Unterschätzen, Überschätzen, Szenario eines epischen Totalausfalls usw.

Sie können mehr auf unserem Blog lesen!

http://blog.lemberg.co.uk/project-management/software-estimation-process/

Hoffe, diese Informationen werden Ihnen helfen!

6
Olha

Am Ende gebe ich immer Schätzungen ab, die ich später nicht erfüllen kann. Es ist unzählige Male passiert und ich verspreche immer, dass es nicht wieder passieren wird.

Es hört sich so an, als würden Sie um eine Verpflichtung gebeten, nicht um eine Schätzung. Dies sind verschiedene Dinge, aber wenn Sie Verpflichtungen zuverlässig verwalten können, hilft dies Ihrer Glaubwürdigkeit und Karriere.

Einige Ratschläge basierend auf meiner ~ 10-jährigen Erfahrung:

  • Geben Sie immer einen Bereich an (d. H. Unter- und Obergrenze). Dies wird Ihre Unsicherheit kommunizieren
  • Wenn Sie eine sehr große Unsicherheit haben, fordern Sie eine Verschiebung an (z. B. 1 Tag für die Analyse, und geben Sie dann einen engeren Bereich an).
  • Wenn die Aufgabe zu groß ist, teilen Sie sie auf und geben Sie für jedes Stück einen Bereich an
5
jamesfmackenzie

Wenn mir eine Aufgabe zugewiesen würde, würde ich sie zunächst in Unteraufgaben aufteilen. Ich würde die Zeit für jede Unteraufgabe schätzen und wahrscheinlich mit Unteraufgaben den Problembereich finden und somit vorhersagen können, wie lange sie dauern würde bis zu einem gewissen Grad nehmen.

Trotzdem würde die gesamte Planung nur bis zu einem gewissen Grad helfen. Erst wenn Sie mit dem Codieren beginnen, können Sie die genauen Probleme finden

4
Gopi

Wenn Sie viele Projekte für denselben Chef oder Kunden durchführen, können Sie versuchen, die Komplexität in großen Schritten anstatt in Wochen oder Monaten, möglicherweise in T-Shirt-Größen, zu schätzen. Identifizieren Sie einige frühere Projekte und weisen Sie ihnen die Größen S, M, L, XL zu.

Und dann fragen Sie sich: Welches Projekt klingt im Umfang ähnlich? Und anstatt mit "2 Monate" zu antworten, können Sie mit "Klingt für mich wie ein L" antworten (oder wie auch immer sich Ihre Kalibrierung für das Projekt herausstellt).

Dies ist ziemlich einfach zu verstehen, und es ist auch klar, dass diese Vermutungen sehr unsicher sind.

Wenn sich die Anforderungen ändern, können Sie sagen, dass diese Änderung eher wie ein XL klingt.

1
moritz

Ein bisschen spät, aber als ich beim Militär war, wurden wir angewiesen, PERT zu verwenden, um Schätzungen zu ermitteln. Es erfordert einige Erfahrung in Ihrem Bereich und der anstehenden Aufgabe. Es war überraschend genau bei der Bestimmung der geschätzten Fertigstellungszeit bei der Wartung und Reparatur elektronischer Geräte (komplexe Funkgeräte und Satellitenkommunikationsgeräte), bei denen eine beliebige Anzahl von Dingen falsch sein oder gefunden werden kann und während der routinemäßigen Wartung behoben werden muss. Die Schätzungen waren wichtig, da andere Einheiten möglicherweise nicht funktionsfähig sind, bis sie ihre Kommunikationsausrüstung zurückerhalten. Eine, die ich verwendet habe, ist diese Free Online PERT Calculator

0
xtreampb