Titelbild Blog Remote Debugging Kubernetes

Remote Debugging von Java Apps in Kubernetes

Quickie: Schätzen mit der PERT

25. Oktober 2022

Schätzungen im Projektalltag

Veröffentlicht von Florian Storz am 28. September 2022

Ein Sales-Consultant, ein Projektmanager und ein Entwickler gehen in eine Bar.

Was sich nach dem Anfang eines schlechten Witzes anhört, hat in Wirklichkeit Potenzial für viel Drama und gegenseitige Miss- und Unverständnisse in Hülle und Fülle. Oft beginnt das Drama beim Thema dieses Textes, der Schätzung des Aufwands bzw. des Budgets eines Softwareprojekts.

Ich möchte die in meinen Augen größten Probleme bei Schätzungen beleuchten, Schätzmethoden und Lösungsansätze vorstellen. Im besten Fall dient der Text dafür, die eigene Vorgehensweise bei Schätzungen zu hinterfragen und zu verbessern.

Welche Probleme haben wir mit Schätzungen in der Softwareentwicklung?

Zusammenfassung:

Schätzungen auf Basis einer dünnen Faktenlage, genauer gesagt bei extremer Unsicherheit sind zwangsweise ungenau
Schätzungen werden mitunter auf Basis einer Problembeschreibung kommuniziert; verlässliche Schätzungen können jedoch nur auf Lösungsansätzen basieren, was wiederum eine ordentliche Analyse des Problems voraussetzt
Die Angebots- und Kommunikationshoheit gegenüber dem Kunden liegt oft bei Personen, die keine ausreichende Erfahrung in der Softwareentwicklung besitzen
Die Erwartung des Kunden wird nicht an künstlich klein gerechnete Schätzungen angepasst
Die Umsetzungs- und Schätzmethoden passen nicht zur Komplexität des Projekts
Das Festhalten an Management- und Planungsmethoden, die nicht in eine komplexer werdende und sich ständig verändernde, digitale Welt passen
Ein Team muss Features implementieren, die sie selbst nicht geschätzt haben

Hände hoch: wer wurde schon nach einem Preis für ein Projekt gefragt, zu dem nur rudimentäre Informationen vorlagen und eine Grobschätzung “nur als ungefährer Fingerzeig” dienen sollte?

Das einfache und gerne zitierte Beispiel trifft es auf den Kopf: Wenn Du einen Autoverkäufer fragst, was ein Auto kostet, wird er Dir nicht sofort einen verbindlichen Preis nennen wollen, auf den Du ihn im ungünstigsten Fall sogar festnageln kannst. Er wird Dich zuerst nach Marke, Grundausstattung und zusätzlichen Ausstattungsmerkmalen fragen und ob es auch ein gebrauchtes Modell sein kann. Und erst, wenn er alle benötigten Informationen hat, wird er eine Zahl nennen und das verbindliche Angebot erstellen. Logisch? Na klar!

Denn: nur bekannte und verstandene(!) Anforderungen und Rahmenbedingungen an ein Projekt können eingeschätzt werden.

Problem Nr. 1 und für mich das schwerwiegendste, in direkten Worten: Schätzungen auf Basis einer dünnen Faktenlage, genauer gesagt bei extremer Unsicherheit sind zwangsweise ungenau.

Unbekannte Informationen und nicht formulierte Anforderungen können nicht geschätzt werden! Lass Dich nicht zu verbindlichen Aussagen hinreißen, wenn Dir nicht genügend Informationen vorgelegt wurden. Die Schwierigkeit hierbei ist die eindeutige Definition von „genügend Informationen“. Die benötigte Menge an Informationen hängt direkt von der Erfahrung und dem Skillset einer Person ab.

Ich halte dieses Problem für als immer gegenwärtig und immens kritisch. Wir müssen uns vor Augen führen, dass wir oft nicht wissen, dass wir etwas noch nicht wissen.

Wir wissen, dass wir zu bestimmten Themen keine Informationen haben
→ wir fordern diese Informationen bei den Stakeholdern an, können diese analysieren und schätzen
Wir wissen nicht, dass wir zu bestimmten Themen keine Informationen haben
→ wir stolpern bei der Anforderungsanalyse, im schlimmsten Fall bei der Implementierung, über neue Informationen und planen z. B. neue Features ein, die den Umfang des Projekts/Produkts vergrößern und dadurch Zeit- und Budgetplanung in Gefahr bringen
Wir wissen nicht, dass wir zu bestimmten Themen keine Informationen haben und die auch unser bestehendes Wissen beeinflussen oder infrage stellen
→ wir stolpern über Informationen, die eine Umplanung von bereits spezifizierten Features erfordern, im schlimmsten Fall schon implementierte Features obsolet machen oder beeinflussen etc. und dadurch die gesamte Projektplanung torpedieren

