Aufwandsschätzung

So heute ist es mal wieder so weit. Nils stellt eine Aussagen in den Raum. Und zwar geht es um Aufwandsschätzung. Ich möchte hier auch gar nicht auf irgendwelche Techniken eingehen. Das können andere sicherlich um einiges besser erklären . Hier sollte sich Eberhard jetzt angeblinzelt gefühlt haben. Vielmehr geht es mal wieder um einen kleinen Erfahrungswert.

Ich kann mich noch an meine Zeit bei Nero erinnern. Wir waren teilweise echt miese Schätzer. Zeiten, die wir am Anfang eines Projektes angegeben hatten, hatten wir mal um dreifache übertroffen, mal lagen wir drunter, mal haben wir getroffen. Der Treffer im Bulls Eye war aber leider sehr selten.

Waren wir also besonders schlecht? Nein! Laut Scott Berkums Die Kunst des IT Projektmanagements (das ich übrigens jedem empfehlen kann) landen zu frühe Schätzungen bis zu 400% daneben. Wir lernen also, das mies Schätzen in der Natur des Menschen liegt und nicht an uns. Ihr musstet sicher auch schon mal eine Schätzung abgeben von was, dass ihr gar nicht schätzen konntet oder wolltet. In vielen Fällen betreten wir nämlich Neuland und das macht besonders schwer.

Um wenigstens ein wenig damit zurecht zu kommen, gilt es möglichst oft eure Schätzungen anzupassen. Sobald ihr ein neues Stück Information gefunden habt, das euch behilflich ist euren Zeitplan zu verbessern, dann macht es. Kommuniziert den neuen Plan auch. Ist ja nicht verkehrt jede Woche eine bessere Schätzung zu haben. Irgendwann und ich hoffe mal nicht zu spät wird euer Tipp dann doch ins Schwarze treffen.

Was haben wir also gelernt? Schätzen ist schwierig, deswegen sollte man es häufig machen.

18 Comments

Schade, hab jetzt irgendwie auf Praxistipps gehofft… Da bleiben Einem wohl doch nur dietheoretischen Formeln.

Tja, das lernt wohl jeder am Anfang seiner Karriere 😉 „Wie lang dauert das denn?“ .. das was ich über die Zeit gelernt habe .. schätzen ist okay, wenn man eigentlich gar nicht schätzen kann .. dann Bedingungen damit verknüpfen.

„Diese Schätzung bedingt, dass wir .. wissen/haben/können/dürfen“. Ist diese Bedingung hinfällig, ist auch die damit verbundene Schätzung hinfällig – und ich muss sagen, das funktioniert mittlerweile relativ zuverlässig und wird auch (manchmal widerwillig, aber doch :p) vom Kunden akzeptiert.

Kann man ja auch (zur Not *g) argumentieren .. so isses ja nicht 😉

Hier bei Mayflower schätzen wir über Planning Poker und kommen damit sehr gut zurecht, die Schätzungen gehen auch nur sehr selten daneben. Der Vorteil, den wir dadurch erreichen, ist, dass die Entwickler bei vollkommen falschen Schätzungen keine Überstunden schieben müssen und man dem Kunden eine wirklich reale Vorhersage mitteilen kann.

-Thorsten

Wer aufgrund solcher Schätzungen (zu diesem unmöglichen Zeitpunkt) dann nachträglich zu Überstunden verdonnert wird .. sollte sich wirklich Gedanken machen ;o

Um gut Schätzen zu können muss man häufig reflektieren (also ist es ganz klar ein Erfahrungswert).
Also sollte man bei einem Projektabschluss immer rückblickend betrachten, wie anfänglich die Schätzung war und wie das Ergebnis effektiv herausgekommen ist. Dann sollte man noch schauen, welche Faktoren dafür verantwortlich waren, dass die Schätzung falsch oder eben richtig lag.
So hat man die Möglichkeit diese Erfahrungswerte wieder in neue Projekte einfliessen zu lassen.
In dem man permanent nur schätzt, ohne Rückblickend zu schauen, wie die Schätzung herausgekommen ist, bringt nix.

