Wie berücksichtige ich geänderte oder vergessene Aufgaben in einem Kostenvoranschlag?


10

Um Schätzungen auf Aufgabenebene und Zeitberichte zu verarbeiten, habe ich (ungefähr) die Technik verwendet, die Steve McConnell in Kapitel 10 der Softwareschätzung beschreibt. Insbesondere wenn es an der Zeit ist, Schätzungen auf Aufgabenebene zu erstellen (kurz bevor die Codierung für ein Projekt beginnt), bestimme ich die Aufgaben auf einer ziemlich detaillierten Ebene, sodass ich, wann immer möglich, keine Aufgaben mit einem einzelnen Punkt habe, 50 % -Konfidenzschätzung größer als vier Stunden. Auf diese Weise hilft der Aufgabenschätzungsprozess beim Erstellen der Software und hilft mir, Aufgaben während der Schätzung nicht zu vergessen. Ich habe auch für jede Aufgabe eine Reihe von Stunden festgelegt. Mithilfe der statistischen Berechnungen, die McConnell zusammen mit meinen historischen Genauigkeitsdaten beschreibt, kann ich auf Wunsch Schätzungen mit anderen Konfidenzniveaus erstellen. Ich habe das Gefühl, dass diese Methode für mich ziemlich gut funktioniert hat. Wir müssen Aufgaben und ihre Schätzungen zur Nachverfolgung in TFS einfügen, daher verwende ich die Schätzungen mit dem Prozentsatz des Vertrauens, den ich verwenden soll.

Ich bin mir jedoch nicht sicher, was ich tun soll, wenn ich eine Aufgabe vergesse oder am Ende Arbeiten ausführen muss, die nicht genau zu einer der von mir geschätzten Aufgaben gehören. Natürlich ist es am besten, diese Situation zu vermeiden, aber wie kann ich vergessene / geänderte Aufgaben berücksichtigen? Ich möchte die besten historischen Daten haben, die ich kann, um mir bei zukünftigen Schätzungen zu helfen, aber im Moment berechne ich im Grunde nur, ob ich die 50% -Konfidenzschätzung gemacht habe und ob ich sie innerhalb der Bereichsschätzung gemacht habe.

Gerne kläre ich bei Bedarf, was ich frage - lassen Sie mich wissen, was unklar ist.



Ich denke, ich muss ein Beispiel geben, wie ich diese Berechnungen durchführe und welches Problem ich zu lösen versuche. Ich habe im Moment keine Zeit, aber ich werde so schnell wie möglich darauf zurückkommen.
Andrew

In Scrum geben Sie keine Zeitschätzungen heraus. Sie geben Story Points, die anderen eine Idee geben. Sie haben auch keine Größe von unten nach oben. Sie müssen nicht - die Geschwindigkeit ist eine vage Sache.
Job

@Job Wir sind derzeit kein Scrum-Shop. Im Gegensatz zu dem, was ein anderer Antwortender vorgeschlagen hat, habe ich bisher festgestellt, dass die Bottom-up-Schätzungen meine Schätzgenauigkeit verbessert haben, hauptsächlich durch die erhebliche Reduzierung der Anzahl vergessener Aufgaben während der Schätzung auf Aufgabenebene.
Andrew

@blueberryfields - Eine Multiplikation mit nur 50% sollte ausreichen, zumindest in einem Unternehmen mit vielen Hierarchieebenen, in dem jede ihren eigenen Überschätzungsfaktor hinzufügt.
Mouviciel

Antworten:


6

Das Buch Waltzing With Bears: Risikomanagement bei Softwareprojekten (von DeMarco und Lister, den Peopleware-Autoren) hat einen hervorragenden Ansatz. Hier ist meine Neuinterpretation:

Machen Sie eine Schätzung "Alles läuft perfekt". Natürlich läuft selten alles perfekt, so dass die Wahrscheinlichkeit, dass etwas passiert, gering ist, sagen wir 0,1 Prozent. Mit anderen Worten, nur ein Projekt von tausend wird perfekt nach Plan verlaufen. Dies ist, was die meisten Menschen als ihre "Schätzung" verwenden, was offensichtlich verrückt ist.

