Unter Aufwandsschätzung (Aufwandschätzung, Aufwandsabschätzung) versteht man die Vorhersage über den erforderlichen Aufwand,

1. … um ein Ziel zu erreichen.
2. … um einen Plan durchzuführen.
3. … um ein (Software−) Produkt zu entwicklen.

Unter Schätzung versteht man einen ermittelten Näherungswert, der mit einer bestimmten Wahrscheinlichkeit in einem bestimmten Bereich liegt (z. B.: 8 Mannmonate, bestenfalls zu 50% 7 Mannmonate und schlimmstenfalls zu 75% 10 Mannmonate). Eine so genannte Einpunktschätzung hingegen wäre die Bestimmung eines Näherungswertes ohne Bereichsangabe, der mit hundertprozentiger Wahrscheinlichkeit nie erreicht werden kann (z. B.: exakt 5 Mannmonate).
Unter Aufwand versteht man die Dauer oder die Kosten, die erforderlich sind oder waren, um etwas zu erreichen. Im Zusammenhang mit der Produktentwicklung versteht man unter Aufwand die Entwicklungsdauer, über die man auf die Entwicklungskosten schließen kann.
Primär schätzt man den Aufwand, um ein Ziel zu erreichen. Deshalb macht eine Schätzung erst dann Sinn, wenn das zu erreichende Ziel und die Voraussetzungen, von denen der Schätzer ausgehen darf, geklärt sind.
Beispiel/Template:

1. Das Ziel Z wird unter der Voraussetzung V in X Manntagen plus/minus Y Manntagen mit der Wahrscheinlichkeit W erreicht.

Meist muss der Aufwand geschätzt werden, um dem potentiellen Kunden ein Angebot unterbreiten zu können. Der Kunde (Auftraggeber) möchte bereits vor der aufwändigen Entwicklung die voraussichtlichen Entwicklungskosten sowie die Entwicklungsdauer kennen. Er möchte wissen, wie viel er unterm Strich bezahlen und wie lange er auf die Auslieferung warten muss. Eine Aufwandsschätzung liegt aber auch im Interesse des Auftragnehmers, um beispielsweise prüfen zu können, ob die vorhandenen Kapazitäten ausreichen oder ob die Wirtschaftlichkeit einer Entwicklung für ein bestimmtes Produkt gegeben ist. Das zu entwickelnde Produkt muss sich in einer bestimmten Zeit amortisieren.
Oft wird der Aufwand anhand gegebener Anforderungen, die an das neu zu erstellende Produkt gestellt werden, geschätzt. Im günstigen Falle handelt es sich bei den Anforderungen um ein Pflichtenheft und im ungünstigen Falle um ein Lastenheft. Je genauer die Angaben der Anforderungen, desto genauer die Aufwandsschätzung. Kennt der Schätzer ein ähnliches Referenzprojekt, fällt die Aufwandsschätzung selbstverständlich genauer aus. Der Schätzer kann hierbei auf reale Erfahrungswerte zurückgreifen.

Unter Hausnummer versteht man in der Regel eine grobe Aufwandsschätzung bezüglich der Entwicklungskosten.
Hierbei geht es nicht darum, dem Kunden den zu erwartenden Betrag auf den Cent genau zu nennen. Der Kunde braucht eine schnelle Kostenschätzung, die nicht vollkommen exakt sein muss. Mit der Hausnummer legt der Schätzer lediglich die Größenordnung der Kosten eines neu zu entwickelnden Produkts fest.

Du willst also wissen, was da steht?
Wenn nun einer zu mir kommt, der wissen will, wieviel etwas kostet, was es noch gar nicht gibt, dann kann ich ihm das sagen. Zum Beispiel willst du einen Wunglsul kaufen. Du weißt aber nicht, wie viel ein Wunglsul kostet, weil es den noch gar nicht gibt. Dann kommst du einfach zu mir, und ich werde dir sagen, wie viel Geld du für einen Wunglsul mitbringen musst. Natürlich ist es nötig, dass du mir etwas näher erklärst, was ein Wunglsul ist, weil ich jetzt nicht genau weiß, was du darunter verstehst. Aber wenn du mir genau sagen kannst, was ein Wunglsul ist, dann kann ich dir auch den Preis dafür ausrechnen. Und wie das geht, steht in diesen dicken Büchern: [SWSCHäTZUNG] und [SWTECHNIK].