Vor genau diesem Problem stehe ich nun.
Ich bin so gut wie am Ende meiner Ausbildung zum FI/AE und muss jetzt bis zum Ende des Monats meinen Projekt Antrag abgeben.
In diesen soll grob Ziel des Projektes und Aufwandsabschätzung für einzelne Schritte in Stunden enthalten sein.
Tücke daran ist, unsere Projekte müssen natürlich ein gewisses Niveau haben und die Zeiteinschätzung recht genau.
Ich weiß weder, wie ich das Niveau genau abschätzen soll, noch die Zeitplanung kalkuliere.

-Spider

Also mal mein Senf dazu.

Zunaechst einmal ist eine Schaetzung keine exakte Zeitplanung, sondern hat eine gewisse Toleranz. Deswegen kann man Schaetzungen zB als von-bis Schaetzungen definieren, wobei der von Wert eine geringere Wahrscheinlichkeit hat als der bis Wert. Wenn man sehr frueh schaetzen muss, sollte man mit beiden Werten ein ausreichend grosses Fenster aufziehen.
Durch den Fortschritt im Projekt kann man dieses Fenster dann immer enger ziehen.

Ein super Buch zu dem Thema, welches ich nur jedem ans Herz legen kann ist http://www.amazon.de/Termin-Ein-Roman-%C3%BCber-Projektmanagement/dp/3446414398/ref=sr_1_1?ie=UTF8&s=books&qid=1262938871&sr=8-1.

Was ausserdem betrachtet werden muss:
Oft jammern wir immer, dass wir fuer Tests, Dokumentation, etc keine Zeit hatten. Das liegt nicht selten daran, dass wir sie nicht mitschaetzen! Wer nur netto die Implementierung schaetzt, schaufelt sich sein eigenes Grab.

Der einfachste Weg ist, große Anforderungen in kleinere zu zerlegen. Das ganze kann soweit betrieben werden, dass man die Dinge dann wirklich mit Leichtigkeit abschätzen kann. Wie in [1] beschrieben, funktioniert das Gesetz der großen Zahlen recht gut. Durch das Aufteilen einer großen Anforderung in kleinere Teilanforderungen kann ich jede überschaubare Teilanforderung besser bewerten. Da man aber oft, wie hier auch schon gesagt, falsch bewertet, liegt der Vorteil in diesem System, dass über die Werte gemittelt ein besseres Schätzergebnis entsteht. Mal schätzt man drüber, mal drunter, aber im Mittel nähert man sich an.

Auch bei den agilen Methoden werden Hilfsmittel zur Aufwandsschätzung bereitgestellt. Wie Thorsten schon erwähnt hat, kann man mit abstrakten Schätzgrößen (z.B. StoryPoints in XP [2]) und PlanningPoker ganz gute Ergebnisse erzielen.

[1] http://www.webkrauts.de/2009/12/08/hilfsmittel-fuer-aufwandsschaetzungen/
[2] http://de.wikipedia.org/wiki/Extreme_Programming

Es ist doch ganz einfach.

Schritt 1: Ihr schätzt den Aufwand nach bestem Wissen und Gewissen in Stunden.

Schritt 2: Diese Summe aus Schritt 1 wird pauschal verdoppelt.

Schritt 3: Ihr legt den Kunden Faktor fest. Einfacher und strukturierte Kunde bekommt den Faktor 1, komplizierter und chaotischer Kunde bekommt den Faktor 3. Diesen Kunden Faktor multipliziert ihr mit der Summe aus Schritt 2.

Schritt 4: Ihr legt den Entwickler Faktor fest. Habt ihr nur motivierte und sehr erfahrene Entwickler nehmt ihr den Faktor 0.5, habt ihr nur unmotivierte Praktikanten, nehmt ihr den Faktor 4.0, die Wahrheit liegt sicher irgendwo dazwischen. Diesen Entwickler Faktor multipliziert ihr mit der Summe aus Schritt 3.

Schritt 5: Gibt es ein Pflichtenheft zieht ihr pauschal 20 Stunden multipliziert mit dem Kunden Faktor von der Summe aus Schritt 4 ab. Gibt es kein Pflichtenheft addiert ihr pauschal 20 Stunden multipliziert mit dem Kunden Faktor und dem Entwickler Faktor zu der Summe aus Schritt 4 dazu.

