Beratung für einen jungen Programmierer bei der Erstellung von Programmschätzungen

Ich bin ein junger Programmierer, der kürzlich einen Job bei einem kleinen Unternehmen bekommen hat, das aber Schätzungen liebt. Da gute Schätzungen für mich in der Vergangenheit ein Problem waren, freue ich mich über diese Chance, meine Zeit besser einzuschätzen. Irgendwelche Tipps, wie man sich am besten verbessert?

Wo sind die Moderatoren? Wir müssen ungefähr 10.000 gleichwertige Benutzer hierher bringen, damit wir uns um Fragen wie diese kümmern können. Es ist eine großartige Frage für Programmers SE, aber nicht hier.

Antworten (6)

Joel Spolsky empfiehlt in seinem Blog keine einzelne Aufgabe länger als 16 Stunden . Wenn es dort mehr Details gibt, teilen Sie es in Teilaufgaben auf. Ich bevorzuge 1 Tag oder 1/2 Tag Stücke. Und IT-Leute und Entwickler sind regelmäßig optimistisch (nehmen Sie an, dass die Dinge beim ersten Mal funktionieren, minimales Debugging usw.). Verfolgen Sie Ihre Schätzungen im Vergleich zu den tatsächlichen und verwenden Sie diese, um Ihre eigenen Schätzungen abzufedern.

PERT-Bücher verwenden häufig den Ansatz (Optimistisch + 4x Typisch + Pessimistisch)/6 = Schätzwert . Es würde nicht schaden, es ein paar Mal zu versuchen

Die erste Phase für eine gute Schätzung besteht darin, das vorliegende Problem in kleinere Teile zu zerlegen. Versuchen Sie, die anstehende Aufgabe in funktionale Teile zu zerlegen. Da Sie ein Programmierer sind, unterteilen Sie Ihre Arbeit in die Entwicklungsphasen, die Sie voraussichtlich durchlaufen werden (Recherche, Design, Testplanung, Codierung, Tests, Codeüberprüfung, Dokumentation usw.).

Ein guter Detaillierungsgrad ist es, Aufgaben mit einer Größe von etwa 1 Tag Aufwand zu haben.

Wenn Sie mit der Aufschlüsselung fertig sind, besteht die zweite Phase darin, die verschiedenen Aufgaben zu schätzen, die Sie haben. Faktoren, die Ihre Schätzungen beeinflussen könnten, sind:

  1. Das Maß an Gewissheit/ Ungewissheit darüber, was getan werden muss.
  2. Die Technologie , mit der Sie arbeiten – wie viel Overhead haben Sie in einer Iteration von der Codierung bis zum Testen? Wie lange dauert ein Aufbau? Wie schwierig ist es, Ihren Code in kleinen Iterationen zu testen und zu verifizieren?
  3. Wie viel Interaktion benötigen Sie mit anderen Entwicklern , um Ihre Aufgaben zu erfüllen?
  4. Wie stabil ist Ihre Umgebung und Ihr Setup? Haben Sie täglich viele Brüche oder Ausfälle, die Sie daran hindern könnten, Fortschritte zu erzielen?

Ich könnte weiter und weiter fortfahren... Versuchen Sie, an solche Kriterien zu denken, die auf Ihre Umgebung anwendbar sind. Berücksichtigen Sie diese Punkte und versuchen Sie, Ihre Schätzungen entsprechend den Antworten auf diese Fragen anzupassen. Es gibt keine einzige Antwort oder Nachschlagetabelle, die Ihnen bei der Auswahl einer Schätzung hilft, wenn Antworten auf diese Fragen gegeben sind.

In der nächsten Phase überprüfen Sie Ihre Schätzungen mit Ihren erfahrenen Kollegen . Überprüfen Sie nicht nur die Zahlen. Überprüfen Sie die Gründe für die Auswahl der Zahlen als Ihre Schätzungen.

