Suche
Schätzen schätzen lernen

Aufwandsschätzung für Entwickler: Warum und wie schätzen sinnvoll ist

Dirk Dorsch

© Shutterstock / ImageFlow

Schätzen hatte noch nie einen allzu guten Ruf. Die eine Seite fürchtet den hohen Aufwand und die damit verbundenen Kosten, die andere Seite ein daraus entstehendes Commitment, das einzuhalten insbesondere dann ein Ding der Unmöglichkeit ist, wenn man nicht ausreichend Zeit und Informationen hat. Trotz eines ambivalenten Verhältnisses bieten Schätzungen allen Stakeholdern einen großen Nutzwert. Richtig verankert erhalten alle Beteiligten ein gemeinsames Verständnis des Projekts und Stellschrauben für Optimierungen – alles im Sinne der Anwender.

Schätzen ist eine Frage der Übung. Das steht ebensowenig außer Frage wie die Tatsache, dass jede Schätzung mit hoher Wahrscheinlichkeit falsch sein wird. Auch in einem klassischen Set-up mit intensivem Austausch von Lasten- und Pflichtenheft lassen die Anforderungen Freiheitsgrade und Interpretationsspielraum. Bietet die Lastenheftphase genügend Zeit, kann man sie eventuell auf ein Minimum reduzieren. Gepaart mit großer Erfahrung und bester Kenntnis über die in der geplanten Durchführung einzusetzenden Technologien und Menschen lässt sich so womöglich eine annähernd verlässliche Schätzung abgeben. Also Schluss mit Agile, zurück zum Wasserfall?

Warum und wie schätzen sinnvoll ist

Vermutlich nicht, sind da doch noch die Proargumente agiler Entwicklung. Im Allgemeinen ist es – in Hinblick auf ein für den Kunden oder Anwender optimiertes Ergebnis – nicht ratsam, die Handlungsfähigkeit bei sich ändernden Anforderungen zugunsten einer optimierten initialen Schätzung aufzugeben. Also Schluss mit Schätzen, hin zu „Es ist halt fertig, wenn es fertig ist“ und „Es dauert so lange, wie es dauert“? Außerhalb Utopias ist das schwer vorstellbar. Gibt es da ja noch den allseits geliebten Festpreis und auch die Releasetermine. Was bleibt, ist zu erkennen, dass Schätzungen Teil der Software und ebenso agil zu behandeln sind. Schätzen ist keine einseitige Aufgabe der Entwickler, die dann an den Pranger gestellt werden, wenn sie die Schätzung in der Umsetzungsphase nicht einhalten. Schätzen ist, wie die gesamte Entwicklung, ein kollaborativer Prozess, der alle Beteiligten zusammenbringt und ein gemeinsames Verständnis und Verantwortungsgefühl schafft.

Der Softwareentwicklungsprozess bindet die einzelnen Stakeholder in den unterschiedlichen Projektphasen unterschiedlich intensiv ein. Innerhalb der jeweiligen Peergroups und Projektphasen entstehen schnell ein abweichender Terminus und eine damit einhergehende Varianz in der Sicht auf die Anforderungen. Zwangsläufig ist es deswegen ab einem gewissen Zeitraum immer aufwendiger, einen nachvollziehbaren Projektstatus zu bekommen. Der Managementoverhead steigt also mit fortschreitendem Projektverlauf rapide an. Die Antwort nach dem Stand im Budget zu bestimmen, erfordert teilweise schon forensische Detailarbeit.

Vertrieb und Management benötigen einen einfachen Zugang zum Projektstatus, um eine rollierende Kontrolle des Budgets zu erreichen, die im Risikofall ein zielgerichtetes Eingreifen ermöglicht. Auftraggeber wollen bezüglich Lieferterminen und Budget stets auf dem aktuellen Stand sein, insbesondere, sobald Abweichungen zu erkennen sind. Der Projektleiter will ebendiese vermeiden und benötigt einen Echtzeitblick auf die KPIs des Projekts. Die Entwicklung selbst ist häufig nur nebensächlich an den Aufwänden interessiert, hier liegt der Fokus verstärkt auf der qualitativ hochwertigen Umsetzung. Aber gerade diese erfordert auch eine entsprechende Sensibilität für die Aufwände, um zu erkennen, wann und in welchem Umfang beispielsweise nicht zwingend erforderliche Optimierungen an der Infrastruktur vorgenommen werden können.

