Methode nach Unsicherheit wählen: Aufwandsschätzung für Softwareprojekte

Eine Schätzung für ein Softwareprojekt gehört als Bandbreite mit Konfidenzstufen präsentiert, nicht als einzelne Zahl: ein P50-Basisfall, ein P70-Erwartungsfall und eine P90-Obergrenze für alles, was zum Festpreis angeboten wird. Die Methode richtet sich danach, was Sie nicht wissen. Bei festem Umfang und vertrauter Technologie genügt eine Bottom-up-Aufschlüsselung. Bei hoher Unsicherheit braucht es die Drei-Punkt-Schätzung (PERT) und, für die Risikoberichterstattung auf Portfolioebene, eine Monte-Carlo-Simulation. Kalibrieren Sie jede Zahl an Ihren eigenen abgeschlossenen Projekten, bevor sie das Haus verlässt.

---

Kurz zusammengefasst:

• Eine Bandbreite mit Konfidenzstufen (P50, P70, P90) bildet Unsicherheit besser ab als eine einzelne fixe Schätzung, besonders bei riskanten Modulen wie Anbindungen von Drittanbietern.

• Die Kalibrierung an den historischen Daten Ihres Teams erhöht die Genauigkeit, weil sie systematisches Unter- oder Überschätzen korrigiert.

• Die Drei-Punkt-Schätzung (PERT) für Module mit hoher Unsicherheit und Monte-Carlo-Simulationen liefern eine wahrscheinlichkeitsbasierte Sicht auf Termine und Kosten.

• Wer den Umfang in detaillierte Aufgaben zerlegt und die riskantesten Bereiche markiert, erhält nachvollziehbare und realistische Schätzungen und senkt das Risiko grosser Abweichungen.

• Wiederholtes Nachschätzen während des Projekts, mit aktualisiertem Umfang und aktualisierten Meilensteinen, verengt die Unsicherheit und erhält das Vertrauen der Beteiligten.

---

Was ist Aufwandsschätzung für Softwareprojekte, und warum scheitert eine einzelne Zahl?

Die Aufwandsschätzung für Softwareprojekte sagt Aufwand, Dauer, Kosten und Risiko eines Entwicklungsprojekts voraus, bevor die Arbeit beginnt, und verfeinert diese Voraussage, sobald mehr bekannt ist. Der Fehler, den die meisten Teams machen: Sie behandeln das als Prognoseübung, die eine einzige Zahl ausspuckt. Tatsächlich ähnelt es eher einer Risikomodellierung, die eine Verteilung liefert.

Eine Punktschätzung, etwa «12 Wochen», suggeriert eine Präzision, die es nicht gibt. Sie sagt den Beteiligten nichts darüber, ob 12 Wochen ein Münzwurf oder eine fast sichere Sache sind. Eine Bandbreite mit benannten Konfidenzstufen macht das Gegenteil: Sie zeigt der Kundschaft genau, wie viel Puffer sie kauft und warum. Genau darum geht es bei Schätzmethoden wie PERT und Monte Carlo. Sie machen Sie nicht klüger in Bezug auf die Zukunft. Sie machen Ihre Unsicherheit sichtbar statt versteckt, und erst das erlaubt es der Kundschaft, über das tatsächliche Risiko zu verhandeln statt bloss über die Zahl.

Der Fachbegriff dafür, wie er in wissenschaftlichen Arbeiten oder in Leitfäden des Software Engineering Institute auftaucht, lautet software effort estimation oder software cost estimation, also Aufwand- beziehungsweise Kostenschätzung. Beide Begriffe decken dasselbe Feld ab wie «Aufwandsschätzung für Softwareprojekte», mit leicht anderem Schwerpunkt auf der Achse Aufwand/Zeit gegenüber der Kostenachse. Alle drei Bezeichnungen werden in diesem Text gleichbedeutend verwendet.

Der Fahrplan: So bauen Sie eine Schätzung, die den Realitätstest übersteht

Die meisten Fehlschätzungen sind keine Rechenfehler. Es sind Fehler im Vorgehen: Jemand wählt eine Methode, wendet sie einmal an und präsentiert eine Zahl ohne jeden Kontext.

1. Machen Sie zuerst einen Top-down-Plausibilitätscheck. Bevor jemand eine Tabelle öffnet, vergleichen Sie das Projekt mit zwei oder drei ähnlichen Umsetzungen aus der Vergangenheit. Wenn eine vergleichbare E-Commerce-Plattform Ihr Team letztes Jahr vier Monate gekostet hat, sollte ein ähnlich zugeschnittenes Projekt dieses Jahr nicht mit sechs Wochen oder vierzehn Monaten zurückkommen. Diese Übung dauert einen Tag und deckt völlig falsche Annahmen auf, bevor sie in eine detaillierte Schätzung einfliessen.