Es ist eine äußerst verantwortungsvolle und ebenso anspruchsvolle Aufgabe, den zu erwartenden Aufwand zur Entwicklung eines Software−Produkts abzuschätzen. Wenn sich der Schätzer verschätzt, kann das verheerende Folgen nach sich ziehen. Schlimmstenfalls hängt von der Aufwandsschätzung das Überleben einer Firma ab. Es ist deshalb unbedingt erforderlich, die Aufwandsschätzung so realistisch wie möglich zu halten.

Nicht immer stehen dem Schätzer die zur Schätzung notwendigen Mittel zur Verfügung. Frameworks, Komponenten und Hilfsmittel, die zur Entwicklung eines Software−Produkts benötigt werden, sind während der Aufwandsschätzung nur zum Teil vorhanden. Hier ist der Schätzer teilweise gezwungen, ins Blaue hineinzuschätzen. Auch unvollständige Anforderungen machen eine genau Schätzung nahezu unmöglich, bestenfalls gelangt man zu einer verlässlichen Hausnummer, die die Größenordnung des Aufwandes widerspiegelt.

Man dürfte annehmen, dass der Schätzer als Entwickler den Aufwand höher schätzt als erforderlich. Doch dem ist in der Regel nicht so: Der zu erwartende Aufwand wird von den meisten Entwicklern um 30 Prozent zu optimistisch geschätzt. [SWSCHäTZUNG S. 79]
Doch damit nicht genug. Der Manager neigt dazu, diese optimistische Schätzung nochmals zu Gunsten des Kunden um etwa 10 bis 20 Prozent nach unten zu setzen. Was dabei herauskommt, liegt auf der Hand: Der Kunde freut sich über das günstige Angebot, der Entwickler — geplagt von schlaflosen Nächten — hat es mit einem unrealistischen Projektplan zu tun. Dabei sei erwähnt, dass viele Projekte nur aufgrund des hohen Zeitdrucks scheitern.

Erfahrene Entwickler sind mit allen Wassern gewaschen. Sie haben schon bei einigen Projekten mitgewirkt und wissen genau, was und wie viel sie in einer bestimmten Zeit schaffen. Sie wissen auch, wann und wo sie sich verschätzt haben und welche Schätzungen unrealistisch waren.

Jede Software bringt Neuerungen mit sich, in die sich der Entwickler erst einarbeiten muss. Die Einarbeitung in unbekannte Strategien und Lösungen erfordert selbstverständlich Zeit (Forschungsaufwand). Auch dieser Aufwand muss geschätzt werden, wenn man als Schätzer realistisch sein will. Die Lernkurve ist durchaus ein Bestandteil einer vollständigen Schätzung.

Ein häufig begangener Fehler ist, dass eine Schätzung abgegeben wird, ohne den eigentlichen Entwickler miteinzubeziehen. Der Entwickler steht dann vor einem vollendeten Projektplan, der nicht auf seine Fähigkeiten abgestimmt ist. In diesem Fall braucht sich der Projektleiter nicht wundern, wenn der Aufwand unverhältnismäßig höher ausfällt.

Zwei unabhängige Schätzungen führen zu unterschiedlichem Aufwand. Will der Projektleiter auf der sicheren Seite bleiben, so ist es sinnvoll, ein und dasselbe Projekt von mehreren Stellen unabhängig schätzen zu lassen. Im Folgenden werden die unterschiedlichen Schätzungen analysiert und zu einer neuen Schätzung vereint. Die Vorteile dabei liegen auf der Hand: Es ist unwahrscheinlich, dass aufwandsabhängige Einflussfaktoren übersehen werden, das Aufspüren von zu optimistisch oder auch zu pessimistisch geschätzten Programmteilen fällt leichter usw.