Es gibt mit Sicherheit noch weitere Ausprägungen des Problems. Merken wir uns aber, dass mit zunehmender Komplexität die unter der Nummer 3 beschriebene Variante immer wahrscheinlicher wird. Ein erster Hinweis, dass wir Schätzungen iterativ durchführen sollten, sei es auf der Ebene von Meilensteinen oder durch ständiges Anpassen und Verfeinern einer bestehenden Schätzung.

Ein Beispiel aus meiner Praxis. Im Gespräch mit der Sales-Abteilung bei einem Gespräch über ein absehbar sehr komplexes und langwieriges Projekt habe ich einen Workshop mit dem Kunden beantragt, um Licht ins Dunkel zu bringen und essenziell wichtige Dinge für eine Schätzung zu erfahren. Ich habe vor einer Kommunikation eines ungefähren Budgetrahmens gewarnt, bevor uns nicht die wichtigsten Informationen vorliegen. Schließlich wollten auch wir als Auftragnehmer eine Budgetsicherheit bei der Realisierung des Projekts. Dieser Antrag wurde mit einem kurzen „Wir dürfen den Kunden nicht gleich von Anfang an mit Fragen nerven.“ weggewischt. „Aha“ dachte ich bei mir, „dann viel Spaß.“ Und es kam, wie es kommen musste. Eine Schätzung aufgrund der vorliegenden Informationen wurde durch die Sales-Abteilung „schön gerechnet“ (= nach unten „korrigiert“, um sich gegen die Konkurrenz durchsetzen zu können) und in einem fixen Angebot manifestiert. Der Auftrag wurde erteilt, das Sales-Personal hat mit Provisionssekt darauf angestoßen und auf halbem Weg der Realisierung des Projekts war das Budget aufgebraucht. Die Nerven lagen blank – bei unseren EntwicklerInnen, unserem Projektmanager, unserer Geschäftsführung und natürlich beim Kunden. Glückwunsch. Hätte uns nur jemand gewarnt.

Und es ist leider nicht so unüblich, dass Aufträge auf diese Weise zustande kommen. Schließlich heißt es im Vertrieb schnell zu sein. Sonst läuft die Konkurrenz mit dem Vertrag aus dem Raum.

Mein Beispiel bringt zwei weitere kritische Probleme ans Licht.

Problem Nr. 2: Die Angebots- und Kommunikationshoheit gegenüber dem Kunden liegt oft bei Personen, die keine ausreichende Erfahrung in der Softwareentwicklung besitzen.

Eine Verschiebung des Fokus von schnellen Versprechungen hin zu für alle Parteien sicheren Vertragsabschlüssen muss im Sinne der eigenen Unternehmensgesundheit eine hohe Priorität haben. Oft hilft schon ein Gespräch eines erfahrenen IT-Consultants oder Softwarearchitekten mit dem Kunden gleich zu Beginn. Wenn für den Vertragsabschluss verantwortliche Personen keine oder nur wenig Erfahrung in der Softwareentwicklung haben, müssen zur eigenen Sicherheit Personen in den Prozess involviert werden, die diese Erfahrung mit sich bringen.

Problem Nr. 3: Die Erwartung des Kunden wird nicht an künstlich klein gerechnete Schätzungen angepasst.

Eine Aufwandsschätzung bezieht sich immer auf die bekannte Menge an Informationen. Eine Änderung nur eines der beiden Parameter muss auch eine Anpassung des anderen Parameters nach sich ziehen. Es ist Entwicklungsteams nicht zuzumuten, dass diese die gleiche Arbeit in kürzerer Zeit leisten. Qualitätseinbußen und Budgetüberschreitungen sind so in der Regel vorprogrammiert.

Um es deutlich zu benennen: wenn Entwicklungsteams einen Aufwand von 15 Tagen schätzen und ein Angebot über 10 Tagen erstellt wird, um konkurrenzfähig zu bleiben, darf von den Schätzenden nicht erwartet werden, dass sie die Implementierung in dieser gekürzten Zeit erledigen können. Man verschiebt damit die gesamte Verantwortung hinsichtlich des Projekterfolgs. Ein offensichtliches Fehlverhalten und ein leider gar nicht mal so seltenes Phänomen in Agenturen.

Problem Nr. 4: Die Umsetzungs- und Schätzmethoden passen nicht zur Komplexität des Projekts.