2. Zerlegen Sie den bestätigten Umfang in einen Projektstrukturplan (PSP). Für alles, was Sie tatsächlich offerieren, zerlegen Sie das Projekt in Aufgaben, die klein genug sind, um sie in Entwicklertagen oder Story Points zu schätzen. Das ist Ihre Bottom-up-Schätzung, und es ist die einzige Methode, die jede Position nachvollziehbar macht, wenn die Kundschaft fragt: «Warum kostet der Bestellprozess mehr als der Produktkatalog?»

3. Markieren Sie die ein bis drei riskantesten Module. Jedes Projekt hat eine Handvoll Komponenten, bei denen niemand sicher ist: eine Schnittstelle eines Drittanbieters mit dürftiger Dokumentation, eine Datenmigration mit unbekannter Datenqualität, eine Funktion, die im Team noch niemand gebaut hat. Wenden Sie die Drei-Punkt-Schätzung (PERT) nur auf diese Module an, nicht auf das ganze Projekt.

4. Kalibrieren Sie an Ihrer eigenen Historie. Holen Sie sich die Ist-gegen-Soll-Daten aus drei bis fünf vergleichbaren abgeschlossenen Projekten und berechnen Sie einen Kalibrierungsfaktor. Wenn Ihr Team Backend-Integrationen historisch um 20% unterschätzt hat, wenden Sie diesen Faktor jetzt an, nicht im Nachhinein.

5. Rechnen Sie Monte Carlo, wenn das Publikum eine Wahrscheinlichkeitskurve braucht. Für Risikoberichte auf Verwaltungsratsebene oder ein ganzes Projektportfolio speisen Sie Ihre Verteilungen auf Aufgabenebene in eine Monte Carlo simulation ein und erhalten eine vollständige Wahrscheinlichkeitskurve statt drei statischer Punkte.

6. Präsentieren Sie Bandbreite, Annahmen und ein empfohlenes Budget. Geben Sie nie eine Zahl allein heraus. Das Ergebnis sollte immer enthalten:

• die P50/P70/P90-Bandbreite in Zeit und Kosten

• die konkreten Annahmen, auf denen die Bandbreite beruht (Umfang, Teamzusammensetzung, Abhängigkeiten von Dritten)

• einen empfohlenen Vertragspreis, angesetzt auf P90, wenn das Mandat einen festen Umfang hat

Diese Abfolge dauert länger als Raten, kostet aber selbst bei einem mittelgrossen Projekt selten mehr als ein bis zwei Tage Gesamtaufwand. Und sie macht den Unterschied zwischen einer Schätzung, die Sie in einer Verhandlung über den Umfang verteidigen können, und einer, für die Sie sich im dritten Monat entschuldigen.

Wie funktionieren Schätzmethoden tatsächlich?

Jede der folgenden Methoden löst ein anderes Problem. Sie zu verwechseln, also PERT einzusetzen, wo ein schneller Plausibilitätscheck reicht, oder einem parametrischen Modell ohne Kalibrierungsdaten zu vertrauen, ist die eigentliche Ursache der meisten Fehlschätzungen.

Bottom-up-Schätzung (PSP und Story Points)

Die Bottom-up-Schätzung zerlegt das Projekt in einzelne Aufgaben oder User Stories, schätzt jede davon und addiert die Ergebnisse. Für eine Offerte mit festem Umfang ist das das Rückgrat: Es ist die einzige Methode, mit der Sie eine Gesamtsumme auf konkrete Lieferergebnisse zurückführen können, wenn die Kundschaft die Zahl hinterfragt.

Das Vorgehen: Zerlegen Sie die Arbeit in Aufgaben, die klein genug sind, dass eine einzelne Person eine davon plausibel in einem Tag bis einer Woche erledigt. Schätzen Sie jede Aufgabe entweder direkt in Entwicklertagen oder in Story Points und rechnen Sie die Punkte anschliessend mit der tatsächlichen velocity Ihres Teams in Zeit um, also den durchschnittlich pro Sprint abgeschlossenen Story Points über ein gleitendes Fenster von drei bis sechs Sprints.

