Autor: Andreas Stucki, Solcept AG<\/p>\n
Aufwandssch\u00e4tzung ist immer dann einfach, wenn man etwas schon mal getan hat. Was aber wenn alles neu ist? Was, wenn die Information \u00fcber das Projekt nur d\u00fcrftig ist? Der Beitrag zeigt verschiedene Sch\u00e4tzmethoden auf, bekannte und weniger bekannte, zusammen mit weichen Faktoren, die man beachten sollte. Dann wird gezeigt, wie man die Methoden f\u00fcr zwei F\u00e4lle kombinieren kann; zuerst f\u00fcr neue, aber einigerma\u00dfen klar definierte Projekte, dann auch f\u00fcr Projekte, die eher noch Ideen sind.<\/strong><\/p>\n Diese Frage h\u00e4ngt sehr stark davon ab, wen Sie in Ihrer Organisation fragen. F\u00fcr uns als Ingenieurb\u00fcro ist es \u00fcberlebenswichtig genau zu sch\u00e4tzen, da bereits Fehlsch\u00e4tzungen von ein paar 10 Prozent existenzbedrohend werden k\u00f6nnen.<\/p>\n Der folgende Beitrag zeigt auf, wie man f\u00fcr zwei F\u00e4lle einen Entwicklungsaufwand sch\u00e4tzen kann. Der erste Fall ist eine Entwicklung, bei der die Spezifikation und vor allem die Schritte zum Produkt einigerma\u00dfen bekannt sind. Im anderen Fall kommt der Produktmanager mit einer Produktidee auf einer A4-Seite und will wissen, was die Entwicklung nun kostet \u2212 „bis Ende Woche bitte“.<\/p>\n Vor allem, wenn wenig vorhanden ist, sollte man auf alle vorhandene Information zugreifen k\u00f6nnen. Daher lohnt es sich, z.B. mit dem Autor der Spezifikation ein Gespr\u00e4ch zu f\u00fchren, damit klarer wird, was zwischen den Zeilen steht. Diese Information kann man nun in eine WBS (Work Breakdown Structure, auch PSP: Projektstrukturplan) gem\u00e4\u00df Bild 2 (s.\u00a0PDF<\/a>) \u00fcberf\u00fchren, d.h. eine hierarchische Aufteilung des Projektes in immer feinere Arbeitspakete, am besten als Tabelle. Es macht Sinn, diese Pakete hierarchisch zu gliedern, am besten entlang eines Projektlebenszyklus. D.h. entlang der Schritte, „wie wir hier solche Dinge entwickeln“.<\/p>\n Was machen wir aber bei der Idee auf einer A4-Seite? Eine WBS w\u00fcrde erfordern, dass wir eine Architektur des Produkts erstellen. Hier kann man eine FBS (Functional Breakdown Structure) gem\u00e4\u00df Bild 3 (s.\u00a0PDF<\/a>) erzeugen, welche alle Funktionen beinhaltet, am besten hierarchisch geordnet. Vor allem sollte man die Funktionen f\u00fcr verschiedene Entwicklergruppen, z.B. Soft- und Hardware trennen. So kann jede Gruppe ihren eigenen Teil sch\u00e4tzen.<\/p>\n Diese Liste sollte man dann mit allen Beteiligten nochmals durchgehen. So kann man Dinge einfangen, von denen „doch klar ist, dass sie dazugeh\u00f6ren“. Und \u00fcbrigens: wenn man die WBS immer \u00e4hnlich macht, entsteht mit der Zeit eine Vorlage, die daf\u00fcr sorgt, dass keine Schritte vergessen werden.<\/p>\n Am Ende l\u00e4uft es immer auf das Geld hinaus, der Stundensatz ist gegeben, man wird also nicht darum herumkommen, den Aufwand in Stunden zu sch\u00e4tzen. Vor allem bei einer FBS, wo vieles noch unklar ist, kann man sich das Leben mit Kategorien vereinfachen, d.h. man sortiert die Funktionen grob nach Komplexit\u00e4t in z.B. S, M, L, XL und sch\u00e4tzt dann nur den Aufwand f\u00fcr jede Kategorie.<\/p>\n Die einfachste Methode ist der heroische Ansatz: man gibt die Liste dem Guru, der „soll nun mal sagen, was der Aufwand ist“.<\/p>\n Weil das h\u00e4ufig nicht funktioniert, hat die Rand Corporation Wideband Delphi [RC] erfunden, wiedererweckt als Planning Poker [JG]. Dabei gibt jeder Experte zu jedem Arbeitspaket seine Sch\u00e4tzung ab, aber er erf\u00e4hrt erst von der Sch\u00e4tzung aller anderen, nachdem er selbst gesch\u00e4tzt hat (Details zum Vorgehen: [PP]). Der Konsens aus der iterativen Anwendung dieses Prozesses ist meist sehr gut, da niemand dem Leithammel einfach folgen kann.<\/p>\n Parameter-basierte Sch\u00e4tzung erlaubt einfache, aber genaue Sch\u00e4tzung. Man weiss z.B. wie viel Zeit man pro w\u00f6chentlicher Projektsitzung verbraucht, diese multipliziert mit der Anzahl der Anwesenden und der Anzahl Wochen gibt eine gute Aufwandssch\u00e4tzung.<\/p>\n Auch historische Daten liefern gute Anhaltspunkte. Wir wissen zum Beispiel, dass ein Projekt ziemlich genau 10-mal mehr Aufwand macht als die sauber abgeschlossene Systemdesign Phase. Wenn also diese Phase 400 h braucht, braucht das Gesamtprojekt wohl ca. 4000 h. Man beachte hier, dass der Zusammenhang nicht-linear sein kann, z.B. f\u00fcr ein gro\u00dfes Projekt der Aufwand nur mit 8 multipliziert werden muss.<\/p>\n Und man muss die historischen Daten zuerst mal haben. Das hei\u00dft, dass ein Projekt-Controlling stattfinden muss, welches diese Parameter erfasst.<\/p>\n Jede Sch\u00e4tzung ist mit Unsch\u00e4rfe behaftet, und es ist hilfreich, diese zu kennen.<\/p>\n In [RS] S. 112 findet man dazu eine 3-Punkt Sch\u00e4tzung. Es werden zuerst der wahrscheinlichste Aufwand N, der kleinstm\u00f6gliche K und der gr\u00f6\u00dftm\u00f6gliche G gesch\u00e4tzt. Der resultierende zu erwartende Sch\u00e4tzwert S (basierend auf der Beta-Verteilung) ist dann: S:=\u00a0(K\u00a0+\u00a04N\u00a0+\u00a0G)\/\u00a06. An derselben Stelle findet man auch eine getunte Formel, welche ein Gewicht von N zu G verschiebt, um die „Neigung der Sch\u00e4tzer zum Optimismus“ auszugleichen:\u00a0 S:=\u00a0(K\u00a0+\u00a03N\u00a0+\u00a02G)\/\u00a06.<\/p>\n In [WR] S. 146 wird daraus eine einfachere Formel, indem die kleinstm\u00f6gliche Sch\u00e4tzung gerade ganz weggelassen wird, d.h. es wird eine 2-Punkt Sch\u00e4tzung gemacht:\u00a0 S:=\u00a0(0K\u00a0+\u00a04N\u00a0+\u00a02G)\/\u00a06 =\u00a0(2N\u00a0+\u00a0G)\/\u00a03. Damit ist der Aufwand f\u00fcr eine Sch\u00e4tzung gespart und der Ausgleich f\u00fcr den Optimismus gerade eingebaut. Die Formel hat auch eine einfache Begr\u00fcndung in der Normalverteilung: Wenn man annimmt, dass G bei 3\u00a0Standardabweichungen liegt, dann liegt S bei 1\u00a0Standardabweichung. D.h. in 84% der F\u00e4lle liegt der Aufwand unter S.<\/p>\n F\u00fcr eine statistisch sauberere 2-Punkt-Sch\u00e4tzung kann die Log-Normal Verteilung herangezogen werden. Diese hat den Vorteil, dass sie von 0 (Aufw\u00e4nde unter 0 sind unrealistisch) bis unendlich definiert ist und sich auch aus den zwei Parametern N und G bestimmen l\u00e4sst. Ihr Nachteil ist, dass es einige Numerik braucht, um die Verteilung z.B. zu summieren.<\/p>\n „If a project has no risks, don’t do it“ [dML].<\/p>\n Welche Risiken sind nun in der Sch\u00e4tzung enthalten? Welche nicht? Dies wird vom Sch\u00e4tzteam in der Diskussion (z.B. w\u00e4hrend des Planning Poker) entschieden. Und zwar in der Form von Annahmen und verbleibenden Risiken au\u00dferhalb der Sch\u00e4tzunsch\u00e4rfe. Es empfiehlt sich daher, zu jedem Punkt der WBS\/ FBS beide in der Diskussion zu dokumentieren, damit sie nicht verloren gehen.<\/p>\n Beide kann man dann f\u00fcr die Risikofeststellung des Projektes verwenden, denn Risiken sind ja Annahmen, die nicht eintreffen. Wenn man diese Risiken mit Schaden und Eintretenswahrscheinlichkeit beziffert erh\u00e4lt man die Risikosumme, welche ein wichtiger Bestandteil der Absch\u00e4tzung ist.<\/p>\n Keine zu gro\u00dfen Aufgaben sch\u00e4tzen: typisch sollten die auf einmal gesch\u00e4tzten Aufgaben nicht gr\u00f6\u00dfer als 40, maximal 80 Stunden sein.<\/p>\n Die Sch\u00e4tzung budgetieren: \u00fcberlegen, wieviel Zeit man f\u00fcr die gesamte Sch\u00e4tzung aufwenden will. Dann kann man die Zeit f\u00fcr jede Sch\u00e4tzung z.B. mit einem Timer begrenzen.<\/p>\n Aufwand (Stunden) ist nicht gleich Dauer (Stunden): je nach Organisation und Erfahrung arbeiten Entwickler maximal 70..80% f\u00fcr das Projekt, dies also einplanen.<\/p>\n Und \u00fcbrigens: Man kann die Methoden grunds\u00e4tzlich auch verwenden, um andere Gr\u00f6ssen zu sch\u00e4tzen, zum Beispiel Kosten oder Speicherbedarf.<\/p>\n Falls wir eine gen\u00fcgend detaillierte Spezifikation haben, gehen wir folgenderma\u00dfen vor: Zuerst erstellt der Projektleiter basierend auf einer Vorlage eine WBS-Tabelle mit einer Beschreibung der einzelnen Arbeitspakete.<\/p>\n Dann f\u00fchrt das Team unter der Leitung des Projektleiters Planning Poker durch. Das Team sch\u00e4tzt zuerst den wahrscheinlichsten, normalen Fall und dann den Spread, d.h. die Differenz zum gr\u00f6\u00dftm\u00f6glichen Aufwand („Worst Case“). Die Diskussion (Beschreibung, Annahmen und verbleibende Risiken) werden vom Projektleiter w\u00e4hrend der Diskussion dokumentiert.<\/p>\n Der gesch\u00e4tzte Aufwand berechnet sich f\u00fcr jede Aufgabe der WBS gem\u00e4\u00df S\u00a0:=\u00a0(2N\u00a0+\u00a0G)\/\u00a03. Zur Gesamtsumme werden f\u00fcr eine realistische Sch\u00e4tzung die gewichteten Risiken dazu gez\u00e4hlt. Unter [Sc1] finden Sie eine Vorlage f\u00fcr ein Spreadsheet f\u00fcr diese Sch\u00e4tzung. Wir haben uns ein Tool geschrieben (von dem die Bilder stammen), welches es erlaubt, auch parametrische Sch\u00e4tzungen aufgrund historischer Daten einfach einzubeziehen.<\/p>\n Und die Sch\u00e4tzung einer Projektidee? Dazu erstellt der Projektleiter eine FBS-Tabelle und beschreibt die Funktionen und sortiert sie nach Komplexit\u00e4t in S..XL ein. Siehe Bild 3 im\u00a0PDF<\/a>.<\/p>\n Das Team w\u00e4hlt zuf\u00e4llig drei Funktionen von jeder Komplexit\u00e4t (S..XL). Es sch\u00e4tzt f\u00fcr diese nun N und G mit Planning Poker wie oben. Dann sch\u00e4tzt das Team basierend auf historischen Daten die Parameter wie z.B. den Anteil von Test und Debugging an der Entwicklung. Daraus l\u00e4sst sich numerisch oder mit Monte-Carlo Simulation die Verteilung f\u00fcr das gesamte Projekt berechnen. Unser Tool kann auch das, unter [Sc2] finden Sie unser Tool f\u00fcr die Absch\u00e4tzung von Steuerungsprojekten. Auch zu diesem Resultat macht es Sinn, die Summe der Risikoabsch\u00e4tzung dazu zu z\u00e4hlen.<\/p>\n F\u00fcr den Sch\u00e4tzer hat die Methode den Vorteil, dass er einen Bereich aus der Verteilung angeben kann, z.B. das 90% Konfidenzintervall. Damit gibt er seinem „Kunden“ in die Hand, wie viel Risiko er nehmen will. Sobald das Projekt klarer wird, kann man statt der FBS eine WBS erstellen und zumindest die n\u00e4chste Phase genauer absch\u00e4tzen.<\/p>\n [RC]: Wikipedia: „Delphi Method“, 2017, https:\/\/en.wikipedia.org\/wiki\/Delphi_method (download: 2017-09)<\/p>\n [JG]: J. W. Grenning: „Planning Poker“, 2002, https:\/\/wingman-sw.com\/papers\/PlanningPoker-v1.1.pdf (download: 2017-09)<\/p>\n [PP]: Solcept: „Planning Poker Anleitung“, 2017, https:\/\/www.solcept.ch\/de\/pp (download: 2017-09)<\/p>\n [RS]: R. D. Stutzke: „Estimating Software Intensive Systems“, 2005<\/p>\n [WR]: W. Reiter: „Die nackte Wahrheit \u00fcber Projektmanagement“, 2003<\/p>\n [dML]: T. DeMarco, T. Lister: „Waltzing with Bears“, 2003<\/p>\n [Sc1]: Solcept: „ESE Kongress Referenzen“, 2107, https:\/\/www.solcept.ch\/de\/blog\/ese-kongress-2017\/ (download: 2107-12)<\/p>\n [Sc2]: Solcept: „OnlineEstimation“, 2017, https:\/\/www.solcept.ch\/de\/aufwandsschaetzung\/ (download: 2107-12)<\/p>\n Andreas Stucki, Dipl. El.-Ing. ETHZ, Gesch\u00e4ftsleiter von Solcept AG hat eine 20j\u00e4hrige Erfahrung in der Projektleitung von embedded Soft- und Hardware-Projekten im industriellen und kommerziellen Umfeld.<\/p>\n Internet: www.solcept.ch Beitrag als PDF downloaden<\/strong><\/a><\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema Software Engineering Management \/Prozess-, Projekt- und Produktmanagement.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema\u00a0Software Engineering Management \/Prozess-, Projekt- und Produktmanagement steht\u00a0hier<\/strong>\u00a0<\/a>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\nIst Sch\u00e4tzung so wichtig?<\/h2>\n
Was soll gesch\u00e4tzt werden?<\/h2>\n
Vorbereitung<\/h2>\n
Was sch\u00e4tzen?<\/h2>\n
Wie sch\u00e4tzen?<\/h2>\n
Wie geht man mit Unsch\u00e4rfe um?<\/h2>\n
Was ist mit den Risiken?<\/h2>\n
Was muss man sonst noch beachten?<\/h2>\n
Wie sch\u00e4tzt man auf Basis einer Spezifikation?<\/h2>\n
Und bei einer Projektidee?<\/h2>\n
Referenzen<\/h2>\n
Autor<\/h2>\n
Kontakt<\/h3>\n
\nE-Mail:\u00a0\u00a0 a.stucki@solcept.ch<\/p>\n
\nSoftware Engineering Management – unsere Trainings & Coachings<\/h2>\n
\nSoftware Engineering Management – Fachwissen<\/h2>\n