Meine Schätzung Wird Stimmen
 
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern

Ein DenkFehler. Eine der interessantesten, schwierigsten und wichtigsten Detailaufgaben in Softwareprojekten ist die Aufwandsschätzung. Nirgendwo liegt so viel Risiko. Nirgends wirkt sich die persönliche Erfahrung und Intuition mehr aus.

Regel 1: Der Aufwand wird immer unterschätzt.
Regel 2: Dies ist sogar dann der Fall, wenn man Regel 1 berücksichtigt.

Wie schätzt man ein Softwareprojekt richtig? Kann man allgemeine Tipps geben oder ist das eine schwarze Kunst? Oder ist der einzig gangbare Weg ExtremeProgramming, wo die verantwortungsvolle, riskante Gesamtkostenschätzung vermieden wird?

Mögliche Probleme bei der Arbeitszeitschätzung (Kosten)

Mögliche Probleme bei der Realzeitschätzung (Liefertermine)
Erfahrungen

Erfahrung und Wunschdenkenbeiseiteschieben:
A: Es ist unvorstellbar, dass das vor Ablauf von 5 Monaten geschafft wird.
B: Es wird wohl 7 Monate in Anspruch nehmen.
C: Ein Zeitbedarf von mehr als 10 Monaten dürfte recht unwahrscheinlich sein.

Geht's dir da auch um die Trennung der reinen Arbeitszeitschätzung von der Realisierungszeit? Wir bieten z. B. Projekte immer nur mit Terminen an, die um den Faktor 2-4 über den theoretischen Realisierungszeiten liegen. Damit werden z. B. Anlaufzeiten, Verzögerungen durch den Kunden (Rückfragen, Testdaten, ...) oder Kooperationspartner (Interface-Spezifikationen, ...) berücksichtigt.

Nur Realisierungszeit im Unternehmen, aus Entwicklersicht geschätzt.
Wenn man abgezogen werden kann zwischendurch, ist die Zeit nicht mehr gleichauf zum Abgabetermin.

Denkfehler ja, aber ...

Es wird hier behauptet, die Ansicht "Meine Schätzung wird stimmen" sei ein Denkfehler. Das mag zwar sein, allerdings wird diese Ansicht erfahrungsgemäß kaum jemals vertreten. Wenn eine Person A an eine Person B eine Schätzung abzugeben hat, dann überlegt A eine Weile und teilt dann B seine Schätzung per "Hier ist meine Schätzung" mit, und nicht per "Hier ist meine Schätzung, und übrigens, sie wird stimmen.".

Ich weiß nicht. Jede Schätzung impliziert, dass der Schätzende den Schätzwert für den plausibelsten, also für richtig hält. Man kann natürlich dazusagen, welche Unsicherheit die Schätzung enthält. Wenn es aber um die Schätzung von Projektkosten geht - die ja letzlich irgendwann Basis für den Anbotspreis sind - dann muss man sich normalerweise schon auf eine Zahl festlegen. Eine gute Schätzung beginnt - in meinen Augen - bei ±30% gegen die Echtkosten. Alles was unter ±%20 liegt ist exzellent. Alles was unter ±10% liegt ist reines Glück.

Ja. Meinen Einwand hatte ich angebracht, weil ich annahm, es würde hier gemeint, "Meine Schätzung wird stimmen" wäre eine (in dieser Form) öfters anzutreffende Meinung. Jedoch merke ich gerade, dass das gar nicht der Fall ist, die Aussage vielmehr provokativ steht.

ExtremeProgramming

Oder ist der einzig gangbare Weg ExtremeProgramming, wo die verantwortungsvolle, riskante Gesamtkostenschätzung vermieden wird?

Wer sagt, in XP wird die Gesamtkostenschätzung vermieden?

Gibt es vor Projektbeginn eine Gesamtkostenschätzung?

Je nachdem, wie Du "vor Projektbeginn" definierst. ExtremeProgramming beginnt mit einer ExplorationsPhase, die genau dies zum Ziel hat.

Wenn der Kunde ständig in der Lage ist, Anforderungsgeschichten hinzuzufügen (oder zu entfernen), dann ist es im Prinzip auch nicht notwendig (und vom Auftragnehmer wahrscheinlich gar nicht erwünscht), die gesamten Anforderungen von Beginn an festzulegen. Damit ist normalerweise auch keine halbwegs zuverlässige Schätzung möglich.