Ich plädiere seit je her dafür, dass mit wachsender Komplexität eines Softwareprojekts eine iterative und agile Entwicklung und damit auch eine iterative Aufwandseinschätzung oder zumindest eine Verfeinerung einer ursprünglichen Schätzung einhergehen muss. Ob wir Projekte in Meilensteine unterteilen oder tatsächlich ein agiles Framework einsetzen ist dabei nebensächlich. Wir können nur überschaubare und damit vorstellbare Arbeitspakete abschätzen.
Bei kleinen Projekten machen unter Umständen klassische Vorgehen mehr Sinn.
Was dagegen keinen Sinn ergibt, ist eine verbindliche und komplette Vorhersage zu Beginn eines iterativ entwickelten Projekts. Agile Frameworks begegnen diesen Problemen deshalb mit eigenen Schätzmethoden, die man nutzen sollte.

Dass Kunden oder das Management eine im Voraus sichere Budgetplanung machen wollen, ist verständlich. Dies führt in vielen Fällen jedoch zu den zuvor beschriebenen Problemen. Und damit ist auch der Kunde oder das Management ein Problem in dieser Gleichung.

Problem Nr. 5: Das Festhalten an Management- und Planungsmethoden, die nicht in eine komplexer werdende und sich ständig verändernde, digitale Welt passen.

Es muss Schluss sein, dass sich die Rahmenbedingungen einer komplexen Softwareentwicklung dem übergeordneten Management anpassen! Vielmehr muss sich das Management der Realität stellen und die eigenen Vorgehensweisen anpassen, verfeinern, ändern. Nur wenn dies passiert, lassen sich Probleme bei Aufwandsschätzungen lösen und damit bei der Entwicklung komplexer Software insgesamt.

Ein „du musst lernen zuverlässiger zu schätzen“ kommt dabei oft genau denen schnell über die Lippen, die durch eigene Unflexibilität ebendiese Probleme verursachen. „Dann liefere mir mehr Informationen und passe Deine Planung an“ sollte hier die Antwort sein.

Ein letzter Punkt, den ich ansprechen möchte, ist die Schätzverantwortung.

Problem Nr. 6: Ein Team muss Features implementieren, die sie selbst nicht geschätzt haben.

Eine Person, die 10 Jahre Erfahrung in der Entwicklung komplexer Software hat, wird zu einer anderen Einschätzung des zu erwartenden Aufwands kommen wie eine Person, die erst 2 Jahre „dabei ist“. Genauso verhält es sich mit Theoretikern und Praktikern. Wenn Schätzsicherheit höchstes Gebot ist, dann müssen die Personen, die das Projekt umsetzen sollen, die Schätzung der Features ausarbeiten. Es geht in erster Linie darum, welchen Aufwand dieses Team mit ihrem Know-how und ihrer Spezialisierung vermutlich haben wird. Es schätzt sich also selbst ein – das sollte von niemand Anderem getan werden. Leider sieht es gerade im klassischen Projektvorgehen vielfach anders aus. Agile Frameworks bieten dafür dankenswerterweise Hilfsmittel an, um dieses Problem aufzulösen.

Mein Fazit und meine These: Menschen sind schlecht darin, Aufwände verlässlich zu schätzen. Aber noch viel schlechter darin, Schätzungen zu kommunizieren oder weiterzuverarbeiten. Und dieses Unvermögen steigt bei immer komplexer werdenden Softwarelösungen immens.

Es gibt Mittel und Wege, diesen Problemen entgegenzutreten.

Wie lassen sich Probleme bei Schätzungen in der Softwareentwicklung minimieren?

Zusammenfassung:

Wissen ist Macht – Requirements Engineering hilft bei der Schaffung einer Schätzbasis
Die Projektplanung muss an die Komplexität der zu liefernden Lösung und deren Umgebung angepasst werden
Schätzungen sollten des Projektverlaufes regelmäßig geprüft und dem aktuellen Wissensstand angepasst werden
Die richtige Schätz- und Planungsmethode ist der Schlüssel zu mehr Verlässlichkeit und Planbarkeit
Schätzungen von den implementierenden Teams besitzen höheren Wert als Schätzungen von beratenden oder planenden Personen
Das Einbinden der Schätzenden in die Kundenkommunikation vermeidet Missverständnisse
Verantwortung im Rahmen der eigenen Rollen zu übernehmen und die eigenen Grenzen zu kennen sind notwendige und herausragende Merkmale, um zu einer realistischen Einschätzung eines Projekts zu kommen

Wenden wir uns an diesem Punkt von guten und schlechten Praktiken im Projektmanagement ab, treten wir einen Schritt zurück und fokussieren wir uns darauf, wie wir Schätzungen so realistisch wie möglich gestalten können.

Wissen ist Macht – Requirements Engineering hilft