Schritt 6: Nun könnt ihr noch das Ergebnis aus Schritt 5 je nach Lust, Laune und Sonnenstand um maximal 23% nach oben oder unten anpassen. Verlasst euch da auf euer Gefühl.

Das war es schon. Einfach, oder? Und klappt garantiert immer!

😉

*schmunzel, in der Tat fühle ich mich angesprochen. Man könnte natürlich immer so schätzen wie Scotti auf der Enterprise. Das hilft aber nicht weiter 😉

Vieles wurde schon genannt. Erfahrung ist hilfreich, Erfahrung muss jedoch erarbeitet werden. Hier möchte ich den Punkt von Ralph Meier unterstreichen. Nutzbare Erfahrung entsteht durch Reflektieren, Reviews, Retrospekiven … also durch bewusste Rückblicke. So gewonnene Erfahrung macht Schätzungen allmählich besser. Um aber auch in neuen Kontexten zu Beginn gute Schätzungen abliefern zu können halte ich mich an folgende Punkte:

Aufgaben und Ziele so weit wie möglich in Teile zerlegen und für jeden einzelnen Teil schätzen.

Unabhängige Schätzungen für die Teilschritte einholen. Das müssen nicht immer die gleichen Leute sein, ggf. kann auch ein Außenstehender eine kurze Schätzung für einen Teil abgeben.

Wenn sich unabhängige Schätzungen um mehr als 20% unterscheiden, Widersprüche unbedingt aufklären.

Zuschläge für übergreifende Aktivitäten nicht vergessen und ebenfalls in Einzelaktivitäten aufsplitten. Z.B fallen in einem 9 monatigen Projekt ggf. nennenswert Aufwände für Berichte an. Alle 4 Wochen ein Bericht, mit Nachfragen beantworten + ggf. Präsentation alle drei Monate: Aufwand = 9 * 2 Stunden (Schreiben) + 9 * 1 Stunde (Nachfragen) + 3 * 4 (Präsentation vorbereiten und halten) = 39 Stunden oder 5 Tage.

Methodisch wiederkehrende Termine (Meetings) nicht vergessen und ebenfalls auf Stundenbasis aufschlüsseln.

Immer im Hinterkopf behalten, dass eine Schätzung nie genauer als +/- 20% sein kann. Dementsprechend wenn möglich die Toleranzen auch angeben.

Eine gute Methode um die ersten drei Punkte zu berücksichtigen ist auf jeden Fall der Planungs-Poker.

Scrum und die dort genannten Techniken sind eine Sache. Mein Problem war, das dies bei uns nicht anwendbar war, weil die Teams zu klein sind und Scrum erst viel zu spät ansetzt.

Wenn der „Product Owner“ die Geschäftsleitung und das „Team“ ein einzelner Mitarbeiter oder ein sehr kleines Team ohne „Scrum Master“ ist, passt es nicht mehr ohne Weiteres. Wenn das Team zum Schätzen keine Aufgaben sondern unausgegorene Ideen bekommt, macht ein Planungspoker wenig Sinn.

Deshalb: Die Anforderungsdokument ist das „Produkt“ des Anforderungsgebers und der technische Projektleiter nimmt dieses „Produkt“ erst ab, wenn es in Ordnung ist.
Hat es Mängel, muss es zurückgewiesen werden bis es in Ordnung ist. Vorher gibt es keine Schätzung, da eine zu frühe, falsche Schätzung bares Geld kostet.

Natürlich muss in vielen Firmen trotzdem auch mit minderwertigen Anforderungen termingerecht geliefert werden. Fehlschätzungen werden kompensiert durch unbezahlte Überstunden. „Anforderungen“ sind häufig Excellisten oder Stichpunktzetteln und für die Schätzung wird zu wenig Zeit eingeräumt. Die Entscheidung, dass es so nicht funktioniert und sich etwas ändern muss, ist ein wichtiger Schritt, der in vielen Firmen seit Jahren aussteht.

Tipps für kleine Teams:

