Blog

Entmystifizierung der Schätzung für die Software-Produktentwicklung

Rajaram Parimi

Aktualisiert Oktober 22, 2025

4 Minuten

Software-Entwicklung & Software-Engineering ist ein bisschen wie das Befolgen eines Kochrezepts.

Für die Chefköche (jede Kategorie von Experten, von Straßenimbissen bis hin zu Hausköchen) ist es wichtig, dass sie aufgrund ihrer Erfahrung blitzschnell denken und handeln können. Wie so oft ist es ein einzelner Koch, der das Ruder in der Hand hält.

Wenn eine größere Gruppe verköstigt werden soll, übernehmen die Mitglieder des Kochteams verschiedene Aufgaben, um den Geschmack pünktlich, in guter Qualität und in ausreichender Menge zu liefern.

Auch die Softwareentwicklung durch eine Gruppe von Spezialisten ist ein anderes Spiel als durch eine Gruppe von Einzelpersonen (Diverse/Cross-Functional Teams).

Um sicherzustellen, dass das kombinierte Wissen einheitlich übernommen und optimal genutzt wird, kommt Software Engineering (auch bekannt als Rezept für Softwareentwicklung) zum Einsatz.

Schätzung in der Software-Produktentwicklung Von der scheinbar "unerwünschten Liste" der Elemente der Softwareentwicklung(von dem, was ansonsten eine Art kreatives Unterfangen ist), lassen Sie uns über Schätzungen sprechen (die Mengen im Rezept).

Genauso wie Rezepte über Generationen hinweg perfektioniert werden, entwickelt sich auch der Prozess der Schätzung allmählich und braucht einige Zyklen/Jahre, um zu reifen.

Schätzungsebene & Einheit(en)

Je nach Phase ist der Grad der Schätzung unterschiedlich. Bei einem grundlegenden Verständnis des zu erstellenden Gesamtkonzepts ist der Grad der Schätzung relativ hoch (mögliche Abweichung im Bereich von +/- 50%).

Wenn das Konzept auf die Anforderungen heruntergebrochen wird, nähert sich das Niveau der Schätzung dem möglichen Aufwand an (die Abweichung liegt wahrscheinlich im Bereich von +/- 25%).

Zum Zeitpunkt der Detaillierung der einzelnen Anforderung(en) in Arbeitspakete (Tasks) kommt die Schätzung dem möglichen Aufwand für die Realisierung der Anforderung am nächsten (Abweichung um +/- 5%).

Wenn die 5%ige Abweichung überraschend erscheint, sollten Sie nicht vergessen, dass es sich um eine Schätzung handelt.

In jeder Phase der Detaillierung, d.h. Konzept -> Anforderung -> Aufgabe, nimmt der Grad des Verständnisses zu, die Unsicherheit ist geringer und der Annäherungsprozess wird besser.

Um die Schätzungen über die verschiedenen Phasen hinweg abbilden zu können, ist es besser, eine Einheit zu verwenden, auf die während des gesamten Vorhabens Bezug genommen werden kann.

Wenn die Einheit (Tage/Stunden) über alle Phasen hinweg gleich bleibt, verbessert sich die Annäherung. Auch die eigentlichen Planungs- und Ausführungszyklen müssen sich auf diese Einheit stützen.

Ansatz für die Schätzung

Der Detaillierungsgrad ist in den verschiedenen Phasen des Lebenszyklus der Softwareentwicklung unterschiedlich
Die Schätzung auf verschiedenen Ebenen erfolgt auf der Grundlage des Verständnisses und des Fachwissens über das Konzept, die Fähigkeiten und andere Parameter, die in den Bau- und Lieferprozess involviert sind
Der erforderliche Aufwand (Schätzung) und die Dauer für die Erstellung der Software (Dauer) sind zwei unterschiedliche Aspekte
die Einheit der Schätzung (Tage/Stunden) darf nicht falsch interpretiert werden
Die Summe aller Aufgaben über alle Anforderungen hinweg muss die Schätzung des Gesamtkonzepts ergeben.

Dementsprechend gehen verschiedene Teams unterschiedlich an den Schätzungsprozess heran, je nachdem, mit wie vielen Details sie arbeiten.

Normalisierende Schätzung(en)

Die Schätzungen können für jedes einzelne Teammitglied unterschiedlich ausfallen, da die jeweiligen Fähigkeiten übereinstimmen.

Für das kombinierte Vorhaben muss die Gesamtschätzung jedoch auf den durchschnittlichen Fähigkeiten des an der Erstellung der Software beteiligten Teams beruhen.

Dies erfordert eine Normalisierung der Schätzungen, um sicherzustellen, dass sie für das gesamte Team anwendbar bleiben.

Der Prozess der Normalisierung basiert oft auf dem Aufbau von funktionalem/domänenspezifischem Wissen und den entsprechenden technischen Fähigkeiten.

Der Fall eines Teammitglieds mit [hoher technischer Kompetenz + mäßiger fachlicher Kompetenz] unterscheidet sich von [mäßiger technischer Kompetenz + hoher fachlicher Kompetenz] oder einer anderen anwendbaren Kombination dieser Faktoren.

Auf der Grundlage der Teamzusammensetzung muss die anwendbare Normalisierung angewendet werden, um die Schätzungen referenzierbar zu halten. (Die Auswirkung aufgrund der Neuheit der Domäne oder der technischen Fähigkeiten in Bezug auf die anwendbare Lernkurve ist eine Frage der Planung).

Die Mengen (Schätzungen) spielen also eine entscheidende Rolle in dem Rezept (Software), das zu einem schmackhaften Genuss führen soll.