Wenn die Arbeit etwas ähnelt, das Ihr Team schon gebaut hat, liegen Bottom-up-Schätzungen typischerweise innerhalb von rund 15% der tatsächlichen Werte. Wenn nicht, bricht diese Genauigkeit schnell ein, und genau deshalb ist der Schritt mit dem Markieren der riskanten Module im Fahrplan oben so wichtig. Die Bottom-up-Schätzung ist präzise bei dem, was sie kennt, erfasst aber die Unsicherheit dort nicht, wo Erfahrung fehlt.

Top-down- und Analogieschätzung

Die Analogieschätzung vergleicht das neue Projekt mit einem oder mehreren ähnlichen abgeschlossenen Projekten und skaliert die Schätzung entsprechend. Sie ist schnell, meist eine Sache von wenigen Stunden, und ihre einzige echte Aufgabe ist es, Grössenordnungsfehler zu erwischen, bevor sie eine detaillierte Schätzung infizieren.

Die Wahl guter Referenzprojekte zählt hier mehr als jede Formel. Ein Referenzprojekt muss bei Art des Umfangs, Technologie-Stack und Teamzusammensetzung passen, nicht bloss «war auch eine Webanwendung». Zwei E-Commerce-Projekte mit gleicher Seitenzahl können sich um Monate unterscheiden, wenn eines eine massgeschneiderte Lagerbestandssynchronisation braucht und das andere nicht.

Drei-Punkt-Schätzung (PERT)

PERT verlangt drei Zahlen pro Aufgabe: optimistisch (O), wahrscheinlichster Fall (M) und pessimistisch (P). Der expected value is calculated as (O + 4M + P) / 6, was den wahrscheinlichsten Fall stark gewichtet und die Ränder trotzdem berücksichtigt. Die Standardabweichung beträgt (P − O) / 6 und zeigt Ihnen, wie breit die Unsicherheit bei genau dieser Aufgabe wirklich ist.

Setzen Sie PERT gezielt ein. Es über jede Aufgabe eines Projekts laufen zu lassen, erzeugt nur Rauschen, denn bei gut verstandenen Aufgaben sind die Fehler ohnehin klein, und der echte Nutzen von PERT zeigt sich bei der Handvoll Module, bei denen niemand sicher ist. Wenden Sie es auf die riskanten Punkte an, die Sie in Schritt drei des Fahrplans markiert haben, und fassen Sie diese Verteilungen zu einer Summe für diesen Teil des Projekts zusammen.

Praxistipp: Lassen Sie sich O, M und P von Ihren drei Schätzenden unabhängig voneinander geben, bevor Sie in der Gruppe diskutieren. Ankereffekte entstehen im Raum sehr schnell, und in dem Moment, in dem eine erfahrene Entwicklerin eine Zahl ausspricht, driftet die «unabhängige» Schätzung aller anderen still in diese Richtung.

Planning Poker und Wideband Delphi

Beim Planning Poker schätzt ein interdisziplinäres Team eine Story gleichzeitig mit Karten (oft nach Fibonacci: 1, 2, 3, 5, 8, 13), deckt zeitgleich auf und diskutiert dann die Ausreisser, bis ein Konsens entsteht. Wideband Delphi ist der ältere, formellere Vorläufer: mehrere Runden anonymer Schätzung mit moderierter Diskussion zwischen den Runden.

Bei keiner der beiden Methoden geht es wirklich um die Mathematik. Beide existieren, um verborgene Annahmen ans Licht zu bringen. Wenn ein Backend-Entwickler eine Story mit 3 Punkten schätzt und eine Frontend-Entwicklerin dieselbe Story mit 13, offenbart die anschliessende Diskussion meist eine Uneinigkeit über den Umfang, die niemandem aufgefallen war, und keinen Schätzfehler. Genau das ist das Ergebnis, das festzuhalten sich lohnt.

Parametrische Modelle: COCOMO II, Function Point Analysis, COSMIC

Parametrische Modelle leiten eine Schätzung rechnerisch aus Grössen- und Komplexitätswerten ab. COCOMO II berechnet Personenmonate aus Codezeilen oder Function Points, Kostentreibern und Skalierungsfaktoren; Function Point Analysis und COSMIC bemessen das Projekt, indem sie Eingaben, Ausgaben und Datenstrukturen zählen statt Codemenge.