Den Entwicklungsprozess auf diese Anforderung auszurichten, kann zu erheblichen Aufwänden führen. Und nicht auf jeder Ebene des Prozesses zeigen die Beteiligten Verständnis für eine exzessive Dokumentation von (Rest-)Aufwänden. Ist der Wille da, scheitert es häufig daran, dass sich einzelne Aufgaben nicht mehr eindeutig einem Aufwandsblock im Angebot zuordnen lassen. Ein optimaler Prozess und seine Abbildung auf ein Tooling sollten daher so ausgerichtet sein, dass sich die Terminologie der Angebotsphase in der Arbeit von Entwicklung und Operations wiederfindet. In der Entwicklung entsteht ein Kostenbewusstsein, das sich unmittelbar auf ganzheitliche Anforderungsblöcke projizieren lässt und so eine nachvollziehbare Transparenz bis zum Vertrieb schafft. Dies reibungslos umzusetzen, erfordert einen hohen Grad an Automatisierung. Die Entwicklung unterstützt den Vertrieb gerne, wenn es keine Mehraufwände mit sich bringt. Das gelingt, wenn von Beginn an, also bereits während der Angebotserstellung, auf Kollaboration gesetzt wird.

Das Umfeld schätzt mit

Die Basis von Schätzungen ist die gewissenhafte Mitarbeit der Beteiligten. Insbesondere bei mangelnder Erfahrung, sowohl in der Entwicklung, aber auch insbesondere beim Schätzen selbst, entarten Schätzungen oft in ein abenteuerliches Ausmaß – in beide Richtungen. Elementar für ansatzweise zuverlässige Schätzungen ist das Umfeld. Bestimmte Einflüsse können drastische Auswirkungen auf den Schätzwert haben. Je nach Konstellation wird häufig ein direkter oder indirekter Druck auf die Schätzenden ausgeübt. Befindet sich ein Projekt beispielsweise noch in der Angebotsphase, wird vom Vertrieb häufig ein dem Kunden unterstelltes Budget als Druckmittel eingesetzt. Schätzungen werden angezweifelt, sobald sie nicht in diese Budgetvorstellung passen. Dieses destruktive Anzweifeln führt häufig dazu, dass sich unerfahrene Schätzer aus der Ruhe bringen lassen und tendenziell eine niedrigere Schätzung abgeben. Fehlendes Anzweifeln vermindert allerdings ebenso die Güte der Schätzungen. Die technischen Schätzer haben häufig eine zu komplexe Sicht auf die Anforderungen und tendieren bereits beim Schätzen im Geiste zu einem Overengineering. Hieraus resultierende, meist zu hohe Schätzungen lassen sich im Dialog mit der Fachlichkeit häufig relativieren. Der Dialog zwischen allen Stakeholdern hat eine ausgleichende Wirkung und steigert Güte und Verlässlichkeit der Schätzwerte. Um die Belastbarkeit der Schätzungen weiter zu steigern, muss ein Schätzen im stillen Kämmerlein oder im Elfenbeinturm vermieden werden.

Lesen Sie auch: Agil im Gehirn: Darum funktioniert Agile Software-Entwicklung

ch wenn Story Points nicht in allen Lagen die beste Einheit für das Schätzen sind – in einem Angebot spielt wohl eher die Zeit eine Rolle –, bietet beispielsweise eine gesellige Runde Planning Poker sicher einen guten Rahmen. Zumindest sollte die dahinter liegende Idee der kollaborativen Schätzung beherzigt werden. Schätzen im Team schärft nicht nur das Gefühl für Aufwände und Kosten bei der fachlichen Seite, es hilft ebenso, Anforderungen gemeinsam besser zu verstehen und bereits in einer frühen Phase eine gemeinsame Verantwortung für das und Identifikation mit dem Projekt zu entwickeln. Bei einer Reihe von Aufgaben sind dem Auftraggeber die Aufwände häufig nicht bewusst, zusammen mit einer geringen Priorität lässt sich bereits früh Ressourcenvergeudung vorbeugen.