Teammeetings kosten auch Zeit. Beispielsweise kostet eine einstündige Sitzung mit acht Personen genau einen ganzen Arbeitstag, an dem nicht aktiv entwickelt wird. In der Praxis ist eine einzige Stunde für ein Acht−Personen−Meeting zu wenig. Hat man es mit einem großen Projekt zu tun, sollte man die voraussichtlichen Teammeetings (eventuell großzügig) miteinplanen; dasselbe gilt selbstverständlich auch für betriebliche Weihnachtsfeiern und andere Festlichkeiten.

Der Preis kann nicht zu hoch ausfallen, wenn realistisch geschätzt wurde. Was bringt es dem Auftragnehmer, wenn er einen Auftrag an Land zieht, für den der Schätzer höhere Kosten ansetzt als tatsächlich eingenommen werden? Der Schätzer muss hier gegebenenfalls Überzeugungsarbeit leisten.

Einfache Tipps zur Aufwandsschätzung finden Sie hier.

Die wichtigste Faustregel. Der Schätzer braucht immer etwas, was er zählen kann — sei es die im Pflichtenheft stehenden Funktionen, die erforderlichen Datenbanktabellen oder die Datensätze einer zu übernehmenden Datenquelle.
Hier gilt der Grundsatz:

1. Wer zählen kann, kann auch schätzen!

Diese Regel sollten Projektleiter nie vergessen, denn sie bestimmen letztendlich, welche der verfügbaren Personen schätzen soll. Für ein besonders genaues Schätzergebnis gilt der Grundsatz:

1. Je erfahrener der Schätzer, desto genauer seine Schätzung!

Verkalkuliert man sich bei kleineren Projekten, kann man das eventuell noch verkraften. Verschätzt man sich bei großen Projekten, bedeutet dies das Aus!
Deshalb gilt hier der Grundsatz:

1. Je größer das Projekt, desto wichtiger eine genaue und vollständige Schätzung!

Die Kommunikationszeit zwischen den Teammitgliedern verhält sich exponentiell zur Teamgröße.

1. Je größer das Team, um so mehr Kommunikationszeit muss man einplanen!

In der Testphase wird die Software „auf Herz und Nieren” geprüft. Im Idealfall heißt das, dass für jede einzelne, implementierte Methode mindestens ein Testfall implementiert werden muss.

1. Je ausführlicher die Tests, desto höher die Qualität der Software.

Jedoch bleibt die Testphase manchmal auf der Strecke liegen, weil es an Zeit fehlt oder kein Geld mehr zur Verfügung steht. In einem solchen Fall leidet nicht nur die Qualität der Software, sondern auch der Ruf des Entwicklerteams.
Der Schätzer sollte für die Testphase etwa die gleiche Zeitspanne wie für die Implementationsphase ansetzen. Unterschätzen Sie die wichtige Testphase nicht!

Manchmal wird einfach geschätzt, ohne überhaupt die Ausgangsbasis richtig geklärt zu haben. Deshalb sollten zunächst erst folgende Fragen durch ein Gespräch geklärt werden:

• Welches Ziel muss erreicht werden?
  (z. B.: Endversion, Prototyp, Kundenpräsentation, firmeninterne Präsentation etc.)
• Welche Voraussetzungen sind gegeben?
  (z. B.: Teamqualifikationen, Teamgröße, Technologie etc.)

Sie fahren mit folgender Einstellung deutlich besser und glaubwürdiger:

1. Ohne vorher darüber gesprochen zu haben, werde ich nicht mehr schätzen!

Ein Gespräch dient dazu, an weitere, eventuell für die Schätzung entscheidende Informationen zu kommen. Die Schätzung bekommt mehr Qualität, wenn man diese an die Ansprüche des Auftraggebers anpasst.

Für weitere Faustregeln habe ich ein offenes Ohr — schreiben Sie mir doch einfach unter info@stefan−baur.de