Diese Modelle müssen an Ihren eigenen abgeschlossenen Projekten kalibriert werden, sonst sind sie nichts wert. Ein COCOMO-II-Koeffizient, der auf den Java-Grossprojekten eines anderen Unternehmens eingestellt wurde, sagt sehr wenig über Ihr Team aus, das eine React-Native-App baut, und das Software Engineering Institute is explicit that a cost model is only as good as the data used to calibrate it. Parametrische Modelle rechnen sich bei wiederholbaren Projekten im Unternehmensumfeld, bei denen Sie fünf oder mehr frühere Projekte zur Kalibrierung haben. Für ein neuartiges Produkt ohne interne Historie taugen sie wenig.

Monte-Carlo-Simulation

Monte Carlo nimmt die Verteilungen, die Sie mit PERT (oder aus historischen Streuungsdaten) gebildet haben, und simuliert Tausende von Ergebnissen, indem es aus der Wahrscheinlichkeitsspanne jeder Aufgabe zieht und die Resultate jedes Mal summiert. Das Ergebnis ist eine vollständige Wahrscheinlichkeitskurve: die prozentuale Chance, unter einem beliebigen Budget oder Termin zu bleiben, statt drei statischer Kontrollpunkte.

Für ein internes Werkzeug mit vier Wochen Aufwand ist das überdimensioniert. Es lohnt sich, wenn ein Projektportfolio eine Risikoberichterstattung auf Verwaltungsratsebene braucht oder wenn eine einzelne Festpreisofferte mit hohem Einsatz eine belastbare Wahrscheinlichkeitsaussage jenseits von «wir denken, P90 liegt bei 20 Wochen» erfordert.

Ein durchgerechnetes Beispiel

Nehmen wir an, ein neu gestalteter Bestellprozess umfasst 40 gut verstandene PSP-Aufgaben und einen riskanten Punkt: die Anbindung einer neuen Schnittstelle zur Betrugserkennung mit spärlicher Dokumentation. Die Bottom-up-Schätzung veranschlagt die 40 bekannten Aufgaben mit 60 Entwicklertagen. Die Historie aus zwei vergleichbaren Integrationen ergibt einen Kalibrierungsfaktor von 1,15, womit daraus 69 Entwicklertage werden. Für die Betrugserkennungsschnittstelle sammelt das Team O = 5, M = 10, P = 25 Tage. PERT ergibt einen Erwartungswert von (5 + 40 + 25) / 6 ≈ 11,7 Tagen und eine Standardabweichung von (25 − 5) / 6 ≈ 3,3 Tagen. Das Total P50 liegt bei rund 81 Tagen; P90 rückt wegen der breiten Streuung dieses Moduls näher an 88 bis 90 Tage. Das ist die Zahl, die in eine Festpreisofferte gehört.

Wann sollten Sie überhaupt eine Schätzung erstellen?

Schätzen ist kein einmaliges Ereignis zum Projektstart. Es ist eine wiederkehrende Tätigkeit, die präziser wird, sobald sich Unsicherheit auflöst. Und eine veraltete Schätzung als aktuell zu präsentieren, ist einer der schnellsten Wege, das Vertrauen der Beteiligten zu verlieren.

1. Beim ersten Kontakt liefern Sie eine grobe Grössenordnung (Rough Order of Magnitude). Eine Top-down-Analogieschätzung, in wenigen Stunden erstellt, gibt einer interessierten Kundschaft genug, um über den Schritt in die Analysephase zu entscheiden. Das ist ausdrücklich keine Offerte.

2. Nach der Analysephase liefern Sie eine detaillierte Bottom-up-Schätzung. Sobald Umfang, Integrationen und technische Randbedingungen dokumentiert sind, liefert eine PSP-basierte Schätzung mit PERT auf den riskanten Modulen die Bandbreite, über die Sie tatsächlich verhandeln.

3. Vor einer Festpreisofferte kalkulieren Sie auf P90. Alles, was als Fixpreis offeriert wird, gehört gegen das 90. Perzentil Ihrer Verteilung budgetiert, nicht gegen den Mittelwert. P50 bleibt intern als Ihre Arbeitserwartung; die Kundschaft sieht die Zahl, die die Lieferung absichert.

4. Danach in festem Rhythmus neu schätzen. Schätzen Sie nach der Freigabe des Designs neu, bei jedem grösseren Meilenstein und immer dann, wenn Änderungen am Umfang eine festgelegte Schwelle überschreiten, oft 10 bis 15% der ursprünglichen Schätzung.