Diskussionen über eine Anforderungen und deren Umsetzung fördern die Qualität, da Wissensdefizite einzelner Beteiligter ausgeglichen und frühzeitig erste den Aufwand hochtreibende Detailfragen geklärt werden. Einer der subtilsten Gründe für die Unwilligkeit zu schätzen, insbesondere bei unerfahrenen Entwicklern, sind Angst und Unsicherheit. Eine Schätzung ist auch immer mittelbar ein Commitment. Um dieser Verantwortung gerecht zu werden, tendieren viele zu überhöhten Schätzungen. Schätzen im Team verteilt die Verantwortung und bietet so unerfahrenen Entwicklern das optimale Umfeld, um ein Gefühl für Aufwände zu bekommen, insbesondere für die versteckten.

Die Planung und den Status für den Auftraggeber abbilden

In der Entwicklung haben sich im Wesentlichen zwei Organisationsformen etabliert. In klassischen Ansätzen dominieren die Komponententeams, bei denen Spezialisten in Abteilungen gemäß ihrer Kernkompetenzen aufgeteilt sind, z. B. Frontend, Backend, Datenbank oder QA. Ein Projekt durchläuft dann entsprechend die unterschiedlichen Abteilungen. Dem gegenüber stehen die meist in agilen Methoden verankerten Featureteams. Bei diesem Konzept sind die Teams so organisiert, dass alle benötigten Kompetenzen dauerhaft im Team angesiedelt sind.

Featureteams bieten bereits die wesentliche Grundlage für ein gutes Schätzumfeld. Das Team arbeitet dauerhaft zusammen, kennt die Zeitverluste an den Übergabepunkten – so es diese denn überhaupt noch gibt – kann sich gegenseitig einschätzen und trägt die Verantwortung im Kollektiv. In einer Abteilungsstruktur erfolgt die dauerhafte Zusammenarbeit innerhalb der Komponente oft mit einer gewissen Scheuklappenattitüde hinsichtlich abhängiger Komponenten. Die nativen Schätzteams wären hier nicht projektbezogen, sondern komponentenbasiert. Für eine kollaborative Schätzrunde auf Projektebene müsste diese über Repräsentanten der einzelnen Fachgebiete hinweg gebildet werden. Das kann aber dazu führen, dass die Schätzenden nicht die Ausführenden sind. Der Ausführende fühlt sich so häufig nicht an die Schätzung gebunden oder er wählt schlicht eine andere technologische Umsetzung. Somit ist diese Konstellation häufig eine erste, nicht behebbare Fehlerquelle.

Diese Strukturen spiegeln sich auch in der Sicht auf die Software und die damit verbundene Kommunikation wider. Die so beeinflusste Struktur und Terminologie bestimmt das gemeinsame Verständnis der Anforderungen maßgeblich. Eine durch die technischen Abteilungen geprägte Struktur tendiert dazu, die Anforderungen in Aufgaben für die jeweiligen Anforderungen zu zerlegen. Das kann für den Anforderungssteller schnell zu Unverständlichkeit führen. Die Spezifikationen werden ebenso schnell sehr breit gefächert und feingranular. Eine Anforderung „Kundendaten erfassen“ würde etwas überspitzt dargestellt in eine Menge von Subanforderungen aufgeteilt werden: „Konzeption/Design für Kundendatenformular erstellen“, „Persistenzschicht Kundendaten bereitstellen“, „Webformular Kundendaten implementieren“, „Test der Persistenzschicht Kundendaten“ und „Webtest Kundendatenformular“. In der Planung können die einzelnen Aufgaben nun mit einem Schätzwert versehen und in eine Planung überführt werden, die zeitliche und inhaltliche Abhängigkeiten berücksichtigt. Diese Abbildung wird insbesondere dann notwendig, wenn eine Nachverfolgbarkeit der Anforderung gewünscht ist.

