Agile Methoden in der Softwareentwicklung bringen eine Vielzahl an Veränderungen in weiten Teilen der Softwareentwicklung mit sich. So auch die Herangehensweise bei der Abschätzung der Aufwände eines Projektes – ein Thema, dem auch beim klassischen Projektmanagement viel Aufmerksamkeit gewidmet wird. Dieser Artikel geht der Frage nach, inwiefern Agile Methodiken eine „bessere“ Schätzung der Aufwände eines Projektes ermöglichen.

Diese Frage ist insbesondere auch deshalb interessant, da agile Schätztechniken prinzipiell nicht unbedingt agile Umsetzungen voraussetzen, und somit auch für klassische Softwareentwicklungsprozesse herangezogen werden können und vice versa. Es ist also durchaus denkbar für z.B. ein reines Wasserfall Projektvorgehen, Schätztechniken aus der agilen Softwareentwicklung zu verwenden bzw. klassische Schätzmethodiken wie Function Point Analyse für agile Projekte.

DI Sebastian Dietrich ist Leiter des Kompetenzfeldes JAVA der Firma ANECON,
Experte in Agiler Software Entwicklung

Unterschiede bei klassischen vs. agilen Schätzmethodiken

Versucht man einen Vergleich klassischer gegenüber agiler Schätzmethodiken, kommt man bald zu dem Schluss, dass so ein Vergleich nicht wirklich möglich ist, da in Agilen Projekten an das Thema Schätzung gänzlich anders herangegangen wird, als bei der Verwendung von Klassischen Methodiken. Betrachten wir hier einmal die Unterschiede in der Herangehensweise:

Bei klassischen Vorgehensmodellen werden Schätzungen zumeist am Projektanfang und eventuell bei Erreichung gewisser Meilensteine (z.B. nach Fertigstellung der Spezifikation) erstellt. Diese Schätzungen werden zumeist von Mitarbeitern mit viel Erfahrung mit Schätzungen von IT Projekten und genügend fachlichem & technischen KnowHow über die konkrete Aufgabenstellung durchgeführt. Die Schätzungen basieren zumeist auf (schriftlichen) Lasten- bzw. Pflichtenheften, oder – im Idealfall – auf der detaillierten fachlichen & technischen Anforderungsspezifikation der Software. Das Ziel der Schätzungen ist es zu Projektbeginn (bzw. den oben erwähnten Zeitpunkten) die Aufwände der Softwareentwicklung (& darauf aufbauender Tätigkeiten wie Projektmanagement, Test und BugFixing) abzuschätzen.
Bei agilen Vorgehensmodellen werden Schätzungen laufend (zumindest am Beginn jeder Iteration (d.h. max. alle 4 Wochen), konkrete Tätigkeiten sogar täglich) durchgeführt. Diese Schätzungen werden vom Umsetzungsteam aufbauend auf ihren konkreten Projekterfahrungen getätigt und basieren auf den für die Iteration geplanten Fachlichkeiten durchgeführt. Das Ziel der Schätzungen ist es zu jederzeit die aktuell noch offenen Aufwände (der Iteration bzw. des Gesamtprojektes) abzuschätzen.

Man erkennt also deutliche Unterschiede bei Zeitpunkt, Verantwortlichkeit, Grundlage, Technik und Ziel der Schätzungen in klassischen und agilen Vorgehensmodellen.

Darüberhinaus gibt es auch Unterschiede in der eigentlichen Vorgangsweise der Schätzung. Klassische Schätzmethodiken basieren zumeist entweder auf Expertenschätzungen, oft verbessert durch die Delphi Methodik (d.h. getrennte Schätzung durch mehrere Experten basierend auf einer gemeinsamen Stückliste – gefolgt von einer gemeinsamen Durchbesprechung der Einzelschätzungen und einem schlussendlich gemeinsamen Schätzergebnis). Oder sie basieren auf standardisierten Schätztechniken (wie COCOMO oder Function Point Analyse), welche basierend auf (unternehmensspezifischen) Erfahrungswerten die prognostizierten Aufwände errechnen lassen.

Agile Schätzmethodiken basieren oft auf den oben erwähnten Expertenschätzungen, arbeiten aber meist mit sogenannten Vergleichsschätzungen (d.h. Aufwand des Features B im Vergleich zum (geschätzten) Aufwand des Features A) und somit oft mit anderen Einheiten als Personenstunden (meist „Story Points“ genannt). Darüberhinaus verwenden sie Techniken (wie z.B. das „Planning Poker Game“, bei welchem die „Spieler“ die Schätzungen anhand von mit Fibonacci-Zahlen versehenen Karten „durchspielen“ – wobei immer die nächsthöhere Karte gezogen werden muss), welche die eigentliche Methodiken (in diesem Fall die Delphi Methodik und die Cone of Uncertainty) spielerisch anwenden.

Auswirkungen der Unterschiede

Die oben aufgeführten Unterschiede der klassischen vs. agiler Schätzmethodiken führen unserer Erfahrung nach zu folgenden Auswirkungen:

