Der nachfolgende Text wurden mit KI erstellt und kann Fehler enthalten. Fehler gefunden? Bei GitHub editieren
Die Softwareentwicklung ist geprägt von zwei Begriffen, die häufig als fundamental gelten: Schätzungen und Deadlines. Doch sind sie das wirklich?
Das Problem mit festen Anforderungen
Ein zentraler Punkt ist die Realität von Softwareprojekten: Anforderungen sind nicht statisch. Sie entstehen durch iterative Feedback-Zyklen. Wenn Nutzer mit einer Software interagieren, geben sie Feedback, das zu Änderungen führt – ähnlich wie bei der Einführung des iPhones, das Menschen erst zeigen musste, was sie eigentlich wollen. Diese kontinuierliche Evolution von Anforderungen stellt die traditionelle Schätzung in Frage: Warum sollte man ein gesamtes Projekt präzise durchplanen, wenn sich der Umfang ohnehin ändert?
Agile Schätzung als Planung, nicht als Präzision
Eberhard beleuchtet einen wichtigen Unterschied: Story Points und Velocity dienen nicht der absoluten Genauigkeit, sondern der Planung. Im agilen Ansatz schätzt man relativ zu einer Referenzstory, nicht in Personentagen. Dies führt zu besseren Ergebnissen als absolute Zeitschätzungen. Die Velocity berücksichtigt die aktuelle Teamgeschwindigkeit – abhängig von Urlaubstagen, Hindernisse, individuelle Fähigkeiten. Dieses Verfahren ist nicht objektiv, sondern optimiert auf praktische Planbarkeit.
Warum schätzen wir überhaupt?
Die eigentliche Frage ist nicht, ob wir schätzen müssen, sondern warum. Der hauptsächliche Zweck ist die Entscheidungsfindung: Ist diese Story den Aufwand wert? Ein Nebeneffekt ist wertvoll: Nicht-schätzbare Stories signalisieren Risiken und unklar definierte Anforderungen – ein Signal für einRisiko und ein Hinweis, was geklärt werden muss.
Deadlines zwischen Mythos und Realität
Bei den Deadlines wird es noch interessanter. Eberhard unterscheidet zwischen echten und weichen Deadlines. Eine harte Deadline existiert beispielsweise beim Weihnachtsgeschäft – sie ist unumgänglich. Doch viele Deadlines, besonders bei Architektur-Migrationen oder internen Projekten, sind eher flexibel. Der Wunsch nach einem Gefühl der Kontrolle führt dazu, dass Organisationen an Deadlines festhalten, die bei Bedarf verschoben werden können.
Besonders problematisch: Deadlines unter Druck führen zu Technical Debt. Teams nehmen Abkürzungen, wenn Termine als sakrosankt gelten. Werden Deadlines als gestaltbar verstanden, eröffnet sich Raum für bessere technische Entscheidungen.
Value über Aufwand
Letztendlich sollte nicht der Aufwand das primäre Ziel sein, sondern der geschaffene Wert. Ein realistisches Projektmanagement berücksichtigt: Wann bringt die Software tatsächlich Nutzen? Oft ist eine leicht verspätete Lösung mit guter Architektur wertvoller als eine pünktliche, technisch fragile Implementierung.
Fazit
Die provokative Botschaft lautet: Subjektives Schätzen ist nicht das Problem – es ist die Realität. Feste Deadlines sind oft nicht wirklich fest und können hinterfragt fragen. Der Schlüssel liegt darin, ehrlich zu sein: Wo sind echte geschäftliche Grenzen? Wo haben wir Spielraum? Ein vertrauensvolles Verhältnis zwischen Stakeholdern ermöglicht es, diese Fragen offen zu diskutieren und tatsächlich bessere Software zu entwickeln – nicht schneller, sondern smarter.