Anforderungsmanagement - Best Practise

Anforderungen an ihr Projekt müssen zentral an einer gesammelt werden. Denn nur so erkennt sie sich gegenseitig widersprechende Anforderungen. Und die kommen oft genug vor.

Eigentlich ist aus der agilen Sicht allein schon das Wort "Anforderung" ein Anti-Pattern. Viel besser ist es ein Ziel und einen Mehrwert zu formulieren. Was möchten sie mit dieser Anforderung erreichen?  Nicht: "Ich will Nutzer in einer Datenbank speichern können." Sondern "Als Benutzer möchte ich einmal eingegebene Nutzerdaten wieder abrufen können, so dass ich sie nicht jedes Mal wieder neu eingeben muss." Das klingt bei so einem einfachen Beispiel banal, diese Formulierung "Als Nutzer möchte ich ... damit ... "  hilft aber sehr um sich auf ein Ziel zu konzentrieren und festzulegen.

Anforderungen müssen natürlich die S.M.A.R.T Kriterien erfüllen - mindestens meß- und testbar sein.

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").