Barry Boehms Unsicherheitstrichter ist die übliche Art, diesen Ablauf jemandem zu erklären, der sich darüber ärgert, dass eine frühe Zahl sich verschoben hat. Die Genauigkeit einer Schätzung verengt sich im Projektverlauf berechenbar: Eine Schätzung in der Frühphase kann um den Faktor vier in beide Richtungen danebenliegen, während eine Schätzung nach dem Detaildesign typischerweise innerhalb von rund 20% liegt. Wer diese Erwartung vorab schriftlich festhält, bevor je eine erste Zahl genannt wird, macht aus «Ihre Schätzung hat sich verändert» statt eines Glaubwürdigkeitsproblems einen erwarteten Teil des Prozesses.

Warum Schätzungen danebenliegen: die Fehlerquellen, die niemand einplant

Die meisten schlechten Schätzungen entstehen nicht durch falsche Mathematik. Sie entstehen durch vorhersehbare psychologische und organisatorische Fehlermuster, die unabhängig vom Können des Teams auftreten.

Der Planungsfehlschluss trifft alle, auch erfahrene Entwickler:innen. Menschen schätzen ihre eigene künftige Arbeit optimistisch ein, selbst wenn sie rational wissen, dass ähnliche frühere Arbeiten länger gedauert haben. Der Planungsfehlschluss bleibt über alle Erfahrungsstufen hinweg bestehen, und genau deshalb gibt es die Referenzklassenprognose als Korrektiv: Sie verankert Ihre Schätzung in den tatsächlichen Ergebnissen vergleichbarer früherer Projekte. Bauchgefühl allein behebt diese Verzerrung nicht. Daten von aussen schon.

Die eigene Intuition eines Teams zur Schwierigkeit eines Projekts gehört zu den unzuverlässigsten verfügbaren Grundlagen, gerade weil alle gleichzeitig derselben optimistischen Verzerrung unterliegen.

Ankereffekte unter Druck der Auftraggebenden verformen die Zahl unbemerkt. Wenn ein Auftraggeber sagt «wir hatten auf acht Wochen gehofft», bevor das Team überhaupt etwas geschätzt hat, verankert diese Zahl jede weitere Diskussion, auch wenn sie im tatsächlichen Umfang keinerlei Grundlage hat. Die Abhilfe ist prozessual: unabhängige Schätzungen einholen, bevor irgendeine Zielzahl im Raum ausgesprochen wird.

Aufwand für Integration und Prüfung wird fast immer zu tief angesetzt. Teams schätzen die Arbeit an den Funktionen sorgfältig und vergessen dann, dass das Verbinden von drei Systemen, das Schreiben der Tests und das Beheben dessen, was beim Zusammenschalten bricht, oft so viel kostet wie der Bau der Funktionen selbst.

Story Points werden behandelt, als hätten sie eine allgemeingültige Bedeutung. Ein Story Point ist keine Zeiteinheit, sondern eine Einheit relativer Grösse, die sich auf die Velocity eines bestimmten Teams bezieht. Schätzungen in Story Points über Teams hinweg zu vergleichen oder anzunehmen, «eine 5 bedeutet immer etwa zwei Tage», ist ein verbreiteter Missbrauch, der Prognosen leise verdirbt. Das ist der Kern der Debatte Story Points gegen Stunden: Punkte sind nützlich für ein stabiles Team, das seine eigene Velocity verfolgt, aber sie lassen sich ohne die spezifische Kalibrierung dieses Teams nicht direkt in eine Terminzusage gegenüber der Kundschaft übersetzen.

• Planungsfehlschluss und Ankereffekt verzerren sowohl das Urteil der Schätzenden als auch die anschliessende Verhandlung.

• Integration, Tests und Nacharbeit sind die Kategorien, die in einem PSP am häufigsten zu tief angesetzt werden.

• Parametrische Koeffizienten aus dem Kalibrierungsdatensatz eines anderen Unternehmens erzeugen Schätzungen, die präzise aussehen und still und leise falsch sind.

• Wer «Schätzung» mit «Zusage» gleichsetzt, nimmt sich den Verhandlungsspielraum, den eine Bandbreite gerade schaffen soll.

Die grösste strukturelle Abhilfe für alle vier Punkte: Schätzung und Zusage schriftlich trennen, jede Annahme benennen, auf der die Bandbreite beruht, und nie zulassen, dass der Wunschtermin eines Auftraggebers einen berechneten Termin ersetzt.

Wie machen Sie Schätzungen genauer?

Genauigkeit ist keine Frage der besseren Formel. Es geht darum, bessere Daten in die Formel zu speisen, die Sie ohnehin verwenden, und das so konsequent zu tun, dass sich die Daten über die Zeit aufsummieren.