Führen wir uns zunächst vor Augen, dass eine Schätzung auf Wissen beruht. Bei Projektanfragen und nach dem ersten Gespräch mit dem Kunden kennen wir meist nicht mehr als „Überschriften“ oder Anforderungen, die sehr allgemein und nicht konkret genug formuliert sind. Je mehr wir solche „Überschriften“ hinterfragen und mit dem Kunden bzw. mit den Stakeholdern ins Gespräch gehen, desto mehr erfahren wir über die kleinen Bausteine, über die „kleinen Überschriften“, wenn man so will.

Hier sei erwähnt, dass die Vorstellung, bei Beginn der Umsetzung sei „alles klar“ und jede benötigte Information verfügbar, reine Utopie ist. Es wird immer wieder nötig sein, auch während der Umsetzung, neue Anforderungen, neue Informationen usw. zu analysieren und so dem gewonnenen Wissen hinzuzufügen.
Plant deshalb immer genügend Zeit für Anforderungsmanagement und Analyse in Eure Projekte ein. Selbst wenn ihr bei klassischen Projekten im Idealfall eine Phase der Anforderungsanalyse vor der Umsetzung vorgesehen habt.

Menge an Informationen im Projektverlauf bei vorgelagerter Anforderungsanalyse

Und ja, auch in agilen Projekte ist ein konsequentes Anforderungsmanagement immens wichtig. Zum einen ist dies die Aufgabe eines Product Owners, zum anderen ist die Anforderungsanalyse auch in agilen Frameworks mit Refinements o. ä. Events abgebildet. Diese Arbeit ist bei einem iterativen Vorgehen als ständiger und begleitender Posten zur Entwicklung vorzusehen und durchzuführen.

Ich habe in den letzten Jahren die abwegigsten Begründungen (meist Zeit/Geld) gehört, wieso man auf eine ordentlich durchgeführte Anforderungsanalyse verzichten möchte. Und ich sah die Projekte so gut wie immer scheitern. Größtenteils durch ein erhebliches Überschreiten des vereinbarten Budgets und des Zeitrahmens. Und dies war fast ausnahmslos auf unzählbare Korrekturschleifen zurückzuführen, weil *Trommelwirbel* Anforderungen nicht verstanden oder nicht konkret genug formuliert und spezifiziert wurden.

Projektplanung an eine komplexe Realität anpassen

Breche komplexe und absehbar langwierige Projekte in kleine und schätzbare Pakete auf und plane diese als aufeinander folgende Meilensteine oder plane das Projekt von Beginn an als iterative Umsetzung. Je komplexer ein Projekt, desto mehr helfen agile Frameworks – auch bei der Aufwandsschätzung!

Kleinere Pakete lassen sich besser planen, reduzieren das Risiko aller Beteiligten und vereinfachen die Budgetplanung. Die Schätzungen werden stark vereinfacht und können neue Bedingungen berücksichtigen, die sich seit dem Projektstart geändert oder neu ergeben haben.

Eine Herausforderung kann sein, Deinen Kunden von diesen Vorteilen zu überzeugen, wenn dieser von Beginn an mit fixen Budgets kalkulieren muss. Vermeide, dass diese Unflexibilität zum Nachteil für Dich wird und rechne diesen Aspekt bei der Risikobetrachtung als Auftragnehmer mit ein! Gelegentlich kann es besser sein, einen Auftrag abzulehnen.

Schätzungen regelmäßig prüfen und anpassen

Wenn eine Schätzung für ein komplettes Projekt oder für einzelne Pakete schon weit im Voraus nötig war, lohnt sich eine regelmäßige Betrachtung. Die Projektpartner sollten sich in diesen Fällen auf eine regelmäßige Überprüfung der Schätzungen einigen und sie bei Bedarf anpassen, um alle neuen Rahmenbedingungen und Anforderungen einfließen lassen zu können. Sowohl dem Auftraggeber als auch dem Auftragnehmer muss klar sein, dass dies unter Umständen Budget- oder Scopeänderungen nach sich ziehen kann. Deshalb ist es wichtig, dass dieser Umstand klar und transparent kommuniziert wird.

Die richtige Schätz- und Planungsmethode nutzen

Je nach Projektnatur, je nach Anforderung des Kunden und je nach Umsetzungsmethodik eignen sich gewissen Schätzmethoden besser als andere Methoden. Nachfolgend versuche ich einen Überblick über ebendiese Methoden zu geben. Diese Übersicht ist sicherlich nicht komplett. Sie deckt Methoden ab, mit denen ich in den letzten Jahren in Berührung gekommen bin. Auch finden sich hier Methoden, die eher der Planung und nicht der eigentlichen Schätzung dienen.

Top-Down-Methode