1. ein zweites Augenpaar ist bei der Schätzung immer hilfreich (Das Vieraugenprinzip benutzt man auch im Planungspoker.)
2. Anforderungen aufteilen in „Akzeptanzkriteren“ (Constraints) und Aufgaben
3. Aufgaben zerlegen in Teilaufgaben und dabei Lücken in der Anforderungsdoku erkennen und dokumentieren
4. aus guten Akzeptanzkriterien lassen sich Akzeptanztests ableiten
5. mit 4 Augen gegenseitig kontrollieren, dass der gesamte Entwicklungsprozess geschätzt wurde: inklusive Schriftverkehr, Meetings, Dokumentation, Support und Deployment
6. Sind die Anforderungen schwierig, oder nicht eindeutig dann baue für die strittigen Punkte einen einfachen Prototypen. Prototypen machen Lücken, Fehler und Missverständnisse in den Anforderungen werden schnell transparent.
7. Nimm dir Zeit für die Schätzung.
8. Die Anforderungsdokument ist das „Produkt“ des Anforderungsgebers. Sind die Anforderungen schlecht, dann reklamiere die Mängel BEVOR du damit arbeitest und Zeit verschwendest!
9. Hole dir Hilfe. Es gibt einen Grund, dass „Requirements Engineering“ ein eigenes Studienthema ist. Als Geschäftsleitung oder Anforderungsgeber kann man nicht alles wissen. Wenn du nicht weißt was BPMN ist – frag jemanden der sich damit auskennt.

Hier ist noch ein sehr guter Buchtipp zum Thema.
Der Titel sagt ja schon einiges aus:

http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351

Hallo Nils!

Ich bin ja sonst immer so ein stiller Leser, aber weil ich dieses Jahr zu diesem Thema einen guten Vorsatz hab, kriegt Ihr hier alle meinen Senf ab:

1. Wichtiger als Deadlines oder generell vereinbarte Daten (Meetings, „dann kommt was per Post/Mail“, „dann ist dies und das fertig“) ist für mich dieses Jahr kommunikation:
Kein Kunde (darauf wette ich) jukt es, wenn er ein Mail kriegt: „Du Karri, dauer noch bis Mittwoch statt Montag, [IRGEND EIN GRUND EINFÜGEN].“ (ok, wenn am Montag das 1000 Jährige Jubiläum der Firma ist – scheisse)
ABER: jeden jukts, wenn man am Montag auf die Daten wartet und dann nichts kommt. Ausserdem: rechtzeitig und wenn möglich im voraus Melden!

2. Mach so wenige Deadlines wie möglich! Lieber auf den nächsten Schritt ein genaues Datum – viele meiner Kunden mögen dies, statt eine Deadline weit in der Zukunft, bei der schon von Anfang an klar ist, dass sie nie und nimmer eingehalten wird (dem Kunden auch erklären, warum dieses Datum nicht geht). Aber dann – besonders als Webdesigner / Programmierer – für den Kunden „irgendwas“ bereit haben. Ihm immer wieder klar machen: an DEINEM Produkt wird gearbeitet, hier seh es DIR SELBER an.

Klar ich weiche hier jetzt bisschen von der eigentlichen Frage ab, wie man gute Deadlines bestimmt. Aber dies wurde eigentlich schon imo gesagt: zweites Augenpaar, gut Überlegen, Pflichtenheft verlangen, etc…

Gegrüsstes
David

Hallo Zusammen,

sehr wichtiges Thema und sehr innformative Kommentare. Vielen Dank dafür.

Wir gehen mehr und mehr dazu über, bei komplexen Projekten eine Trennung zwischen Konzeptionsphase und Design bzw. technischer Realisierung vorzunehmen.

D.h. wir starten mit einem Workshop, in dem die Projekteckdaten sehr detailliert konkretisiert werden. Die Vorbereitung läuft auf Grundlage eines Fragebogens in dem vorab die Grundvorausetzungen geklärt werden. Die sich daraus ergebende Aufwandschätzung beruht dann auf weitestgehend durchkonzepierten Elementen. Dabei hilft es uns – wie bereits mehrmals angesprochen – die Arbeiten in Teilaufgaben bzw. Funktionsmodule zu unterteilen (z.B. Newsletter-Modul, Produkt-Datenbank, etc.), so dass die jeweiligen Leistungen einzeln zu betrachten und zu bepreisen sind. In einem Funktionsmodul stecken dann wieder verschieden Leistungsarten (Konzeption, Design, Programmierung, etc.).