1. Bauen Sie einen Referenzklassen-Datensatz auf. Erfassen Sie Ist-gegen-Soll-Ergebnisse Ihrer eigenen früheren Projekte, verschlagwortet nach Art des Umfangs, Technologie und Reifegrad des Teams. Ein brauchbarer Datensatz braucht mindestens drei bis fünf vergleichbare abgeschlossene Projekte, bevor der daraus abgeleitete Kalibrierungsfaktor Vertrauen verdient.

2. Berechnen und speichern Sie einen Kalibrierungsfaktor pro Projektkategorie. Wenn mobile Apps historisch 25% über der Bottom-up-Schätzung lagen und interne Verwaltungswerkzeuge punktgenau, dann sollte dieser Faktor beim nächsten ähnlichen Projekt automatisch angewendet werden.

3. Kombinieren Sie Methoden bewusst, statt sich für eine zu entscheiden. Comparative reviews of estimation techniques consistently find that hybrid approaches, mixing algorithmic and expert-based methods, outperform any single technique used alone. Nutzen Sie Top-down als Plausibilitätscheck, Bottom-up für die Nachvollziehbarkeit, PERT für die riskanten Punkte und Monte Carlo, wenn das Publikum eine Wahrscheinlichkeitskurve braucht.

4. Präsentieren Sie immer P50/P70/P90 statt einer einzelnen Zahl, mit benannten Annahmen. Eine kalibrierte Bandbreite mit ausdrücklichen Annahmen macht den Fehler sichtbar und begrenzt, statt ihn zu verstecken und ihn während des laufenden Projekts anwachsen zu lassen. Kalkulieren Sie Festpreisangebote auf P90; arbeiten Sie nach Aufwand mit regelmässigen Kontrollpunkten, wenn die Kundschaft im Tausch gegen eine tiefere Obergrenze mehr Flexibilität verträgt.

5. Erfassen Sie bei jedem Projekt Schätzung gegen Ist und speisen Sie es in die Kalibrierung zurück. Eine Nachbetrachtung, die nirgends festgehalten wird, lehrt die Organisation nichts. Ein gemeinsam genutztes, verschlagwortetes Protokoll von Schätzung gegen Ist verwandelt «wir glauben, wir werden besser» in eine Zahl, die Sie der Kundschaft tatsächlich zeigen können.

Praxistipp: Verschlagworten Sie jedes abgeschlossene Projekt am Tag des Abschlusses nach Art des Umfangs, nicht sechs Monate später, wenn jemand die Daten für eine neue Offerte braucht. Die Erinnerung an Schätzungen verblasst schnell, und die entscheidenden Details, welches Modul länger dauerte und warum, verschwimmen innerhalb von Wochen.

Die comparative literature on effort estimation models stützt dieses Muster aus einer anderen Richtung: Algorithmische Modelle sind stark bei wiederholbarer, gut dokumentierter Arbeit, Expertenurteil ist stark bei neuartiger oder mehrdeutiger Arbeit, und keines gewinnt über alle Projekttypen hinweg. Hybride, kalibrierte Ansätze schneiden durchgehend besser ab als eine einzelne Methode für sich.

Welche Daten und Werkzeuge stützen bessere Schätzungen wirklich?

Die obigen Methoden sind nur so gut wie die Daten dahinter, und genau hier investieren die meisten Teams zu wenig. Dafür brauchen Sie keine Unternehmenssoftware. Sie brauchen die Gewohnheit, die richtigen Zahlen konsequent festzuhalten.

Der unverzichtbare Datensatz für jedes Projekt:

• Ist gegen Soll bei Dauer und Kosten, aufgeschlüsselt nach Modul oder Arbeitspaket

• Velocity pro Sprint bei agilen Teams, über ein gleitendes Fenster erfasst statt über einen einzelnen Sprint

• Fehler- und Nacharbeitsquoten, denn Nacharbeit gehört zu den am zuverlässigsten unterschätzten Kostenkategorien

• Anzahl der Schnittstellen und Integrationen, die bei Projekten über mehrere Systeme stark mit dem Terminrisiko korreliert

Schlanke Vorlagen decken das meiste ab, was ein mittelgrosses Team braucht: ein einfaches Bemessungsblatt im Stil der Function Point Analysis für die frühe Umfangsbestimmung, eine vierteljährlich aktualisierte Umrechnungstabelle von Entwicklertagen pro Story Point, ein Standardblatt für PERT-Eingaben mit O/M/P-Spalten pro riskanter Aufgabe und ein einfaches Monte-Carlo-Modell in einer Tabelle mit einer Erweiterung zur Zufallszahlenerzeugung.