Es muss jederzeit ersichtlich sein, in welcher Abteilung die Anforderung aktuell in Bearbeitung ist, um so Budget und Zeit kontrollieren zu können. Für die Fachseite bietet dieser Ansatz nur einen geringen Mehrwert. Für die beschriebene Unternehmensstruktur ist er allerdings unabdingbar, um die Auslastungen der Abteilungen planen zu können. Das Projekt befindet sich so von Beginn an in einem Interessenkonflikt zwischen Unternehmensstruktur und Kunden- oder Anwenderinteressen. Alternativ zu diesem aufgabenorientierten Ansatz passt auf Featureteams eher ein featurezentrischer Ansatz. Als Schätz-, Planungs- und Tracing-Gegenstand bleibt die Anforderung „Kundendaten erfassen“. In der Schätzrunde zerlegt das Team das Feature in die Aufgaben für die einzelnen Teammitglieder und diskutiert sie gemeinsam. Die Summe der Einzelaufwände wird dem Schätzgegenstand zugewiesen. Die Schätzung bezieht sich so auf das für den Auftraggeber Relevante, die Kosten eines bestimmten Features.

Lesen Sie auch: Skalieren mit Scrum und Microservices: Big Bang oder langsame Transformation?

Die Details bleiben für ihn verborgen und spielen nur innerhalb des Teams eine Rolle. Hier tauchen die Aufgaben gegebenenfalls wieder als Post-its am Kanban-Board oder in der Sprintplanung auf. In agilen Methoden werden die Anforderungen selten dauerhaft in Aufgaben zerlegt und in unterschiedlichen Planungszyklen umgesetzt. Scrum verlangt beispielsweise das Abarbeiten einer User Story innerhalb eines Sprints. Planerisch herrscht somit bei eingespielten Teams stets Gewissheit in Bezug auf die Sprintlänge. Eine komplexe Betrachtung der Abhängigkeiten einzelner Aufgaben ist nicht notwendig. Ist eine Anforderung zu groß für einen Sprint, wird sie entweder nach Subfeatures gruppiert oder zunächst eine Basisversion im Sinne eines Minimal Viable Products (MVP) umgesetzt. Auch hier profitieren Anwender durch eine frühestmögliche Verfügbarkeit einzelner Anforderungen.

Da agile Projekte Anforderung im Allgemeinen in User Stories formulieren und in Featureteams organisiert sind, ist der featurezentrische Schätzansatz der naheliegende. In klassischen Strukturen dominieren häufig die Abteilungen und spiegeln unter Umständen schon in Lasten- oder Pflichtenheften und später in der Softwarearchitektur eine eher aufgabenorientierte Darstellung wider. Auch hier lassen sich natürlich die Details nach den Bedürfnissen des jeweiligen Betrachters verbergen und die äußere Darstellung lässt sich auf das Level der Anforderung abstrahieren.

Häufig ist auch eine konsequente Darstellung nach einem der beiden Muster nicht möglich. Die Aufgaben „Beschaffung von Testgeräten“ oder „Set-up der Continous-Integration-Infrastruktur“ sind nun einmal querschnittliche Aufgaben. Eine Zuordnung auf ein Feature ergibt keinen Sinn. Auf der anderen Seite gibt es auch Features, die sich nur schwer in weitere Aufgaben zerlegen lassen. Die Unterscheidung liegt dann häufig nur noch in der sprachlichen Formulierung.

Schätzmethoden: Nicht einfach würfeln

Allen Schätzmethoden gleich ist, dass der Schätzgegenstand bestmöglich beschrieben und verstanden sein muss. Fehlerwahrscheinlichkeit und -größe steigen mit dem Umfang einer Anforderung. Bezogen auf ein agiles Requirements Engineering ist also ein Epic als Schätzgegenstand eher schlecht geeignet. Die User Story, beziehungsweise ihr Analogon der klassischen Welt, der Use Case, sind im Allgemeinen bereits so definiert, dass sich der Aufwand im Bereich einiger Stunden bis weniger Tage bewegt. Das bietet somit den optimalen Kompromiss zwischen Feingranularität und Überschaubarkeit.