Klassische Planungs- und Schätzmethode
Geeignet, wenn eine fixe Projektlaufzeit bzw. das Datum des Projektendes vorgegeben und die Umsetzung in einem klassischen Vorgehen geplant ist
Diese Schätzmethode setzt voraus, dass Anforderungen vorgelagert analysiert und verstanden wurden
Die Granularität der Schätzung bestimmt den Zeitaufwand für die Schätzung, welcher ebenfalls eingeplant werden muss

Diese klassische Schätzmethode eignet sich in erster Linie für Projektszenarien mit anspruchsvoller Zeit- oder Budgetvorgabe. Diese Vorgabe ist der Ausgangspunkt für alle weiteren Schritte hin zu einer Schätzung. Die Zeitspanne kann in Phasen, also kleinere Zeitspannen, unterteilt werden, die uns die Möglichkeit der Kontrolle und der Nachjustierung in der Planung geben. Anforderungen/Features können nun über diese Phasen hinweg geplant werden. Dies geschieht eventuell sogar thematisch, also fachlich verwandte Anforderungen werden gemeinsam in einem Meilenstein oder in einer Phase geplant. Um eine realistische Schätzung zu ermöglichen, müssen die Anforderungen noch in Tasks aufgeteilt und einzeln geschätzt werden. Das Ergebnis ist eine Planung “von oben nach unten” und eine im besten Fall kleinteilige Schätzung von “unten nach oben”. In vielen Fällen wird auf das Erstellen von Tasks verzichtet und die Anforderungen selbst werden geschätzt, was zwar Zeit spart, aber eine gewisse Ungenauigkeit mit sich bringt. Auch werden die Schätzungen bei dieser Methode oft nicht von den EntwicklerInnen selbst durchgeführt, was wiederum die Ungenauigkeit erhöht.

Ergibt die Schätzung eine längere Projektlaufzeit als vorgegeben, muss nachjustiert werden. Dies bedeutet, dass Anforderungen mit dem geringsten Geschäftswert nicht umgesetzt werden, um die Zeitvorgabe nicht zu überschreiten. Es gilt also: Man implementiert so viele Features, die in der vorgegebenen Zeit möglich sind.

Mehr Informationen: https://www.projektmagazin.de/glossarterm/top-down

Bottom-Up-Methode

Klassische Planungs- und Schätzmethode
Geeignet, wenn Anforderungen bekannt sind, die Projektlaufzeit nicht vorgegeben und die Umsetzung in einem klassischen Vorgehen geplant ist
Diese Schätzmethode setzt voraus, dass Anforderungen vorgelagert analysiert und verstanden wurden
Die Granularität der Schätzung bestimmt den Zeitaufwand für die Schätzung, welcher ebenfalls eingeplant werden muss

Bottom-Up, Projektlaufzeit ergibt sich aus der Summe aller Schätzungen, Schätzungen auf Task- oder Featureebene

Ebenfalls im klassischen Umfeld bekannt, setzt die Methode auf eine vorgelagerte Analyse der Anforderungen. Ausgangspunkt ist hier im Gegensatz zur Top-Down-Schätzung der Pool der bekannten Anforderungen. Diese können in einzelne Tasks/Aufgaben aufgeteilt und geschätzt werden. Darauf wird allerdings aus Zeitgründen oft verzichtet – auch wenn dies ungenauere Schätzungen zur Folge hat.
Die Schätzungen werden aufsummiert und ergeben somit eine voraussichtliche Laufzeit des Projekts.

Diese Methode ist gegenüber der Top-Down-Methode oft genauer. Sie nimmt aber in der Regel mehr Zeit in Anspruch. Und wie schon erwähnt wurde, hängt die Genauigkeit auch sehr von dem Wissen der Schätzenden ab.

Mehr Informationen: https://www.projektmagazin.de/glossarterm/bottom-up

Drei-Punkt/Zeiten-Schätzung / Program evaluation and review technique (PERT)

Für die Schätzung ganzer Projekte und einzelner Features geeignet
Geeignet für klassische und iterative Vorgehensmodelle
Diese Schätzmethode setzt voraus, dass Anforderungen vorgelagert analysiert und verstanden wurden
Die Granularität der Schätzung bestimmt den Zeitaufwand für die Schätzung, welcher ebenfalls eingeplant werden muss

Drei-Punkt/Zeiten-Schätzung / PERT, Berechnung der Schätzwerte

Eine Technik, die Unsicherheiten berücksichtigen möchte, ist die Drei-Punkt-Schätzung, Drei-Zeiten-Schätzung oder einfach die nach der englischen Abkürzung benannten “PERT”. Diese Technik wurde schon um 1958 herum entwickelt und erstmalig in einem Projekt angewandt, welches extreme Unsicherheiten berücksichtigen und die Schätzungen deshalb auf Wahrscheinlichkeiten beruhen mussten.

