Klassische Projekt Mathematik

Gegeben seien

• Feste Resourcen (Leute die im Projekt arbeiten)
• Eine Aufgabe, die auf Tasks heruntergebrochen wurde
• Ein Starttermin für das Projekt

Gesucht ist die Dauer des Projekts, und somit also der Termin, wann das Projekt fertig werden wird.

Unter der Annahme, dass die Arbeit für alle Tasks vollständig und korrekt im Voraus geschätzt werden können, (Diese Annahme ist natürlich für Agile Projekte, und für IT/Software Projekte im speziellen völlig falsch, wie wir alle wissen. Aber spielen wir mal weiter....)  folgt dann für jeden Task

Resource x Einheit x Arbeit = Dauer

zum Beispiel

Franz arbeitet 40 h / Woche.  70% davon ist er für unser Projekt verfügbar. Und der Task hat einen geschätzen Aufand von 140 Stunden.

40h / Woche x 70% x 56h   =  2 Wochen

=> Ein Task mit (nur!) 56h wird von einer Person in frühestens zwei Wochen fertig! Unter Beachtung der Abhängigkeiten zwischen Tasks ergibt sich entlang des kritschen Pfades dann die Gesamtdauer des Projekts.

Und nein, mit doppelt so vielen Leuten wirds nicht doppelt so schnell!

Die Geschichte vom Schätzen

Eine der grundlegen Thesen der agilen Entwicklung ist:

Menschen sind ziemlich schlecht im Schätzen, jedoch relativ gut im Vergleichen.

Dies lässt sich sehr schön mit einer kleine Geschichte illustrieren.

Stellen Sie sich einen kleinen bis mittelgroßer Berg Kies vor. Davor steht eine Schubkarre und eine Schaufel. Wie lange würden sie brauchen um den Berg Kies von dort zehn Meter weiter nach da drüben zu bewegen?

Natürlich fragen sie jetzt: Wie groß genau ist denn der Berg?  Aber selbst das (=der Gesamtaufwand eines Projekts) ist ja schon meistens nicht bekannt. Und selbst wenn, dann ist die Einheit unklar: Meter Höhe? Kubikmeter? Grundfläche?  Und selbst wenn wir das noch genau wüssten, dann wüssten sie immer noch nicht wie viele Kubikmeter pro Stunde sie schaffen würden. Sicherlich, wenn man komplett alle Parameter wüsste (incl. Wie viele Kubikmeter passen in den Schubkarren, wie lange dauert das rein schaufeln? Wie weit ist die Fahrstrecke? usw.) dann könnte man die Gesamtdauer leicht ausrechnen. Aber man weis diese Parameter in der Realen Welt vorher eben nicht.

Außer es ist jemand dabei, der schon viel Kies geschaufelt hat. Der weis aus Erfahrung wie lange es dauert eine Schubkarre dort rüber zu schippen. Und der kann auch mit ziemlicher Genauigkeit schätzen, wie lange es dauert zwei, drei vier oder fünf Schubkarren dort rüber zu schaffen.

Doch selbst jemand mit der Erfahrung wie lange es für eine Schubkarre dauert, kann kaum schätzen wie lange es für einen riesig großen Berg dauern würde. Wären es 100 oder 500 Schubkarren?

=> Man kann immer nur einigermaßen ähnliche Aufwände vergleichen und mit einer genügenden Genauigkeit schätzen.

Die konkrete Umsetzung dieses Gedankens ist das Schätzpoker ("Planning Poker").

Dauer und Aufwand

Ein einfaches, aber doch oft nicht verstandenes Prinzipt: Der Unterschied zwischen Brutto-Dauer und Netto-Aufwand.

Wie lange denken sie Arbeitet ein Mitarbeiter für ihr Projekt? Wahrscheinlich würden sie im ernsten Moment sagen: Ja natürlich 40 h pro Woche. So stehts im Vertrag. Aber arbeitet denn die Resource nur für ihr Projekt? Selbst wenn dem so ist, sind 100% noch lang keine 40 Stunden. Ein Mitarbeiter hat Urlaub, Pausen, Ablenkungen und viele viele administrativen Tätigkeiten. Die Erfahrung lehrt, dass man mit einem Faktor von 0,7 gut beraten ist. Selbst eine exklusive Resource arbeitet also nur zu ca. 70% ihrer Zeit an ihrem Projekt.

Wie lange braucht jemand also für 1BT (einen Bearbeitertag) Aufwand?  "Na da ist er ja morgen fertig!"  - wohl kaum. Wenn man die Reibungsverluste für das Kontextswitching abzieht, sind das mindestesn 2 Tage in brutto real Zeitdauer.

Überlasten sie ihre Resourcen nie mehr als 70%, denn darunter leidet die Qualität. Das müssen sie später im Bugfixing nur doppelte und dreifach wieder nachholen.