Die denkbar einfachste Methode ist es, einen Wert anzugeben. Das Ganze ähnelt dann aber eher dem Würfeln, da keinerlei Risiken oder Ausprägungen der Umsetzung berücksichtigt werden. Sinnvoller und eine durchaus als natürlich empfundene Schätzform ist „von/bis“. Hier hat der Schätzende die Möglichkeit, den Best Case und den Worst Case abzubilden. Die Dreipunktschätzung, auch Program Evaluation and Review Technique (PERT) genannt, ergänzt diese beiden Werte noch um den Normalfall. Der anzusetzende Wert wird dann durch eine Gewichtung der jeweiligen Werte wie folgt ermittelt:

Aufwand = (Worst Case + 4 * Norm + Best Case) / 6

Die Nennung von drei Werten ist allerdings gewöhnungsbedürftig. Auch erfahrenen Entwicklern fällt „von/bis“ wesentlich leichter. Erzwingt man die Nennung eines Normalwerts, wird charakterabhängig wahlweise der Worst Case, das Mittel oder der Best Case zum Normwert. Natürlicher und einfacher ist es, bei „von/bis“ zu bleiben und stattdessen einen Puffer anzusetzen, der das unterstellte individuelle Risiko einzelner Anforderungen abbildet. Das Konzept des Planpuffers errechnet aus den beiden Schätzpunkten einen zeitlichen Puffer für das Gesamtprojekt. Dem Planpuffer liegt als erste Annahme zugrunde, dass die Differenz zwischen Normalfall und Worst Case ein Maß für die Unsicherheit ist. Die zweite Annahme ist, dass die Wahrscheinlichkeit, eine Normalfallschätzung in der angesetzten Zeit abzuschließen, bei 50 Prozent liegt, eine Worst-Case-Schätzung aber zu 90 Prozent eingehalten werden kann.

Eine hohe Unsicherheit birgt ein höheres Risiko, das entsprechend stärker abgefedert werden muss. Der gewählte Wert sollte in diesem Fall zum Worst Case tendieren. Liegen Normalfall und Worst Case nahe beieinander, spielt die Differenz eine untergeordnete Rolle, und das Mittel beider Werte ist eine gute Wahl. Eine Methode, die diesen Ansprüchen genügt, ist die „Quadratwurzel der Summe der Quadrate“. Hierbei erfolgt die Aufsummierung der quadrierten Differenzen aus Normalfall und Worst-Case-Schätzung. Die Wurzel dieser Summe ergibt den Projektpuffer und wird zur Summe der Normalfälle des Gesamtvolumens addiert. So werden die Aufgaben mit höherer Unsicherheit stärker gewichtet als die mit geringerem Risiko. Ein Planpuffer lässt sich auch für einzelne Anforderungsblöcke definieren und ermöglicht so ein unter Umständen differenzierteres Bild auf das Gesamtvolumen. Bezogen auf eine einzelne Anforderung degeneriert der Planpuffer zum reinen Mittelwert.

Verbindlichkeit schaffen

Softwareprojekte beginnen beim Angebot. In einer idealisierten, klassischen Welt kann dieses nach Durchlaufen der Lasten- oder Pflichtenheftphase erstellt und die Software nach klassischen Methoden entwickelt werden. Die Projektleitung führt ein konsequentes Controlling durch und bietet mit dem Prozess lückenlose Nachverfolgbarkeit. Ein Change-Management-Prozess ermöglicht die Anpassungen an die Anforderungen und stellt die Aktualisierung der Aufwände sicher. Es gibt aber auch viele Projekte, bei denen eine detaillierte Spezifikation nicht vorliegt und auch aus zeitlichen Gründen nicht erstellt werden kann oder soll. In diesem Fall muss ein Angebot oder eine interne Kosten-/Aufwandsschätzung, auf einer wesentlich dünneren Wissensgrundlage erstellt werden. Mit sinkendem Detailgrad der Anforderungen steigen die Abweichungen bei den Schätzungen. Basis für Schätzungen bei dünner Ausgangslage sind also immer Annahmen über Art und Ausprägung des Schätzgegenstands. Ein vorgegebenes Budget kann die Situation noch weiter erschweren oder aber eben auch erleichtern. Ist die exakte Ausgestaltung einer Anforderung oder des Gesamtsystems nicht bekannt, kann das Budget herangezogen werden, um die Annahmen so zu gestalten, dass bei vorgegebenem Budget eine Verteilung der Aufwände über die Menge der Anforderungen zum bestmöglichen Gesamtsystem führt.