Stattdessen sollten wir uns Schätzungen als Wahrscheinlichkeitsverteilungen vorstellen. Diese Schätzung der "perfekten Welt" ist der am weitesten links stehende Punkt in der Schätzwahrscheinlichkeitsverteilung.

Machen Sie als nächstes eine Schätzung "Wenn die Dinge so laufen, sind ähnliche Projekte wie dieses verlaufen". Diese Schätzung hilft Ihnen bei der "Außenansicht" ( http://wiki.lesswrong.com/wiki/Outside_view ), um dem Planungsfehler ( http://wiki.lesswrong.com/wiki/Planning_fallacy ) zu entkommen .

Machen Sie als nächstes eine Schätzung "Ich bin zu 90% sicher, dass wir mit X fertig sind". Seien Sie sehr, sehr sicher, Sie meinen 90% sicher. Mit anderen Worten, Sie erwarten, dass Sie nur einmal pro zehn Projekte länger als diese Schätzung dauern.

Wir können jetzt Ihre erste Schätzung als 0,1% Wahrscheinlichkeitsschätzung und Ihre zweite als 50% Wahrscheinlichkeitsschätzung (Jahreszeit nach Geschmack) und die dritte als 90% Schätzung verwenden, wodurch Sie eine schöne Kurve erhalten.

Angenommen, Ihre Schätzungen für 0%, 50% und 90% waren der 1. Mai, der 1. Juni und der 1. August. Dann würde Ihre Schätzkurve ungefähr so ​​aussehen:

     100 |                                  ......
         |                        ..........
% chance |                ........
of being |          ......
  done   |      ....
         |   ...
         |...
       0 +-----------------------------------------
          \           \           \           \
           May 1st     June 1st    July 1st    August 1st

Beachten Sie, wie sich das Wachstum der Wahrscheinlichkeit mit der Zeit verlangsamt. Wenn Sie in diesem Szenario von jemandem um eine Schätzung von 99,9% gebeten wurden, ist dies möglicherweise der 1. Januar des nächsten Jahres.


Danke für die Antwort. Die Methode, die ich bereits verwendet habe, ermöglicht es mir, das zu tun, was Sie anscheinend vorschlagen, berücksichtigt aber auch (indirekt unter Verwendung eines Prozentsatzes der historischen Genauigkeit) meinen bisherigen Erfolg mit meinen Schätzungen, um den Prozentsatz zu generieren. zuversichtliche Schätzungen erwünscht. Ich frage jedoch, wie verpasste Aufgaben in diese historische Genauigkeit einbezogen werden können, wenn die Genauigkeit im Wesentlichen danach berechnet wird, ob ich eine Aufgabe innerhalb des Bereichs abgeschlossen habe, den ich für meine ursprüngliche Schätzung verwendet habe.
Andrew

@ Andrew, wenn ich Sie richtig verstehe, werden die "verpassten Aufgaben" durch die weniger als 100% ige Wahrscheinlichkeit erklärt, zu einem bestimmten Zeitpunkt erledigt zu werden. Wenn Sie viele Projekte wie das aktuelle durchgeführt haben, steigt Ihre Kurve schnell von 0% auf (sagen wir) 90%. Das liegt daran, dass Sie sehr sicher sind, dass nur wenige Aufgaben verpasst werden. Wenn Sie ein geringes Vertrauen haben, ist die Steigung viel allmählicher. Das gilt aus irgendeinem Grund, nicht nur für vergessene Aufgaben, sondern auch für andere Risikofaktoren.
Benji York

Ja, die fehlenden Aufgaben werden insgesamt durch die Bereiche auf Aufgabenebene abgedeckt, die sich in den von mir angegebenen Konfidenzniveaus niederschlagen. Ich berechne diese Werte mit einer Methode, die McConnell in Kapitel 10 der Software-Schätzung vorschlägt, wie ich bereits sagte. Ich frage mich hauptsächlich, wie ich diese fehlenden oder geänderten Aufgaben in der TFS-Stundenberichterstattung berücksichtige und wie ich diese Stunden bei der Berechnung meiner historischen Genauigkeit einbeziehe.
Andrew

5

Mit einem Wort - Kontingenz.

Kontingenz ist der Betrag, den Sie für "andere Dinge" hinzufügen - die Dinge, die Sie an keiner anderen Stelle in Ihrer Schätzung berücksichtigen können. Deckt SMc dies in Software Estimating ab? Ich kann mich nicht erinnern und mein Exemplar ist bei der Arbeit (ich bin im Urlaub und beantworte dies - wie traurig bin ich) ...

Im Allgemeinen gibt es drei Arten von Eventualitäten, die ich empfehlen würde:

1) Risikospezifische Eventualverbindlichkeit - Hier identifizieren Sie ein bestimmtes Risiko und fügen eine bestimmte Zeit hinzu, um die damit verbundene potenzielle Überschreitung abzudecken. Das erste, was hier klar ist, ist, was ein Risiko ist - es kann passieren, was sich negativ auf das Projekt auswirkt, das außerhalb Ihrer Kontrolle liegt .