Ein großes Problem haben wir nach wie vor bei der Einschätzung der Kommunikationsaufwände. Zumal Leistungspositionen wie Projektmanagment vom Kunden nicht als konkrete Design- oder Programmierleistung wahrgenommen werden. Gleichwohl sind diese Abstimmungen – wie jeder weiß – besonders bei der Kunden Kategorie 3, sehr zeitaufwendig. Hier hilft dann die Daumenregel von 15 – 20% des Projektetats auch nicht weiter.

In jedem Fall ist dazu zu raten, möglichst alle Funktionen in den Templates final zu visualisieren und sich vom Kunden abnehmen zu lassen. Korrekturschleifen in bereits programmierten Gewerken sprengen jede Aufwandschätzung.

wie schon erwaehnt, ist reflexion auch sehr hilfreich und das laesst sich meistens einfacher bewerkstelligen, wenn man stundenerfassungstools fuer laufende projekte nutzt.

das zwingt den erwickler mehr darueber nachzudenken, was er eigentlich den ganzen tag getrieben hat. gibt ihm aber auch genauso die moeglichkeit im nach hinein festzustellen, was nun der tatsaechlich aufwand war.

… und das ist wieder ein guter erfahrungswert fuer die naechste schaetzung …

Ich finde die Kommentare sehr hilfreich und übersichtlich. Insbesondere die Kommentare 3, 5, 8, 10, 11. Danke!

Ich möchte mal noch einen Aspekt in dem Raum werfen, der imo etwas zur kurz kommt in dieser Diskussion. Wie soll man schätzen wenn es keine konkreten Vorgaben gibt a la „Wer kann mir eine Webseite umsetzen?“ oder „Wie lange dauer Feature xy?“. Insbesondere diese Schätzungen sind für die Freiberufler wichtig, denn wenn ich erst 2 Tage mir Infos reinhole, dann arbeite ich für lau.

Auch in den Startups gibt es Never-ending-changing requirements. Wenn man da gewisse Ideen erst zu Ende durchdenken und modellieren würde, wären diese schon wieder veraltet. Auch weiß Marketing / PM meist selbst nicht so genau was Sie wollen. Was dann tun?

@Ulf … das Szenario, das Du beschreibst ist der kniffligste Fall. So oder so führt aber kein Weg am „für lau“ vorbei. Konkret für Webseiten lohnt es sich vorab ein paar Beispiele (oder Referenzen) in der Hinterhand zu haben. Dann lässt sich auf die unspezifische Frage eine klare Antwort geben: „Beispiel A gibts für x Tage“ „Beispiel B gibts für y Tage“ … jeweils verbindliche Designvorgaben und Grafiklieferungen vorausgesetzt. Wenn Design auch unklar ist einen Aufwand pro Korrekturlauf nennen (Erfahrungswert aus abgeschlossenen Aufträgen). Bei einer solchen Schätzung kommt zwar keine fixe Zahl raus, der Kunde hat aber einen Anhaltspunkt und als Dienstleister geht man kein unkalkulierbares Risiko ein.

Wenn die Anforderungen sich wirklich schnell ändern führt m.E. kein Weg an agiler Entwicklung (z.B. Scrum) vorbei. Der Trick dabei ist, dass in kleinen Häppchen spezifiziert und entwickelt wird, die Schätzung für die kleinen Häppchen ist dann erheblich leichter.

Ich möchte an dieser Stelle auch noch auf den Artikel von Joel Spolsky „Evidence Based Scheduling“ ( http://www.joelonsoftware.com/items/2007/10/26.html ) verweisen. Er stellt einen Ansatz vor, mit dem die Schätzungen aus vergangenen Projekten mathematisch/statistisch korrekt berücksichtigt werden, um für jeden Entwickler einen „Abweichungsfaktor“ der Schätzungen zu berechnen.