Die meisten Teams können diesen ganzen Prozess in einer Tabellenkalkulation abwickeln, ergänzt um eine Skripterweiterung für die Monte-Carlo-Ziehungen, und zwar weit über den Punkt hinaus, an dem man eigene Software erwarten würde. Wechseln Sie erst dann zu einem schwereren Werkzeug für Schätzung oder Portfolioprognose, wenn Sie Simulationen über mehrere parallele Projekte rechnen und geteilte, prüfbare Daten brauchen statt einer Tabelle, die per E-Mail herumgereicht wird.

Die Datenqualität verbessert sich durch drei Gewohnheiten mehr als durch jede Werkzeugwahl: jedes Projekt beim Abschluss nach Typ und Technologie verschlagworten, die Annahmen hinter jeder Schätzung im Moment der Schätzung festhalten statt sie später zu rekonstruieren, und anonymisierte Kennzahlen lange genug aufbewahren, um die Referenzklasse aus drei bis fünf Projekten aufzubauen, die eine Kalibrierung tatsächlich verlangt.

Wie Ampersand Labs aus der Analysephase eine belastbare Bandbreite macht

Dass erfahrene Leute vom ersten Gespräch an dabei sind, hält eine Schätzung ehrlich. Wenn die Person, die den Umfang festlegt, dieselbe ist, die für die Lieferung geradesteht, und bis zur Übergabe beteiligt bleibt, bleibt die Lücke zwischen dem Offerierten und dem Gebauten klein. Diese Kontinuität verkürzt auch die Analysephase selbst, denn ein erfahrener Entwickler erkennt das riskante Modul schon in der ersten Arbeitssitzung und nicht erst nach drei Sprints.

Ein typischer Schätzablauf für den Bau eines MVP sieht so aus:

• Zuerst die Analysephase. Strukturierte Gespräche und eine technische Prüfung, um Umfang, Integrationen und Randbedingungen festzuzurren, bevor irgendeine Zahl aufgeschrieben wird.

• Danach kalibriertes Bottom-up. Eine PSP-basierte Schätzung, abgeglichen mit Ampersands eigener Historie vergleichbarer MVP-, Web- und Mobile-Projekte.

• PERT für die Module, die wirklich Risiko tragen. Anbindungen von Drittanbietern, Datenmigrationen oder alles wirklich Neuartige bekommt eine Drei-Punkt-Behandlung statt einer Schätzung aus dem Bauch.

• Eine Bandbreite, keine Zahl. Die Kundschaft erhält P50/P70/P90 samt den konkreten Annahmen, auf denen die Bandbreite beruht, damit eine spätere Änderung des Umfangs klare, nachvollziehbare Kosten hat.

Mandate für Organisationen wie UBS und die Stadt Lugano zeigen die Bandbreite dessen, wofür Ampersand Labs schätzt, von streng regulierten Integrationen im Unternehmensumfeld bis zu schnell bewegten Startup-MVPs. Fallstudien zu umgesetzten Projekten, darunter eine Plattform mit über 600 Websites für eine Schweizer Partei und ein Verwaltungssystem für Immobilienportfolios für Repa Immobiliare, zeigen, wie dieser Weg von der Analyse bis zur Lieferung in echten Mandaten abläuft.

Auch die Abweichung wird im Hintergrund erfasst: Die tatsächliche Lieferzeit im Vergleich zur ursprünglich offerierten Bandbreite fliesst in den Kalibrierungsfaktor für das nächste vergleichbare Projekt zurück. Das ist der weiter oben beschriebene Referenzklassen-Datensatz, aufgebaut aus der eigenen Projekthistorie von Ampersand Labs statt aus einem allgemeinen Branchenvergleich, und angewendet bei jeder neuen Offerte.

Holen Sie sich eine kalibrierte Schätzung, bevor Sie sich auf einen Termin festlegen

Ampersand Labs ist die Alternative zur klassischen Agenturofferte für Teams, die eine Zahl brauchen, die sie vor einem Verwaltungsrat oder Investor tatsächlich verteidigen können, und keinen groben Betrag, der nach drei Monaten still und leise wächst. Weil erfahrene Entwickler:innen die Analysephase selbst führen, statt die Umfangsbestimmung an eine Junior-Person abzugeben, spiegelt die Bandbreite, die Sie erhalten, ein technisches Urteil über Ihre konkreten Integrationen und riskanten Module wider und nicht eine Vorlage mal Anzahl Köpfe.