Dieser letzte Teil ist von entscheidender Bedeutung - es geht nicht nur um "Dinge, die etwas länger dauern als ich dachte", sondern um "das Planungsmodul von Drittanbietern, von dem uns gesagt wurde, dass wir es verwenden müssen, da es ein Unternehmensstandard ist, der möglicherweise nicht der Aufgabe entspricht". Die Art und Weise, wie Sie berechnen, wie viel Risikokontingenz hinzugefügt werden muss, ist die prozentuale Wahrscheinlichkeit, dass das Risiko eintritt, ausgedrückt als Dezimalzahl (also 50% = 0,5), multipliziert mit der Auswirkung dieses Risikos (im Beispiel heißt es, Sie müssen CRON manuell schreiben Jobs anstelle der Verwendung des Schedulers und dies dauert 10 Tage, diese Zahl ist 10 Tage).

Wenn also eine 50% ige Chance besteht, dass Ihr Risiko eintritt, und es 10 Tage dauert, um es zu umgehen, fügen Sie 5 Tage hinzu. Addieren Sie alle Werte für alle identifizierten Risiken im Projekt und addieren Sie sie zur Gesamtsumme.

2) Scheiße passiert Kontingenz - Die beste Beschreibung, die ich je dafür gehört habe, auch wenn sie nicht elegant ist. Es ist ein IT-Projekt, Scheiße passiert. Es geht nie so, wie du denkst, die Dinge dauern länger, werden verpasst und so weiter. Im Allgemeinen liegt die SH-Kontingenz zwischen 10% (absolutes Minimum) und 25% (kann jedoch höher sein), wobei 15% ungefähr typisch sind, wobei das genaue Niveau von der Unsicherheit und dem allgemeinen Risiko abhängt (Verschieben von Torpfosten, unsichere Anforderungen usw.) ).

Wenn Ihr PM SH Contingency nicht akzeptiert (und es ist möglich, dass er keine Erfahrung mit IT-Projekten hat oder ein blinder Optimist ist), addieren Sie es einfach zu allen einzelnen Beträgen. Wenn er weiß, was er tut, hat er ein eigenes Risikoprotokoll und liebt dich, wenn du über dieses Zeug nachdenkst. Wenn er irgendeine PM-Qualifikation hat (wie PRINCE2), wird er es sicherlich wissen.

3) Änderungskontingenz - Hier sind Sie ziemlich sicher, dass der Client Änderungen vornehmen wird, möchten aber nicht, dass dies ein Streitpunkt ist. Addiere entweder X Tage oder X% und es geht in einen Topf für Änderungen, die der Kunde erhöht. Es gibt zwei Möglichkeiten, damit umzugehen: Entweder erzählst du ihnen davon und es liegt an ihnen, es auszugeben, oder du erzählst ihnen nichts davon.

Der erste Weg ist der beste, braucht aber einen ziemlich gebildeten und fair gesinnten Kunden - Dinge werden als Veränderungen eingestuft und er kann seinen Topf ausgeben, wie er es für richtig hält (basierend darauf, dass Sie die Dinge schätzen, sobald sie auftauchen).