Natürlich wird die Schätzung um so besser, je mehr AnforderungsGeschichten von Anfang an vorliegen - und ich kenne auch niemanden, der vorschlagen würde, bewusst Anforderungen unter den Tisch fallen zu lassen.
XP ermöglicht es lediglich dem Kunden, auch später noch alte Anforderungen gegen neue auszutauschen oder den Umfang des Projekts zu verändern. Es trägt damit dem Umstand Rechnung, dass sich Anforderungen einfach dadurch ändern können, dass sich die Umgebungsbedingungen des Projektes ändern (z. B. die Marktlage) und dass der Kunde während der Entwicklung viele Möglichkeiten hat, über seine Anforderungen zu lernen und sie zu verfeinern. Zudem nimmt es den Druck vom Team, gleich am Anfang alles perfekt hinzubekommen und verhindert damit eine AnalysisParalyse?.

Im Gegenteil, XP bietet gar eine dreiteilige Strategie, um obiges Problem recht erfolgreich zu minimieren:

  1. Akzeptieren, dass Menschen schwer in der Lage sind, absolute Aufwände zu schätzen, aber gut in der Lage, relative Aufwände miteinander zu vergleichen. Deswegen wird in XP vorzugsweise mit einheitenlosen Werten geschätzt. Wir wissen zwar anfangs nicht, wie lange eine "3" dauern wird, sind uns aber ziemlich sicher, dass es etwa dreimal so lange sein wird wie eine "1".
  2. Berücksichtigen, dass auch diese Schätzungen nicht immer perfekt sein werden - mal werden wir darüber, mal darunter liegen. Deswegen halten wir unsere Arbeitsschritte klein - möglichst in der Größenordnung von wenigen Tagen. Das führt sowohl dazu, dass die Schätzungen genauer werden, als auch dass sich aufgrund der Menge der Schätzungen Fehler ausmitteln.
  3. Wir versorgen uns möglichst früh mit Daten über unsere tatsächliche EntwicklungsGeschwindigkeit?. Wir entwickeln zwei Wochen an den wichtigsten Features und schauen dann, wieviele Punkte die Dinge wert sind, die wir geschafft haben. Im Sinne von WetterVonGestern gehen wir erstmal davon aus, dass wir diese Geschwindigkeit beibehalten werden und extrapolieren damit das Projektende. Dann entwickeln wir zwei Wochen lang weiter, schauen wiederum, was wir geschafft haben und korrigieren die Projektion. Von Iteration zu Iteration wird somit unsere Gesamtschätzung genauer werden.
Erfahrung zum Bestandteil des Prozesses machen

Vielfach ist und bleibt die Erfahrung ein Bauchgefühl des Projektleiters oder Senior Developers. Und je mehr Praxis diese Person hat, desto besser liegen die Schätzungen auch. Sie bleiben dennoch Schätzungen und sind stark personengebunden. Ein Weg der hilft, dieses zu umgehen, ist es, die Erfahrung zum Bestandteil eines Entwicklungsprozesses zu machen.

In einem Unternehmen bzw. einer Abteilung, welche(s) sich regelmäßig mit Projekten befasst, muss über genau diese Buch geführt werden. Es gilt, sowohl den Rahmen als auch Metriken so festzuhalten, dass sie später ausgewertet und in Verbindung gebracht werden können. Dies erlaubt für zukünftige Schätzungen auf eine größere Erfahrungsbasis für alle zurückzugreifen.

Dennoch muss allen Beiteiligten immer wieder deutlich gemacht werden, dass es sich um Schätzungen handelt. Diese können und müssen im Laufe des Projekts verfeinert werden, also ein inkrementelles Vorgehen auch bei den Schätzungen. So können dynamisch einlaufende Änderungen (EmbraceChange) mit in die neuen Schätzungen eingearbeitet, Auswirkungen verdeutlicht und Prioritäten neu gesetzt werden. -- FrankMüller


KategorieZumNachdenken
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Text dieser Seite ändern (zuletzt geändert: 5. August 2003 10:45 (diff))
Suchbegriff: gesucht wird
im Titel
im Text