23. Juli 2007 sri Allgemein 4

Faustformeln Aufwandsabschätzung

Aufwandsabschätzungen in IT Projekten sind immer ein Problem. Um eine solide Abschätzung zu machen, benötigt man viele Informationen und viel Zeit.
Es gibt zu dem Thema verschiedene mehr oder weniger komplexe Methoden. Ein Beispiel ist das Function Point Verfahren. In der Praxis sieht es aber – leider – oftmals so aus: Fachbereich oder Geschäftsführung haben eine Idee und würden sich freuen, wenn das Thema in einer vorgegebenen Zeit umgesetzt ist. Eine Antwort – ob das alles so klappt – muss bis maximal binne 2 Stunden erfolgen und natürlich gibt es mal wieder viel zu wenig Informationen.

Trotzdem schaffen es gute Projektleiter, auch in solchen Situationen eine einigermaßen gute Abschätzung auf den Tisch zu bringen. Wie sie das machen? Tja, ich habe lange mit mir gerungen, ob ich die bittere Wahrheit wirklich ausplaudern soll. Ich befürchte, ich werde jetzt aus der Gilde der Projektleiter wegen Geheimnisverrat ausgeschlossen. Nun gut, die Wahrheit ist manchmal hart, aber einer muss es ja sagen:

Wahrheit 1:
80% aller Projektleiter machen ihre Aufwandsabschätzungen aus dem Bauch heraus.

Ok, das klingt nicht gut. Ich formuliere es vielleicht anders:

Wahrheit 1B:
80% aller Projektleiter machen ihre Aufwandsabschätzungen aus der Erfahrung heraus.

Dabei gibt es Projektleiter, die das wirklich drauf haben. Leider gibt es da noch die …

… Wahrheit 2:
80% dieser Projektleiter haben nicht genug Erfahrung, um Aufwandsabschätzungen zu machen.

Oftmals sind die Anforderungen auch so schwammig, dass eine saubere Abschätzung einfach unmöglich ist. Um trotzdem auf eine einigermaßen saubere Abschätzung zu kommen, habe ich mir im Laufe der Zeit ein paar Regeln definiert mit denen man erstaunlich korrekten Vorhersagen machen kann. Und hier sind sie nun:

Die Guerilla-Projektleiter Faustformeln zur Aufwandsabschätzung

1. Die Verhältnisregel
In einem sauberen Projekt brauchen Analyse-Design, Entwicklung und Test jeweils 1/3 der Zeit.Bei Analyse und Design benötigt das Lastenheft (die Anforderungssammlung) 1/3 der Zeit.
Hat also ein Fachbereich eine Woche für ein Lastenheft benötigt, dauert das komplette Projekt mindestens 9 Wochen (eine Wochen Lastenheft 2 Wochen Pflichtenheft und Design, 3 Wochen Entwicklung, 3 Wochen Test).

2. Die Webseitenregel
Jede Web-Seite benötigt einen Tag Entwicklung.
Es gibt Seiten, die sind in 10 Minuten fertig (z.B. Impressum – es sei denn, die Rechtsabteilung zickt ‚rum). Bestellseiten für eine E-Commerce Seite benötigen vielleicht ein paar Tage. In der Summe kommt es aber gut hin: Einen Tag pro Seite. Bei Frontends, die nicht im Web sind, ist es schwieriger. Die Regel funktioniert daher so gut, da es im Web einen engen Zusammenhang zwischen Seiten und Prozessschritten gibt. bei anderen Oberflächen (wie auch bei Ajax-Oberflächen) muss man die Bildschirmseiten daher etwas anders betrachten.

3. Die Schnittstellenregel
Jede Schnittstelle zu einem externen System benötigt 5 Arbeitstage.
Diese Regel ist in letzter Zeit ein wenig aufgeweicht. Es gibt Web-Services, die habe ich in 3 Minuten angebunden. Aber die Erfahrung zeigt einfach, dass Schnittstellen immer länger brauchen als man vorher dachte. Dabei ist Technik und Syntax der Schnittstelle selten ein Problem. Oftmals finden sich beim Test viele Probleme mit der Semantik (also der Bedeutung der übertragenen Daten). Schnittstellen kann man gar nicht oft genug testen.

4. Die QS und Konfigurationsregeln
Für die Themen Qualitätssicherung, Paketverwaltung, Konfigurationsmanagement sollte man 20% auf das Projekt aufschlagen. Im oberen Beispiel (9 Wochen) sind wir also bei 11 Wochen.

5. Die Dokumentationsregel
Für Dokumentation sollte man 20% auf das Projekt aufschlagen.

6. Die 1. Teamregeln
Softwareentwickler sind bzgl. ihrer Produktivität extrem unterschiedlich. Bei gleicher Qualität unterscheidet sich deren Geschwindigkeit bis zum Faktor 10. Daher sollte man bei jeder Abschätzung einen Buffer einplanen dessen Höhe individuell die Leistung des Teams wiederspiegelt: Mind. 20%, besser 50%, manchmal 100% der bisherigen Abschätzung.

6. Die 2. Teamregel
Wenn man statt 3, 6 Personen mit einer Aufgabe betraut, ist man nicht automatisch doppelt so schnell. Die Leute müssen koordiniert werden, sie werden krank usw. usw. Für jedes Teammitglied müssen 15% der theoretisch möglichen Produktivität für Koodination abgezogen werden. Das bedeutet: Ab ca. 7 (bis 10) Mitgliedern benötigt ein Team einen Teamleiter der sich nur um Koordination kümmert – das Projekt wird also in Teilprojekte zerteilt. 7-10 Teamleiter werden dann wieder zu einer Einheit zusammengefasst. Wichtig: Ich spreche hier von einer Ordnungsstruktur, nicht von einer Hierachie.

7. Die 6-Monate Regel
Komplexität zerstört jede Abschätzung. Komplexität ist nichts für uns Menschen. Die Erfahrung (und viele Unterschungen zeigen), dass Projekt mit einer Laufzeit von über 6 Monaten sehr, sehr selten den vorgegebenen Zeitrahmen einhalten. Wenn es Projekt also in seiner Planung eine Laufzeit von über 6 Monaten hat, muss man das Messer ansetzen. Das Projekt wird in mehrere möglichst unabhängige Teilprojekte zerteilt und neu geplant. Achtung Falle: Es ist absolut wichtig, Teilprojekte wirklich von Grund auf neu zu planen. Aus einem Projekt über 8 Monate macht man nicht einfach 2 Projekt über 4 Monate. Das ist grober Unfug.

Das klingt einfach, aber wie Zuverlässig ist diese Schätzung? Mit etwas Übung bekommt man so eine Genauigkeit von ca. 30% hin. das ist nicht besonders exakt, aber es ist viel besser als viele andere Abschätzungen.

Projektmanagement

‹ Entwarnung IQ Test ›