Wenn Sie ein MVP oder eine Web- und Mobile-App erwägen, ist der nächste Schritt ein Gespräch zur Analyse und keine Offerte ins Blaue. Ampersand Labs geht Ihren Umfang durch, markiert die ein bis zwei Module, die wirklich Unsicherheit tragen, und übergibt Ihnen eine P50/P70/P90-Bandbreite mit ausformulierten Annahmen. Für Teams, die noch verschiedene Zusammenarbeitsmodelle vergleichen, schlüsselt die Preisseite auf, wie Arbeit zum festen Umfang und Beratungsmandate aufgebaut sind, noch bevor es zu einem Gespräch kommt.

Quellen

• Software Engineering Institute is explicit that a cost model is only as good as the data used to calibrate it

• comparative literature on effort estimation models

• Comparative reviews of estimation techniques consistently find that hybrid approaches, mixing algorithmic and expert-based methods, outperform any single technique used alone

• velocity

Häufige Fragen

Welche Software wird für die Aufwandsschätzung von Softwareprojekten eingesetzt?

Die meisten Teams beginnen mit Tabellen, die um einen Projektstrukturplan, Spalten für PERT-Eingaben und eine Erweiterung für Monte-Carlo-Simulationen herum aufgebaut sind, denn damit sind die wichtigsten Schätzmethoden ohne zusätzlichen Aufwand abgedeckt. Grössere Organisationen, die Kalibrierungen mit COCOMO II oder Function Point Analysis fahren, setzen manchmal spezialisierte Software für parametrische Schätzungen ein, sobald genug historische Projektdaten den Aufwand rechtfertigen. Das Werkzeug zählt weit weniger als die Kalibrierungsdaten dahinter.

Wie führt man eine Kostenschätzung für ein Softwareprojekt durch?

Beginnen Sie mit einem Top-down-Vergleich mit ähnlichen früheren Projekten, um Fehler in der Grössenordnung zu erwischen, und erstellen Sie dann für den bestätigten Umfang eine detaillierte Bottom-up-Schätzung aus einem Projektstrukturplan. Wenden Sie die Drei-Punkt-Schätzung (PERT) auf die ein bis drei riskantesten Module an, kalibrieren Sie das Total an den historischen Ist-gegen-Soll-Daten Ihres Teams und präsentieren Sie das Ergebnis als P50/P70/P90-Bandbreite statt als einzelnen Betrag.

Wie schätzt man den Zeitbedarf für ein Softwareprojekt?

Zerlegen Sie das Projekt in Aufgaben, die klein genug sind, um einzeln geschätzt zu werden, und schätzen Sie dann entweder direkt in Entwicklertagen oder nutzen Sie Story Points, die Sie über die tatsächliche Velocity Ihres Teams umrechnen, also die durchschnittlich pro Sprint abgeschlossenen Punkte über ein gleitendes Fenster. Sammeln Sie für die riskantesten Aufgaben eine optimistische, eine wahrscheinlichste und eine pessimistische Schätzung und führen Sie diese durch die PERT-Formel, statt eine einzelne Zahl zu raten.

Was sind Softwareschätzungen?

Eine Softwareschätzung sagt Aufwand, Zeit, Kosten und Risiko voraus, die für den Bau einer Software nötig sind, ausgedrückt als Bandbreite mit Konfidenzstufen statt als eine fixe Zahl. Sie wird an mehreren Punkten im Leben eines Projekts verfeinert, beginnend mit einer groben Grössenordnung beim ersten Kontakt bis hin zu einer detaillierten, kalibrierten Bandbreite, sobald Analyse und Design abgeschlossen sind.

Soll ich in Story Points oder in Stunden schätzen?

Story Points eignen sich gut für ein stabiles Team, das seine eigene Velocity von Sprint zu Sprint verfolgt, denn sie messen relative Grösse statt absoluter Zeit und passen sich automatisch an, wenn sich das Tempo des Teams ändert. Stunden oder Entwicklertage sind besser, wenn Sie eine Zusage gegenüber der Kundschaft brauchen oder Schätzungen über Teams hinweg vergleichen, denn die Bedeutung eines Story Points ist ausserhalb des Teams, das ihn vergeben hat, nicht standardisiert.

Empfohlen

• Software-Engineering-Dienstleistungen, Studio in Zürich

• Interims-CTO Zürich, Tech Lead auf Zeit und in Teilzeit

• Softwarewartung Zürich, monatliche Betreuung

• MVP-, Web- und Mobile-App-Entwicklung Zürich