Die zweite Möglichkeit, wie Sie erwähnen, ist, dass es sich um eine Änderung handelt, aber Sie müssen ihn nicht extra belasten. Sie müssen alle Dinge notieren, für die Sie es ausgeben. Wenn es also so weit ist, dass es aufgebraucht ist, müssen Sie zum Kunden zurückkehren und um mehr Zeit oder Geld bitten, und er sagt: "Moment mal, ich." Ich bezahle bla bla bla "Sie können auf all die Dinge hinweisen, die sie bereits geändert haben und die Sie nicht in Rechnung gestellt haben, als Zeichen dafür, dass Sie nicht völlig unvernünftig sind. Es funktioniert nicht immer, aber es stärkt fast immer Ihre Hand in den Diskussionen.

Keiner dieser drei Punkte behandelt speziell Dinge, die Sie vergessen haben, aber ich denke, zwischen ihnen werden Sie viele der Lücken füllen, die Sie haben.


Vielen Dank für Ihre Antwort. Sie sprechen interessante Punkte an. Ich beziehe diese drei Punkte bereits auf verschiedene Weise in meine Schätzungen ein. Ich habe festgestellt, dass Ihr erster Typ normalerweise artikuliert und mit einer oder mehreren Aufgaben verknüpft werden kann. Der zweite Typ wird nur in meine Bereichsschätzungen auf Aufgabenebene aufgenommen: Ich darf kein zusätzliches Element dafür haben (wir haben darüber diskutiert, und im Moment ist dies eine Richtlinie für unser Team). Zum dritten akzeptieren interne Kunden, dass Änderungen unsere Schätzung erhöhen, und externe Kunden haben dies schriftlich, sodass wir Änderungen nicht berücksichtigen sollten.
Andrew

In Bezug darauf, ob McConnell Eventualverbindlichkeiten abdeckt, ist meine Kopie ebenfalls in Arbeit, daher müsste ich dies überprüfen. Ich denke, ich frage, wie fehlende / geänderte Aufgaben bei der Berechnung von Verlaufsdaten berücksichtigt werden können, um die nächste Schätzung zu informieren, und wo die Stunden in TFS zugewiesen werden sollen, da eine Notfallaufgabe in unserer Gruppe normalerweise nicht zulässig ist.
Andrew

0

Wenn Sie nach einer Schätzung für eine Aufgabe gefragt werden, geben Sie dem Team eine High-End-Schätzung und haben Sie eine Low-End-Schätzung für sich selbst. Auf diese Weise haben Sie nach Abschluss der Aufgabe immer Zeit, an etwas zu arbeiten, das Sie möglicherweise vergessen haben, an erster Stelle zu erwähnen.


Danke für die Antwort. Die Bereiche, die ich mir insgesamt ausgedacht habe, geben mir in der Regel genügend Zeit, um vergessene Aufgaben hinzuzufügen, ohne die Schätzung für das gesamte Projekt zu verpassen. Meine Frage spricht mehr für die Verwendung dieser Informationen in dem Berechnungsverfahren, das ich aus dem McConnell-Buch verwende.
Andrew

0

Befürchten Sie, dass Sie durch Hinzufügen der zusätzlichen Aufgaben Ihre historische Genauigkeit verzerren? Oder glauben Sie, dass die Genauigkeit beeinträchtigt wird, wenn die zusätzlichen Aufgaben nicht berücksichtigt werden?

Ich denke, für das Beste des Projekts sollten die Aufgaben in das Tracking-System eingegeben werden. Ich bin sicher, dass der Projektleiter dem Management eine geeignete Erklärung für Unstimmigkeiten anbieten kann ...


Ich könnte einfach bis morgen warten und dir das persönlich erzählen. :) Ich mache mir mehr Sorgen um die Ungenauigkeit der Geschichte, wenn die zusätzlichen Aufgaben nicht irgendwie enthalten sind. Das Fehlen einer Aufgabe während der Aufgabenschätzung ist eindeutig ein "Fehlschlag" in Bezug auf die Genauigkeit - aber welche Genauigkeitszahl? Diejenige, die ich tatsächlich im quantitativen Sinne verwende, ist, ob meine tatsächliche Aufgabenleistung für jede Aufgabe innerhalb des vorhergesagten Bereichs lag. Das andere, qualitativere Maß ist, wie oft ich meine 50% -zuverlässigen Einzelpunktschätzungen erfülle. Zu weit über oder unter 50%, und ich sollte das "Expertenurteil" für zukünftige Schätzungen von 50% anpassen.
Andrew
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.