Je kleinteiliger die zu schätzenden Pakete sind, desto besser sind sie schätzbar. Hat man dies getan, wird jedes Paket optimistisch (Idealfall), realistisch (evtl. Wert aus Erfahrung) und pessimistisch (Worst Case) eingeschätzt. Mithilfe der in der Illustration gezeigten Formel berechnet man nun einen Schätzwert, der „wahrscheinlich“ auf dieses Paket zutrifft. Teams passen unter Umständen die Formel etwas an, wenn die berechneten Schätzwerte zur letztlich erbrachten Zeit auffallend oft in die positive oder negative Richtung abweichen.

Die Methode eignet sich sowohl in klassischen und iterativen Projektvorgehen zur Schätzung des zu erwartenden Aufwands. Sie lässt sich sowohl auf große Meilensteine anwenden als auch z. B. nur für Schätzungen einzelner Features.

Hinweis: Diese Technik werden wir in einem weiteren Blogartikel näher beleuchten.

Mehr Informationen: https://de.wikipedia.org/wiki/Program_evaluation_and_review_technique

Zwei-Punkt/Zeiten-Schätzung

Von-Bis-Angaben sind wohl die häufigste Form von Schätzungen, wenn es um eine erste Hausnummer für ein Feature oder Projekt geht. Entgegen der PERT-Technik wird hier kein realistischer Wert verwendet. Einzig die optimistische und pessimistische Schätzung werden berücksichtigt. Meine Erfahrung ist, dass in den meisten Fällen der Mittelwert dieser zwei Werte für eine Kommunikation Richtung Auftraggeber verwendet wird, obwohl Von-Bis-Angaben ehrlicher wären und die Unsicherheit bei der Schätzung widerspiegeln. Auch wenn diese Technik für eine schnelle Einschätzung geeignet ist, halte ich sie für verbindliche Aussagen oder gar vertragliche Vereinbarungen unangebracht. Ich empfehle dringend, solche Schätzungen zu verfeinern.

Mehr Informationen: https://de.wikipedia.org/wiki/Zwei-Zeiten-Methode

Analoge Schätzung

Hat man in der Vergangenheit schon ähnliche Projekte umgesetzt, kann man deren Informationen über Implementierungsdauer, Schwierigkeiten usw. zur Schätzung nutzen. Je genauer dieser Informationen sind, desto genauer wird die Schätzung.

Wenn Sie mit der Implementierung von Software beauftragt sind, die von Projekt zu Projekt die gleichen Komponenten nutzen kann, ist diese Technik gut geeignet.

Mehr Informationen: https://www.projektmagazin.de/glossarterm/analogie-methode

Parametrische Schätzung

Auch diese Technik nutzt Informationen aus vergangenen Projekten. Hierbei wird versucht, Unterschiede zwischen beiden Projekten zu identifizieren, diese zu schätzen und so den Gesamtaufwand zu bestimmen.

Wie bei der analogen Schätzung eignet sich diese Technik in einem Umfeld, in dem sich die Projekte sehr ähneln, es aber zu Unterschieden kommen kann. Dies ist zum Beispiel bei Anpassungen von White-Label-Lösungen der Fall, die an unterschiedliche Bedürfnisse angepasst werden müssen.

Mehr Informationen: https://www.projektmagazin.de/glossarterm/parametrische-sch%C3%A4tzverfahren

Story Points, Shirtgrößen etc.

Persönlich finde eine Schätzaussage in Stunden, Tagen o. ä. aufgrund von Story Points nicht geeignet. Da Story Points primär die erwartete Komplexität einer Aufgabe/Anforderung widerspiegeln sollen, muss diese erst noch in eine zeitliche Angabe umgewandelt werden. Oft werden die Story Points mit dem Zeitaufwand einer vergangenen 1-Story-Point-Anforderung multipliziert, um eine Aussage zu Zeit und Budget treffen zu können. Wenn also eine Aufgabe mit 1 Story Point 1,5 Stunden für eine Implementierung in Anspruch genommen hat, dauert die Implementierung für eine 8-Story-Point-Aufgabe in Summe 12 Stunden, richtig? Nicht unbedingt.

Oft bleibt außer Acht, dass Anforderungen mit vergleichbarer Komplexität nicht zwingend eine ebenso vergleichbare Zeit für die Implementierung beanspruchen. Komplexe Aufgaben können zum Beispiel von erfahrenen EntwicklerInnen schneller umgesetzt werden oder sie sind schlichtweg schnell erledigt. Im Gegensatz dazu können Aufgaben mit niedriger Komplexität lange Zeit in Anspruch nehmen, da es sich vielleicht einfach nur um Fleißarbeit handelt.