Ein Schätzprozess muss auf Robustheit hinsichtlich fehlerhafter Einschätzungen optimiert sein, um dem Projekt Verlässlichkeit zu geben. Eine erste Sicherheit bietet die Annahme, dass Fehler nach unten wie oben gleich verteilt sind und sich so bei ähnlich groß geschnittenen Anforderungen gegenseitig egalisieren. Da unterschiedliche Charaktere je zu defensiven oder offensiven Schätzungen tendieren, trifft dies umso mehr zu, je unterschiedlicher die Schätzrunde zusammengesetzt ist. Dieser Effekt ist aber immer noch mit starken Unsicherheiten verbunden, und weitere Maßnahmen zur Absicherung sind empfehlenswert. Neben einem Planpuffer, der das Risiko der Unsicherheiten der Schätzungen mathematisch adressiert, ist der Featurepuffer ein weiteres Instrument.

Lesen Sie auch: „Agile und DevOps bringen Probleme frühzeitig zum Vorschein, anstatt sie zu verstecken“ – Interview mit Thomas Much

Für den Featurepuffer werden die Anforderungen gemäß einer Priorisierung aufgeteilt. Erfahrungsgemäß sind zunächst alle Anforderungen von der höchsten Prioritätsstufe. Sofern aber Labels wie trivial, minor oder unwichtig vermieden werden, lassen sich auch hier Abstufungen finden. Sollte dies nicht zu einer ausgewogenen Abstufung führen, können einzelne Features in Bezug auf ihre Ausbaustufe geteilt werden, um so eine weitere Abstufung zu erreichen. Beispielsweise lässt sich eine Anforderung „Nutzerauthentifizierung“ in „Sign-in with Facebook“, „Google Log-in“ und „Eigenes Authentifizierungssystem“ aufteilen und entsprechend gewichten. Anhand dieser Priorisierung wird aus den geringer priorisierten Anforderungen ein Featurepuffer gebildet und so ein verbindlich zu erbringendes Paket von einem optionalen abgegrenzt.

Eine gedachte rote Linie teilt so die Anforderungen in einen obligatorischen Block und den Featurepuffer. Im Kontext von Auftragsentwicklung lässt sich das Konzept eines Featurepuffers meist schwer durchsetzen. Dennoch verfolgt dieser Ansatz das Ziel, einem Projekt eine höhere Verbindlichkeit und Verlässlichkeit hinsichtlich eines gesicherten Funktionsumfangs und eines sicheren Releasetermins zu bieten. Um eine differenzierte Selektion zu ermöglichen, ist entscheidend, dass die Anforderungen von Beginn an klar priorisiert sind. Sind Budget oder Kosten bekannt, werden aus den am höchsten priorisierten Anforderungen so viele ausgewählt, dass ca. 70 Prozent des Budgets ausgeschöpft werden. Die verbleibenden 30 Prozent werden gemäß geschätztem Aufwand und Priorisierung aufgefüllt und als optional aufgenommen. Um die Risiken weiter einzugrenzen, lässt sich der obligatorische Teil zusätzlich mit einem Planpuffer absichern.