Nun, der letzte Hinweis hier ist, sich selbst im Laufe der Zeit zu üben und zu überwachen . Protokollieren Sie Ihre Schätzungen und die Parameter, die Sie dazu veranlasst haben, Ihre Schätzungen auszuwählen, protokollieren Sie, wie viel Zeit Sie für die Aufgaben wirklich in Anspruch genommen haben und warum. Welche Faktoren hatten Einfluss auf die Ist-Werte? Machen Sie von Zeit zu Zeit eine Retrospektive mit sich selbst und versuchen Sie, Faktoren zu finden, die Sie berücksichtigen können, wenn Sie das nächste Mal Schätzungen abgeben müssen.

Übung macht den Meister (obwohl es bei der Aufwandsschätzung kein Perfekt gibt...).

Das einzige Problem, das ich dabei festgestellt habe, ist, dass Sie zum Erstellen eines Projektstrukturplans (WBS) wenig Fachwissen auf diesem Gebiet haben müssen. Denn wenn WBS nicht in der Lage sein wird, die 100%-Regel zu erfüllen , kann dies zu übermäßigem Zeit- und Kostenaufwand führen .

Hey Ama, auch wenn ich denke, dass diese Frage quasi wiederholt wird, gebe ich dir einen kurzen und süßen Weg, den ich unserem Entwicklungsteam mitteile.

  • Haben Sie einen ersten Swag für Ihren eigenen Zweck. Nennen wir das

x

  • Wenn x > als Ihre PM-Toleranz ist (meine ist 40 Stunden), dann brechen Sie in einfachere logische Probleme auf. Nennen wir das

x1, x2, x3

  • Nehmen Sie x1 und den Umfang von x1 und überlegen Sie sich, was die Zahl sein wird, wenn alles schief geht, was schief gehen kann. Ihre Entwicklungsumgebung geht kaputt, Sie müssen zu viele Fragen stellen, weil die Anforderungen nicht klar sind, usw., usw. Nennen wir das mal

x1-im schlimmsten Fall

  • Ich nehme x1 und x1-worstcase und mittele es. so was:

(x1+x1 – schlimmster Fall)/2

Diese Zahl gibt Ihnen in den meisten Fällen eine gute Schätzung. Wenn Sie weniger pessimistisch sein möchten, fügen Sie ein Best-Case-Szenario hinzu.

Hoffe das hilft. Geo

  • Brechen Sie es kleiner auf. Nie länger als 2 Wochen; vorzugsweise <2 Tage.
  • Notieren Sie, wie Sie es tun, damit Sie sehen können, ob Sie normalerweise 2x oder 10x daneben liegen. Verwenden Sie Bug/Task-Tracking mit dieser Funktion, zB FogBugz oder Redmine.
Eine Aufgabe in kleinere Teile aufzuteilen, dh Arbeitspakete, ist eine gute Option, aber normalerweise wird davon ausgegangen, dass, wenn WP über das spezifische Niveau hinausgeht, dies zu hohen Kosten, aber geringerer Komplexität führen kann.

Besorgen Sie sich ein Exemplar von „Software Estimation“ von Steve McConnell . Es wird sehr helfen .

Eine GROSSE Regel beim Schätzen betrifft das Kundenmanagement. Wenn Sie Ihrer Frau sagen, dass Sie um 5 Uhr zu Hause sind und um 6 Uhr nach Hause kommen, wird sie wütend, ABER wenn Sie ihr sagen, dass Sie um 19 Uhr nach Hause kommen und dann um 6 Uhr nach Hause kommen, ist sie am Ende glücklich. seltsam, aber wahr ... grundlegende Psychologie. Soooooo der wichtigste Teil bei der Abgabe eines Kostenvoranschlags ist sicherzustellen, dass er höher ist als das, was Sie liefern werden, und wenn der PM mit dem Kostenvoranschlag unzufrieden ist, bleiben Sie trotzdem dabei und liefern Sie ihn schneller !!!!!! Am Ende wird er froh sein, dass Sie es früher geliefert haben (und höchstwahrscheinlich sagen, dass Sie anfangen, besser zu schätzen). Aus geschäftlicher Sicht ist es sowieso besser, pünktlich als zu spät zu sein, da sie Termine mit vielen externen Parteien festgelegt haben und diese Termine einhalten wollen.