1. Der klassische Ansatz

* Der Kunde erarbeitet ein Pflichtenheft/Wunschliste mit allen Anforderungen,

* der Programmierer versucht im Voraus den gesamten Aufwand zu schätzen,

* es gibt einen Werkvertrag: der Programmierer soll genau das erfüllen was im Pflichtenheft steht, und zwar zu einem festgelegten Termin und einem festgelegten Budget.

Probleme: Dieser Ansatz ist leider nur sehr selten sinnvoll. Über 60% aller so geführten IT-Projekte schlagen fehl (= über Budget, über Zeit oder Abbruch wegen zu großer Überschreitung des Budgets/der Zeit).

Die Ursachen:

* So sehr man sich auch Mühe gibt, so ein Pflichtenheft bekommt man in der Regel nicht perfekt und vollständig hin, denn es ergeben sich im Laufe des Projekts oft Änderungen.

* Die Aufwandsschätzung des Programmierers ist genauso schwierig und ungenau. Viele Probleme ergeben sich erst bei der Implementierung. Gerade wenn man bestehenden Code erweitern will, kann man kaum genaue Aussagen über die Dauer treffen.

Es gibt 4 Faktoren an denen man theoretisch drehen kann: Qualität, Zeit, Kosten und Scope (= welche Funktionen).  Beim klassichen Ansatz gibt man Zeit, Kosten und Scope fest vor. In der Folge leidet dann oft die Qualität, oder eine oder mehrere der anderen drei festen Größen werden gesprengt.

2. Der agile Ansatz

Wir wollen weder unseren Kunden noch uns 60% Fehlrate bei unseren Projekten antun. Von daher erkennen wir an, dass es nicht möglich ist, eine Software im Voraus komplett zu beschreiben. Wir wollen nicht an der Qualitätsschraube drehen, und wir gehen davon aus, daß unsere Kunden die Software zu einem Termin fertig haben und ein planbares Budget ausgeben wollen. Deshalb garantieren wir eine feste Qualität, fixes Budget und pünktliche Lieferung. Unsere Variable ist der Scope (also die Anzahl der Funktionen/Features). Natürlich wollt ihr als Kunde natürlich keine unfertige Software haben.

Deshalb:

* Planen wir mit euch jeweils die Features für eine Iteration und priorisieren diese konsequent durch. Dadurch haben wir die Funktionen, die euch am Wichtigsten sind, zuerst fertig. Weniger wichtige  Sachen fallen am Ende unter Umständen raus. Je nachdem wie wichtig sie euch sind, werden diese in eine nächste Iteration aufgenommen oder nicht. Genausogut könnt ihr euch entscheiden, keine nächste Iteration zu beauftragen, wenn euch die implementierten Funktionen reichen.

* Arbeiten wir in kurzen Iterationen, an deren Ende jeweils eine fertige Software steht. So wisst ihr immer, wie weit wir sind. Und ihr habt jederzeit eine stabile Software einsatzbereit, wobei die Anzahl der Funktionen stetig wächst.

* Durch die kurzen Iterationen könnt ihr jederzeit in den Prozess eingreifen, wenn ihr merkt, dass bestimmte Sachen doch lieber anders gelöst werden sollen. So habt ihr immer volle Kontrolle über das Produkt.

Belege:

"The results of the case studies indicate that the pre-release defect density of the four products decreased between 40% and 90% relative to similar projects that did not use the TDD practice. Subjectively, the teams experienced a 15–35% increase in initial development time after adopting TDD."

Quelle: http://research.microsoft.com/en-us/projects/esm/