Neben dem Umfang eines Projekts ist ein verbindlich einzuhaltender Liefertermin ein wesentlicher Aspekt der Planung. Der Liefertermin ist zunächst ausschließlich von den Schätzungen und den Kapazitäten abhängig und häufig durch externe Ereignisse wie Release zu Messetermin oder Weihnachtsgeschäft vorgegeben. Das Einhalten des Termins ist somit von den zwei Unbekannten Schätzsumme und Kapazität abhängig. Letztere, also die Velocity des Teams, lässt sich bei einem eingespielten Team gut kalkulieren. Als Richtwert können 80 Prozent der Arbeitszeit angenommen werden. Bei einer Wochenarbeitszeit von 40 Stunden entspricht dies sechs Produktivstunden je Tag. Feiertage, Krankheiten und unproduktive Zeit wie Meetings, E-Mails oder interne Dokumentation sind damit im Allgemeinen hinreichend berücksichtigt. Je nach Projektzeitraum sollten Urlaubszeiten im Sommer gesondert in der Kapazität berücksichtigt werden. Die Unbekannte „Schätzfehler“ lässt sich durch den Planpuffer kompensieren, indem dieser auf alle Anforderungen oberhalb des Featurepuffers angewandt wird.

Das Vorhaben ist für das Einhalten von Budget und Liefertermin somit hinreichend gepuffert. Die Termintreue lässt sich zusätzlich dadurch sichern, dass das Team rechnerisch die Kapazität besitzt, um das Projekt mit einem auf das Gesamtvolumen angewandten Planpuffer abzuschließen. Dies darf allerdings nicht in Trägheit enden. Das Projektteam muss den Ehrgeiz haben, innerhalb der durch den Liefertermin gesetzten Projektlaufzeit auch den Featurepuffer weitgehend zu leeren. Die Trägheit kann umgangen werden, indem die rote Trennlinie zwischen Puffer- und obligatorischen Features während der Umsetzung dynamisch verschoben wird. Die Schätzungen werden während der Projektlaufzeit in regelmäßigen Abständen ebenso überprüft wie die Restkapazität. Hierzu werden maßgeblich die Abweichungen von protokolliertem, erbrachtem Aufwand und Schätzungen, aber auch technische Erkenntnisse herangezogen. Aus den hieraus gewonnen Erkenntnissen werden entsprechend Features aus dem Puffer in den obligatorischen Block verschoben.

Fazit

Ein häufiges antiagiles Argument ist die Angst vor mangelnder (Status-)Transparenz, letztlich eine Angst vor Kontrollverlust. Eine leichtgewichtig in den Prozess integrierte Schätzkultur bietet die vermisste Nachverfolgbarkeit ohne zu viel den Agilen verhassten Prozessoverhead einzuführen. Auch in klassischen Methoden kann der der Aufwand verringert werden, wenn das Schätzen ernst genommen und nicht als Last empfunden wird. Grundlagen für verlässliche Schätzungen sind:

  • Keine Angst vor Verbindlichkeit
  • Keine Schätzungen von Einzelpersonen
  • Kein Anzweifeln von Schätzungen, nur weil die Höhe nicht ins Budget passt
  • Eine „von/bis“-Schätzung genügt und nimmt dem Schätzen die Komplexität
  • Regelmäßiges Anpassen auch und insbesondere von Restaufwänden

Insbesondere schätzfaule Entwickler müssen über ihren Schatten springen und die planende Seite unterstützen. Schätzrunden, insbesondere mit anwesenden Anforderungsstellern, sind ein optimales Mittel, um frühzeitig Unklarheiten aufzudecken, Projektrisiken frühzeitig zu identifizieren und von Beginn an ein gemeinsames Verständnis zu entwickeln. Von verlässlichen Schätzungen profitieren alle Beteiligten auf den unterschiedlichen Ebenen. Kunde und Management erhalten eine gewisse Budgetsicherheit, die Entwicklung kann zeit- und kostenbezogen Optimierungen vornehmen, und nicht zuletzt bekommt der Anwender den optimalen Mix aus Qualität, Umfang und Liefertermin.

MEHR ZUM THEMA:

„Schätzen ist wie eine Droge – lassen wir dieses dumme Spiel!“

Geschrieben von
Dirk Dorsch
Dirk Dorsch
Dirk hat seit 2008 nahezu alle Rollen in der Java-basierten (mobile) Enterprise-Entwicklung durchgemacht. In den Jahren als Entwicklungsleiter vermisste er das Hands-on und legt nun den Fokus wieder auf die Entwicklung.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.