Projektmanagement Softwareentwicklung

Softwareentwicklung für Projektleiter, Manager und Entwickler

IT-Projektmanagement RSS
  • Aufwandsschätzung: Messen Sie schon oder schätzen Sie noch?

    Jörg Hinrichs

    Aufwandsschätzung: Das schwarze Loch der Softwareentwicklung

    Aufwandsschätzungen in der Softwareentwicklung sind in etwa so zuverlässig wie die Wettervorhersage. Oder die Deutsche Bahn. Oder der Standby-Betrieb von meinem Laptop.

    Wieso ist das so? In anderen Bereichen kann man doch auch zuverlässig schätzen. Wenn Sie sich z.B. ein Haus bauen lassen, dann kann Ihnen der Bauherr praktisch auf den Tausender genau sagen was das kosten wird. Stellen Sie sich mal vor, wir hätten bei den Aufwandsschätzungen Ungenauigkeiten von 1% oder weniger. Davon können wir leider nur träumen.

    Auf der anderen Seite: Es ist nicht gerade so, als ob es im Bauwesen keine Negativbeispiele gäbe. Ich sage nur: Elbphilharmonie. Und Sie kennen bestimmt direkt bei Ihnen vor der Haustür auch so ein Beispiel. Das sind Fehlschätzungen in Größenordnungen, da fühlt man sich als Software-Projektleiter schon richtig heimisch. Was ist da schief gelaufen? Was ist anders als bei einem normalen Haus?

    Nun, das Wohnhaus hat der Bauherr wahrscheinlich schon dutzende Male gebaut. Da verfügt er einfach über sehr viele Erfahrungswerte. Die Elbphilharmonie dagegen wurde vorher noch nie gebaut. Alles ist neu, von der Planung bis zur Realisierung.

    Und so ist es bei Software auch: Irgendetwas ist immer neu. Meistens sogar sehr viel. Neue Fachgebiete, neue Tools, neue Prozesse, neue Technologien, nicht zu vergessen neue Menschen. Das macht das Schätzen unglaublich schwer.

    Wieviele Perlen sind das?

    Wie viele Perlen mögen das auf dem Foto wohl sein? Auf den ersten Blick schwer zu sagen.

    Mit einigen Tricks kommt man trotzdem zu ganz guten Schätzungen. Zum Beispiel können Sie einen kleinen Teil des Bildes auszählen und dann hochrechnen. Das macht man in der Softwareentwicklung auch so: Der Aufwand wird in handliche Teile zerlegt, die man dann ganz gut einzeln schätzen kann.
    Erfahrung ist auch sehr wichtig. Wenn Sie ein paar mal geschätzt haben und das mit den tatsächlichen Ergebnissen vergleichen, dann werden Sie auf jeden Fall genauer werden.

    Aber nehmen wir einmal an, die Perlen liegen nicht alle so schön flach nebeneinander sondern befinden sich in einem großen Glas oder in einer Schüssel. Da wird es schon viel schwieriger.

    Perlen in der Schüssel

    Und Softwareentwicklung kann noch viel komplizierter sein. Um bei der Analogie zu bleiben: Da sehen Sie dann nicht mehr, was sich im Inneren befindet. Vielleicht gibt es da größere Perlen. Oder ein großes Loch. Oder Perlen, deren Löcher so klein sind, dass sie nicht mehr auf das Band passen, welches Sie eigentlich für die Perlenkette benutzen wollten.

    Projektaufwände: Das Henne-Ei-Problem

    Aufgrund der systembedingten Schwierigkeiten in der Softwareentwicklung sind Aufwandsschätzungen immer mit einem Risiko verbunden. Und je nach Rahmenbedingungen kann dieses Risiko sogar ziemlich groß sein.

    Je mehr Sie über die Software und das dazugehörige Fachgebiet wissen, desto geringer wird dieses Risiko und desto genauer wird auch die Aufwandsschätzung.

    Die Analyse hilft Ihnen dabei, die fachlichen Grundlagen und den Kontext der Anforderung zu verstehen. Danach werden Sie schon eine wesentlich bessere Schätzung machen können. Das Design der Software lässt weitere weiße Flecken auf der Landkarte verschwinden. Und wenn Sie beides professionell gemacht haben, sollten Sie jetzt auch in der Lage sein, eine genaue Aufwandsschätzung abzuliefern.

    Aber so läuft das Spiel leider nicht. Wie heißt es so schön: “Das erste, was in einem Softwareprojekt festgelegt wird, ist der Abgabetermin!”

    Sie brauchen Schätzungen von Anfang an, für Ihre Projektplanung oder für Ihr Angebot. Möglichst schnell und möglichst genau. Zu einem Zeitpunkt, wo Sie eigentlich viel zu wenig über die zu erstellende Software wissen.

    Sie haben einfach keine Zeit, Wochen oder Monate mit sorgfältiger Analyse und Design zu verbringen. Vielleicht arbeiten Sie auch mit einem iterativ inkrementellen Entwicklungsprozess, wo Sie immer nur kleine Teile der Software genauer betrachten.

    Sie können sich auch schlecht hinstellen und sagen: “Wir wissen eigentlich noch fast gar nichts und deshalb können wir auch keine zuverlässigen Schätzungen abgeben. Wir fangen aber schon mal an und im Verlauf des Projektes werden wir auch immer bessere Aufwandsschätzungen liefern können.”

    Versuchen Sie das mal dem Management oder dem Auftraggeber beizubringen. Die werden über solch vage Aussagen gar nicht glücklich sein. Und wenn Sie als externer Dienstleister bei einem Kunden Software erstellen wird dieser Sie vermutlich gleich wieder zur Tür hinausbegleiten.

    Das ist jetzt vielleicht etwas überspitzt dargestellt. Tatsächlich arbeiten agile Softwareprojekte ganz ähnlich und die sind ja inzwischen relativ weit verbreitet. Aber dann muss auch die Umgebung dazu passen und sich mit dieser Unsicherheit arrangieren. Das setzt Vertrauen voraus, welches nicht überall von Anfang an vorhanden ist.

    Also, was tun?

    Die Relativitätstheorie der Aufwandsschätzung

    Kommen wir noch einmal zur Analogie mit den Perlen zurück. Ohne viel Erfahrung ist es schwer die Anzahl der Perlen in der Schüssel zu schätzen. Dagegen ist es sehr viel leichter, zwei Schüsseln voller Perlen miteinander zu vergleichen. Sie werden ohne großen Aufwand und sehr zuverlässig sagen können, in welcher Schüssel sich mehr Perlen befinden (oder ob die Schüsseln annähernd gleich viele Perlen enthalten).

    Sie verwenden dazu ihr Augenmaß. Und tatsächlich kann man dieses Prinzip auf die Aufwandsschätzung in der Softwareentwicklung übertragen. Dazu vergleichen Sie einfach Features untereinander und bringen diese in eine Reihenfolge bezogen auf den Aufwand. Wir schätzen also nicht absolute Aufwände, sondern wir vergleichen Aufwände untereinander.

    Was haben wir dadurch gewonnen? Erst einmal noch nicht sehr viel. Sie haben immer noch einen Fertigstellungstermin zu definieren (oder zu überprüfen) und dafür brauchen Sie letztendlich absolute Aufwände in Tagen oder Wochen.

    Was Ihnen jetzt noch fehlt ist ein Maßstab, mit dem sich diese relativen Einstufungen in absolute Aufwände übersetzen lassen. Vielleicht haben Sie ja Erfahrungswerte aus anderen Projekten, aus denen Sie auf die tatsächlichen Aufwände zurück schließen können.

    Wenn Sie da auf der ganz grünen Wiese anfangen: Sorry, dann wird es ein bisschen Zeit kosten, diesen Maßstab zu erstellen. Nehmen wir mal an, das ist der Fall. Wie geht es dann weiter?

    Absolute Aufwandsschätzung: Messen Sie schon oder schätzen Sie noch?

    Der nächstliegendste Ansatz besteht darin, die Entwickler den Aufwand direkt schätzen zu lassen, diesmal in Tagen oder Wochen. Leider tendieren diese Schätzungen dazu, permanent zu gering zu sein.

    Dieser Ansatz ist auch noch aus anderen Gründen problematisch:

    • Entwickler schätzen meist aufgrund ihrer eigenen Produktivität. Diese kann aber sehr unterschiedlich sein. Untersuchungen haben Abweichungen bis zu einer Größenordnung (also Faktor 10!) zwischen verschiedenen Entwicklern ermittelt.
    • Sie müssen sehr genau definieren, welche Tätigkeiten in der Aufwandsschätzung enthalten sind, damit es nicht unterschiedliche Bemessungsgrundlagen gibt.
    • Wenn man als Entwickler zu viele schlechte Erfahrungen gemacht hat baut man vielleicht große Zeitpuffer in die Aufwandsschätzung ein, die oft nicht notwendig sind (z.B. Geschätzter Aufwand = Vermuteter Aufwand * 2 + x%).

    Deshalb, und aus den Gründen, die im nächsten Abschnitt genannt werden, sollten Sie Ihre Planung nicht auf Schätzungen sondern auf Messungen basieren lassen. Protokollieren Sie die Aufwände: Von der ersten Idee bis zur Fertigstellung des Benutzerhandbuchs – alles, was für Ihr Projekt relevant ist.

    Wenn irgend möglich erledigen Sie diese Arbeit selbst und lassen die Entwickler dabei außen vor. Die haben genug andere Dinge im Kopf und betrachten dass als nutzlose Zusatzarbeit. Und deswegen werden sie das auch fast immer bestenfalls halbherzig erledigen. Schlimmstenfalls gar nicht.

    Sie benötigen auch keine minutengenauen Aufwände: Es reicht, wenn Sie für einen bestimmten Arbeitsblock (z.B. ein Feature) sagen können wie hoch der Aufwand insgesamt ist. Wenn Sie das außerdem pro Entwickler angeben können: Um so besser.

    Manchmal ist die Aufteilung auf die jeweiligen Entwickler aber nicht eindeutig, da mehrere Entwickler am selben Thema arbeiten. In diesem Fall bekommen Sie die Produktivität für das gesamte Team. Ich würde nicht versuchen, dass auf die Einzelpersonen herunter zu brechen, es sei denn Sie haben einen sehr guten Grund dafür. Das ist nämlich ein nicht zu unterschätzender Aufwand.

    Jetzt haben Sie also eine relative Einstufung der jeweiligen Aufgaben aus der Aufwandsschätzung. Und Sie kennen die Produktivität Ihrer Entwickler – und zwar die reale, nicht die geschätzte.

    Mit diesen Daten würde ich als Projektleiter als Erstes regelmäßig den Fertigstellungstermin überprüfen. Wie viel Restaufwand ist noch vorhanden? Und reicht die Produktivität des Teams, um das in der vorgegebenen Zeit zu schaffen?

    Außerdem können Sie damit noch viele andere nützliche Dinge anstellen. Im nächsten Artikel werde ich darauf zurückkommen, da geht es dann um Fluktuation im Team.

    Risikofaktoren in der Aufwandsschätzung

    Keine Methode für die Aufwandsschätzung ist perfekt. Auch diese nicht. Kurz gesagt: Das Unbekannte können Sie einfach nicht zuverlässig schätzen.

    Gerade bei der Produktivität von Entwicklern gibt es viele Faktoren, die einen mehr oder weniger großen Einfluss haben. Und wahrscheinlich werden Sie einige davon nicht von vornherein kennen. Das sind beispielsweise:

    • Mangelndes Wissen über die fachlichen Grundlagen der Software.
    • Einsatz von neuen Tools und / oder Prozessen. Diese Maßnahmen haben häufig auch eine Produktivitätsverbesserung zum Ziel, erfordern aber eine gewissen Einarbeitungsphase. Gut möglich, dass Ihr Projekt darunter erst einmal leidet.
    • Die Motivation der Entwickler hat ebenfalls einen großen Einfluss.
    • Neue Mitarbeiter im Team führen fast immer zu “Unruhe”. Jeder muss sich seinen Platz neu suchen und sich auf die anderen Teammitglieder einstellen. Das wirkt sich auch auf die Produktivität aus.
    • Neue Technologien sind immer Hoffnungsträger für Produktivitätsverbesserungen. Und fast immer werden die Erwartungen (mehr oder weniger) enttäuscht. In jedem Fall müssen Sie mit Veränderungen rechnen.

    Diese Liste erhebt keinen Anspruch auf Vollständigkeit, sie soll Ihnen nur demonstrieren, welche Risiken in Bezug auf die Aufwandsschätzung bestehen. Einige davon werden Sie sicherlich ausschließen können, andere können Sie vermutlich ganz gut einschätzen.

    Je mehr Erfahrungswerte Sie also aus früheren Projekten besitzen, desto besser. Ausgehend von den Risiken und ihrer Relevanz sollten Sie dann auch die Zeitreserven für Ihre Terminplanung festlegen.

    Die 4 goldenen Regeln der Aufwandsschätzung

    Fassen wir noch einmal zusammen:

    • Lassen Sie die Entwickler relative Aufwandsschätzungen erstellen.
    • Benutzen Sie für die Ermittlung der absoluten Aufwände Erfahrungswerte – entweder aus früheren Projekten oder aus dem aktuellen.
    • Messen Sie regelmäßig die Produktivität. Sie erhalten damit notwendige Daten für die Prüfung des Terminplans sowie für zukünftige Projekte.
    • Wenn es geht, messen Sie die Produktivität für jeden Entwickler einzeln. Und wenn es geht vermeiden Sie dabei zusätzliche Tätigkeiten für die Entwickler.
    2 Comments

2 Responses to “Aufwandsschätzung: Messen Sie schon oder schätzen Sie noch?”

  1. Olaf Knauer said on

    Eine gute Möglichkeit eine bessere Absicherung der Aufwandsschätzung zu bekommen ist die Delphi-Methode. Man läßt 3-4 Spezialisten den Aufwand schätzen und ermittelt den Durchschnittswert. Das kommt immer ganz gut hin.

  2. [...] Aufwandsschätzung: Messen Sie schon oder schätzen Sie noch? [...]

Leave a Reply