In meinen Augen macht, wenn eine Zeiteinschätzung das Ziel ist, ein Mapping der Aufgaben mit Shirtgrößen oder anderen Größenangaben mehr Sinn. Dabei können wir den Größen eine definierte Anzahl an Stunden zuordnen. Die schätzenden Personen weisen den einzelnen Aufgaben diese Größen zu und ermitteln somit nach und nach den zu erwartenden Aufwand für einen Sprint oder ein Projekt.

Die Verwendung von Shirtgrößen hat den Vorteil, dass z. B. hinter „L“ auch Von-Bis-Angaben stehen können. Diese müssen dann natürlich in der Gesamteinschätzung berücksichtigt werden. Für den Schätzer wird der Schätzvorgang aber erheblich erleichtert.

Mehr Informationen: https://www.projektmagazin.de/glossarterm/story-point

#NoEstimates

Einen radikaleren und grundverschiedenen Ansatz verfolgt insbesondere die Idee, die unter dem Hashtag #NoEstimates diskutiert wurde und Aufsehen erregt hat. Dabei bedeutet radikal zu sein nichts weiter, als eine Vorgehensweise zu finden und zu nutzen, die alle genannten Probleme von vornherein vermeidet.

Die Idee bedeutet nicht, dass keinerlei Vorhersagen gemacht werden können oder sollen. Vielmehr räumt dieser Ansatz mit den klassischen Techniken in einer immer komplexeren Welt in der Softwareentwicklung auf. Stattdessen setzt man auf historische Informationen und auf die steigende Sicherheit während der Projektlaufzeit.

Unter dem genannten Hashtag findet man viele Artikel zu diesem Thema und es lohnt sich, einen Blick zu riskieren. Zusammengefasst kann gesagt werden, dass die Idee zum Ziel hat

Aufwände für ungenaue Schätzungen in einem sich ständig verändernden Umfeld zu vermeiden
und vergangene Iterationen/Zyklen und die Erfahrungen aus diesen (in einer agilen Vorgehensweise der Implementierung) für Voraussagen zu nutzen.

Ferner werden auch verschiedene Ideen diskutiert, die eine Risikominderung als Ziel haben. Gelingen kann dies zum Beispiel durch eine gestückelte Finanzierung von Meilensteinen oder Features und aber auch durch den Vorsatz, jederzeit bereit zu sein, das Projekt bereitzustellen oder zu beenden.

Nutzt man das Wissen vorheriger Sprints oder Meilensteinen, werden Voraussagen während der Implementierung immer genauer. Diese Idee steht im Gegensatz zu klassischen Planungsmethoden, die eine fixe Budgetierung über einen langen Zeitraum als Ziel haben. Um dieses Problem auflösen zu können, muss das Management bereit sein, die eigene Vorgehensweisen zu hinterfragen und Schritte auf die operativ tätigen Menschen zugehen.

Wie bei jeder Methode gibt es auch hier Befürworter und Gegner dieser Vorgehensweise.

Mehr Informationen:

Schätzungen aus erster Hand

Gemäß dem DevOps-Ansatz “You build it, you run it.” würde ich gerne ein “You estimate it, you build it.” formulieren.

SoftwareentwicklerInnen konzipieren und implementieren Lösungen. Sie erarbeiten den aus ihrer Sicht passendsten Lösungsansatz in dem jeweils durch Rahmenbedingungen eingegrenzten und gegebenen Lösungsraum. Dieser Lösungsansatz gilt es zu schätzen!

Es hilft nicht, wenn EntwicklerInnen für eine Lösungsentwicklung einen vorgegebenen Zeitrahmen „diktiert“ bekommen. Schlimmer noch, wenn dieser Rahmen von Menschen vorgegeben wird, die den Lösungsraum nicht kennen oder schlichtweg keine Erfahrung in der Entwicklung haben. Solch ein Vorgehen erzeugt vieles – nur keine Motivation unter Projektbeteiligten.

Deshalb gilt: Genauer, wie durch die umsetzenden Personen, wird eine Schätzung nicht erfolgen können. Denn sie können auch sich selbst am besten einschätzen und das Know-how des Teams einpreisen. Dies ist der Grund, weshalb u. a. im Scrum Framework immer von Schätzungen durch das Team ausgegangen wird und diese regelmäßig durchgeführt werden.

Einbinden des Schätzenden in die Kundenkommunikation

Jeder Schätzung folgen Fragen. Sowohl bei der internen Kommunikation als auch in der externen Kundenkommunikation. Meist sind es Rückfragen, die den Kontext der Schätzung beleuchten wollen. Verständlicherweise möchte man meist den angedachten Lösungsansatz kennen, dem die Schätzungen zugrunde liegen. Auch wenn dieser vielleicht schon in schriftlicher oder mündlicher Form dargelegt wurde, kommt es immer wieder zu Detailfragen. Es sollte darauf geachtet werden, dass die Beantwortung dieser Fragen hauptsächlich durch die Schätzer erfolgen, um Missverständnisse und umständliche Kommunikationswege zu vermeiden.

