Schätzproblematik
Dieser Artikel wird derzeit von einem Autor gründlich bearbeitet. Die Inhalte sind daher evtl. noch inkonsistent.
Aufwandsschätzungen können zu meist nicht ordentlich abgeschlossen werden, obwohl eine mangelhafte Schätzung keine gute Basis für ein Projekt darstellt. Es gibt vielerlei Gründe warum gute Schätzungen bereits von vornherein nahezu unmöglich sind. Im folgenden seien einige davon genannt.
So werden zum einem Erfahrungen, welche mit ähnlichen Projekten gemacht werden zurückgewiesen oder nicht beachtet, da man der Auffassung ist, dass dieses Problem nicht auftreten würden oder man es gar dieses Mal besser machen würde. Weiterhin wird eine Schätzung oftmals als Verhandlungssache ausgelegt um sich bei Vertragsverhandlungen erfolgreich durchsetzen zu können um letztendlich den Zuschlag für das Projekt zu bekommen.
Ein weiterer fataler Fehler ist es, das Schätzobjekt, also das entstehende Produkt, nicht genau genug zu betrachten. Bei der Betrachtung eines Schätzobjektes gilt: je mehr Informationen über das Schätzobjekt je genauer die Schätzung. Als Informationen kann man sich aus Softwaresicht beispielsweise die Anzahl und den Umfang von Schnittstellen, die Abläufe aus Benutzersicht (Use Cases) oder das Datenmodell des entstehenden Produktes vorstellen.
Bei Zeit und/oder Kostendruck können diese Informationen nicht so genau erfasst werden, da sich die Entwickler nicht lange genug mit dem Produkt auseinander setzen können, wie es eigentlich für eine erfolgreiche Schätzung nötig wäre.
In manchen Fällen ist nicht mal der Zeit und/oder Kostendruck ausschlaggebend für eine ungenügende Schätzung. So werden teilweise ansprechend durchdachte Schätzungen durch den Projektleiter abgelehnt, da diese schlicht und ergreifendend eine zu lange Entwicklungsdauer zu Tage bringen.
Die hier genannten Gründe bilden nur einen kleinen Ausschnitt an Problemen, welche eine vernünftige Schätzung nicht realisierbar machen. Daher ist es nicht verwunderlich, dass nach einer Studie der Standish Group aus dem Jahre 2003 gut zwei Drittel aller Projekte als misslungen anzusehen sind.
Quellen
Wenn die Definitionen und/oder die Anmerkungen nicht von einem selbst stammen, sollte man die Quellen angeben (das sind natürlich nur Beispiele, keine echten Quellen dieses Artikels :-) ):
- Hinz und Kunz, "Der Bau einer Musterseite", 7. Auflage, Wiki-Verlag, 1931
Besser ist es spezielle Quellendokumente zu erstellen (und diese dann auch mit Inhalt zu füllen):