Besseres Controlling bei Agilen Vorgehensmethodiken
Nachdem die Schätzungen in Agilen Projekten tagesaktuell gemacht werden, lässt sich der gesamte Restaufwand tagesaktuell bestimmen. Das ist ein großer Vorteil gegenüber klassischen Vorgehensmodellen, wo die Restaufwände basierend auf einer teilweise viele Monate zurückliegenden Schätzung (welche wiederum auf dem damaligen – jetzt u.U. veralteten Wissen bezüglich der Anforderungen und der technischen Umsetzung gemacht wurden) errechnet werden.
Automatische Berücksichtigung von Schätzfehlern
Agile Schätztechniken berücksichtigen im Gegensatz zu klassischen Schätzmethodiken von vornherein übliche Fehlerquellen beim Schätzen. Bei klassischen Methoden müssen erst aufwändige Faktoren für z.B. mitarbeiterbezogene Schätzungenauigkeiten („Mitarbeiter A schätzt immer viel zu wenig“) oder für die Cone of Uncertainty („frühe & grobe Schätzungen sind wesentlich riskanter als späte & kleingranulare Schätzungen") eingerechnet werden.
Bei Agilen Schätztechniken werden diese Punkte größtenteils automatisch berücksichtigt (mitarbeiterbezogene Schätzungenauigkeiten durch den Einsatz von Vergleichsschätzungen basierend auf StoryPoints, Cone of Uncertainty durch den Einsatz von Fibonaccizahlen beim Planning Poker Game).
Committment des Projektteams zu Schätzungen
Agile Schätzungen werden immer ausschließlich vom Projektteam durchgeführt. Weder Product Owner, noch Projektmanager, noch andere Stakeholder des Projektes haben die Erlaubnis bei den Schätzungen mitzumachen. Die Schätzung liegt also in der ausschließlichen Verantwortung des Teams, welches für die Umsetzung des Projektes gemäß der Schätzung verantwortlich ist. Dadurch schafft man einerseits ein hohes Committment des Projektteams zu den Schätzungen, andererseits wird damit unterstützt, dass keine leichtfertigen Schätzungen abgegeben werden (weil das Projekt ja von den schätzenden Personen umgesetzt werden muss).
Projektbezogene Schätzgrundlagen
Agile Schätzungen werden immer basierend auf den im konkreten Projekt gemachten Erfahrungen gemacht – d.h. es wird automatisch mit der Zeit der Einfluss projektspezifischer Variablen (wie z.B. Arbeitsumgebung, Skills der Entwickler, Komplexität der Anforderungen, …) auf die Produktivität mit einberechnet (insbesonders bei relativen Schätzungen).
Andererseits werden bei agilen Projekten die Schätzungen oft nicht von im Schätzen sehr erfahrenen Leuten abgegeben. Schätzexperten, wie sie oft bei klassischen Vorgehensmodellen eingesetzt werden, können bei agilen Projekten nur durch Zufall (wenn diese auf Teil des Teams sind) zum Einsatz kommen.
Schätzerfahrung & Schätzqualität
Nachdem in agilen Softwareentwicklungsprojekten laufend Schätzungen abgegeben werden müssen, und diese auch laufend gegen die tatsächlichen Aufwände controlled werden, lernen agile Teams sehr rasch mit Schätzungen umzugehen – auch, dass es gut und richtig ist, inaktuelle Schätzungen möglichst rasch aufzuzeigen und zu aktualisieren. Klassische Schätzmethodiken werden wesentlich seltener, aber dafür von zumeist immer denselben Leuten durchgeführt. Diese lernen damit rasch projekt- und teamübergreifend Schätzungen zu machen, die dann gegen die tatsächlichen Aufwände controlled werden. Leider werden Abweichungen der Ist-Zahlen gegenüber den Schätzwerten in klassischen Softwareentwicklungsprojekten oft als Fehler der Schätzung angesehen, was leider dazu führt, dass Schätzungen nur ungern und möglichst spät bzw. mit unrealistisch hohen Buffern abgegeben werden.

Konklusio

Betrachtet man die Unterschiede der Schätzverfahren und ihre Auswirkungen auf die Schätzungen, lässt sich Folgendes feststellen:

Die Qualität der Schätzungen scheint mit agilen Methodiken nicht unbedingt besser zu werden. Im Gegenteil - klassische Schätzmethodiken führen weit eher zu unternehmensweit einsetzbaren Schätzerfahrungen als agile Methodiken, die ja eher auf die Verbesserung der Schätzerfahrungen innerhalb eines Projektteams abzielen. Dies hat zur Auswirkung, dass gerade in frühen Projektphasen klassische Schätzmethodiken weit bessere Ergebnisse liefern als agile.
Will man also z.B. die Fähigkeit eines Unternehmens verbessern, zu frühen Projektzeitpunkten gute Schätzungen abgeben zu können, so ist einem sicherlich mit klassischen Schätzmethodiken besser geholfen als mit agilen.
Die Relevanz der Schätzungen hingegen ist bei agilen Methodiken wesentlich höher als bei klassischen Methodiken. Dies liegt vor allem daran, dass die Schätzungen agiler Softwareentwicklungsprojekte tagesaktuell und basierend auf den konkreten Projekterfahrungen vom Umsetzungsteam gemacht werden. Die Schätzungen sind also wesentlich aktueller & entsprechen somit weit eher den noch zu erwartenden Aufwänden als lange zurückliegende klassische Schätzungen.
Will man also z.B. die Fähigkeit eines Unternehmens verbessern, frühzeitig auf Änderungen der Projekt-Aufwände und Fertigstellungstermine reagieren, so ist einem mit agilen Schätzmethodiken definitiv besser geholfen als mit klassischen.

Empfehlung

Man erkennt also, dass beide Herangehensweisen an Schätzungen ihre Vor- und Nachteile haben – klassische Techniken punkten eher vor bzw. zu Projektbeginn, agile Schätztechniken eher im Laufe eines Projektes. Die meisten Unternehmen werden aber Softwareentwicklungsprojekte haben, welche sowohl zu Projektbeginn, als auch während der gesamten Projektdauer gute und aktuelle Schätzungen benötigen. Diese Unternehmen werden also nicht umhin kommen, sowohl klassische als auch agile Schätztechniken in ihren Projekten einzusetzen.