Verantwortung übernehmen, eigene Grenzen kennen

Verschiedene Rollen bedeuten verschiedene Verantwortungsbereiche. Und wie immer gilt: Ist man zu einer Erfüllung einer Aufgabe in dem eigenen Verantwortungsbereich nicht fähig, aus welchen Gründen auch immer, muss Hilfe beschafft werden. Das setzt voraus, dass man die eigenen Schwächen und Grenzen kennt. Und ja, es setzt auch voraus, dass man gelegentlich über seinen eigenen Schatten springt. Falscher Stolz bringt niemandem etwas. Zuallerletzt einem selbst.

Der Kunde, also die Partei, die Schätzungen für eine Softwarelösung einfordert, muss auf Nachfrage Informationen liefern, die zu einer realistischen Schätzung notwendig sind. Im besten Fall werden fehlende Informationen von Auftraggeber und Auftragnehmer auf Augenhöhe besprochen, also Personen, die fachlich oder thematisch die Anforderungen diskutieren können. Dem Alter der „stillen Post“, also dass die Kommunikation nur über einen Punkt erfolgen darf, sind wir und auch die Softwareentwicklung längst entwachsen.

Der Auftragnehmer muss dafür Sorge tragen, dass er eine zum vereinbarten Projektvorgehen passende Schätzmethode nutzt und die dafür notwendigen Informationen in der benötigten Detailtiefe vorliegen hat. Sind Wissenslücken bezüglich der Anforderungen intern nicht zu füllen, muss mit dem Kunden zusammen an der Informationsbeschaffung gearbeitet werden. Und dies in direkter Kommunikation, ohne Umwege.

SchätzerInnen und EntwicklerInnen sollten jederzeit die Dinge einfordern, die sie zur Realisierung einer Aufgabe benötigen. Im Kontext der Schätzungen sind dies Informationen, die zur Betrachtung von Anforderungen nötig sind. Direkt an diese Personen gerichtet: Fordert Informationen ein, die zur Schließung von Wissenslücken nötig sind. Euer Name steht in Verbindung mit Euren Schätzungen. Erinnert andere Personen notfalls an ihre eigenen Aufgaben und Verantwortlichkeiten.

Lasst uns lernen – passen wir uns den komplexen Gegebenheiten an

Wie wir gesehen haben, sind Schätzungen oft komplex und langwierig. Allerdings steuern wir durch Schätzrunden auch einen Teil zur Risikominderung bei. Wir lernen Details der zu implementierenden Software und deren Umgebung kennen und erweitern durch konsequentes Requirements Engineering ständig unseren Horizont. Wenn Ihr den einen oder anderen Ratschlag beherzigt, würde ich mich sehr darüber freuen. Ihr werdet merken, dass Ihr Euch das Schätzen und auch den Umgang damit sehr erleichtern könnt.

Jedes Team muss für sich lernen, welche Technik es am besten beherrscht und wann es diese einsetzen muss. Experimentiert, macht Dinge anders, überprüft Euch selbst, lernt, was Euch und Eurem Umfeld am besten liegt und gelingt.
Das Management, welches sehr an risikoarmen Projekten interessiert ist, sollte Euch Freiraum geben, Euch in die Kommunikation Richtung Auftraggeber einbinden und wenn nötig eigene Vorgehensweisen überprüfen und anpassen. Nur zusammen gelingen komplexe Softwareprojekte.

Seid jederzeit transparent dem Kunden gegenüber und fordert ihn. Er ist die Quelle der Anforderungen und hilft Euch, Wissenslücken zu schließen. Verzichtet niemals aus falschen Beweggründen auf dieses Wissen – auch wenn dies längere Schätzrunden nach sich zieht oder intensives Anforderungsmanagement bedeutet.

Schätzungen werden zukünftig sicherlich nicht einfacher. Wie man sieht, werden Schätzvorhaben stark von außen beeinflusst. Es hilft hier aber nicht, in eine Verteidigungsstellung zu gehen. Wir müssen mit der immer komplexer werdenden Welt mitziehen und neue Wege finden, mit ihr umgehen zu können. Dies betrifft Top-Management, Projektmanagement, Beratung, Entwicklung und Betrieb gleichermaßen. Lasst Euch darauf ein – einen anderen Weg gibt es nicht.

Wenn Euch die beschriebenen Probleme bekannt vorkommen und ihr Unterstützung oder Beratung benötigt, dann zögert nicht uns unter https://www.devlix.de/kontakt/ zu kontaktieren.