"Kein Mensch ist so beschäftigt, dass er nicht die Zeit hat, überall zu erzählen, wie beschäftigt er ist."
(Robert Lembke)

Iterationen

Die Versionskennungen bei Software werden typischerweise als v.rr dargestellt, wobei v die Nummer der Version und rr die Nummer der Revision ist. Wenn also Fehler behoben wurden und vielleicht einige Funktionen aufgrund der Rückmeldungen der Kunden noch mal angepasst wurden, wird eine neue Revision des Produktes auf den Markt gebracht. Einige große Hersteller haben noch kleinere Schritte eingeführt, weil der Aufwand für die Produktion einer neuen Version/Revision bei Millionenstückzahlen in verschiedenen Sprachen für mehrere Kontinente extrem aufwendig ist. So gab es von Microsoft ein Word 6.0a, in dem nur geringe Änderungen vorgenommen wurden, die in die laufende Produktion eingeflossen sind, aber nicht zum Ankurbeln der gesamten Marketingmaschinerie geeignet waren.

Oft wird auch die Build-Nummer (Herstellungsnummer) noch mit angegeben. Diese Nummer wird immer hochgezählt, wenn die Software wieder neu generiert wird. Wenn also Entwickler eine Änderung vorgenommen haben und alle ihre Quellen übersetzt haben, brauchen sie einen neuen fertigen Stand der Software, um ihre Änderungen erst selbst testen zu können und dann in die Qualitätskontrolle geben zu können. Zur Kommunikation ist eine eindeutige Identifizierung des Stands erforderlich, und genau hierfür wird bei jeder Erstellung eines neuen Standes die Build-Nummer hochgezählt. So wird beispielsweise bei Microsoft von einem Build-Team jede Nacht ein neuer Stand von Windows generiert, der dann von einem Burning-Team (Brenn-Team) noch in der gleichen Nacht auf CDs gezogen wird. [B21]

Wenn Sie also in Ihrem Projekt auf dem Weg zu einer neuen Revision oder gar Version mehrere Iterationen durchlaufen, sollten Sie vielleicht auch die Programmstände der einzelnen Iterationen mit Builds benennen. Wenn also der Meilenstein "Close Shop" zum Erstellen eines Builds am Ende einer Iteration erreicht ist, sollten alle Entwickler ihre Quellen mit der Angabe dieser Build-Nummer in das Quellverwaltungssystem einchecken und dann daraus das Build erstellen. So können Sie später problemlos die Quellversionen zu jedem Build und damit zu jeder Iterationsstufe abrufen, um bei gemeldeten Fehlern die Ursache zu suchen. Wenn Sie eine Individualsoftware entwickeln und vereinbart haben, dass jeder Iterationsschritt zum Kunden in den Test geht, ist es eine gute Idee, das auszuliefernde Paket gemeinsam mit den Quellen auf zwei CDs zu brennen, wovon eine zum Kunden geht und eine beim Projektleiter des Auftragnehmers verbleibt.

Auch wenn es nahe liegt, vermeiden Sie als Lieferant Zwischenabnahmen, wenn Sie den Aufwand nicht vergütet bekommen. Der Aufwand ist nämlich nicht unerheblich, weil die Anforderungen für die einzelnen Iterationen genau abgegrenzt sein müssen und sehr gründlich getestet werden muss, damit Sie die Abnahme überhaupt durchführen können. Womöglich kommt der Kunde auf die Idee, mit dieser Zwischenabnahme schon mal in Echtbetrieb zu gehen und Sie können keine inkompatiblen Änderungen mehr vornehmen. Wenn Zwischenabnahmen durchgeführt werden sollen, muss dies am Projektanfang im Vertrag genau geregelt sein.

Jetzt wird es aber Zeit, noch mal genau zu klären, was eigentlich eine Iteration ist, oder? Sie haben sicherlich während der Analyse der Anforderungen Anwendungsfälle erstellt und diese in Pakete zusammengefasst oder hierarchisch in vielleicht drei Level angeordnet. Vielleicht haben Sie ja sogar schon in der Pre-Analyse aus den Teilzielen die ersten Übersichtsanwendungsfälle ermittelt. Iterativ inkrementell zu arbeiten bedeutet ja, einen Satz von Prozessen mehrmals zu durchlaufen, um den Funktionalitätsumfang stufig wachsen zu lassen. Dies bedeutet aber eben nicht, dass Sie ein Paket nach dem anderen oder einen Übersichtsanwendungsfall nach dem anderen einbauen sollten. Dies ist nur dann vertretbar, wenn Sie wirklich einen Kernel, eine Stammdatenverwaltung und wenige völlig getrennte Bereiche ohne nennenswerte gemeinsame Logik haben. Dies ist aber nur sehr selten oder nur bei großen Projekten in der ersten Version der Fall. In aller Regel sollten Sie aus jedem Paket bzw. aus jedem Übersichtsanwendungsfall in jeder Iterationsstufe einige Funktionsanwendungsfälle mit mehreren Detailanwendungsfällen haben, um das Produkt gleichmäßig entstehen zu lassen. Die erste Iteration enthält also von allem nur die ersten Ansätze, die zweite Iteration enthält von allem bereits die Basisfunktionalitäten, mit der dritten kann man schon die wichtigsten Anwendungen testen und mit der letzten werden die Funktionalitäten aus allen Bereichen gleichzeitig komplett. Nur so erhalten Sie in der ersten Iterationsstufe ein grobes Gesamtdesign, das iterativ inkrementell verfeinert wird. Ansonsten würden Sie in der ersten Iterationsstufe nur ein Teilmodell designen und in der nächsten Iterationsstufe eine weiteres Teilmodell, etc. Dann bekommen Sie aber Schwierigkeiten bei der Erkennung von Wiederverwendungen, zentralen Logiken und Basisklassen.

Iterationen erstrecken sich aber eben nicht nur auf die Implementierung, denn dann würde das ganze Projekt ja wohl mehr einem Wasserfall gleichen. Vielmehr enthält eine Iteration ja alle Prozesse bzw. Disziplinen. Das heißt nun aber auch nicht, dass Sie einfach mehrmals durch den ganzen Wasserfall laufen! Stattdessen werden Sie in der Praxis feststellen, dass sich bei iterativer Arbeitsweise die Phasen des Projekts sehr stark überlappen und daher (gerade bei frühen Iterationen) noch viel über Anforderungen gesprochen wird, Änderungsanforderungen analysiert werden und oft auch noch ein Review des Designs gefahren wird. Getestet wird natürlich in allen Iterationen, von der ersten bis zur letzten!

Wie viele Iterationen sollte man also planen? Nun, das hängt natürlich von der Größe des Projekts genauso wie von dessen Komplexität ab (was nichts miteinander zu tun haben muss). Ferner spielt die Größe und Erfahrung des Teams eine Rolle. Nicht zuletzt hängt es von der Zusammenarbeit mit dem Kunden ab. Bei einem Aufwandsprojekt, dessen Fachlichkeit sich mit dem Projekt entwickelt, werden Sie natürlich viel mehr Iterationen fahren als bei der Ablösung eines Altsystems, dessen Ablösung nur stattfindet, weil die Technik veraltet ist, aber dessen Funktionalität unverändert übernommen werden soll. Da Sie aber sicherlich dennoch gerne eine Zahl hätten, nenne ich 5 Iterationen pro Jahr bei einer Individualsoftware als gute Obergrenze. Ein Softwareprojekt läuft selten so komfortabel ab, dass der Lieferant freiwillig noch ein paar Iterationen dazwischen schiebt und wie am Fließband produziert. Typischerweise wird man eher ein Build auslassen, um ein paar Tage wieder rauszuholen. Ob dies allerdings immer eine gute Lösung ist, sei dahingestellt.

Wie bereits eben angedeutet, wird natürlich jedes Build von Anfang an im Projektplan geplant, und zwar mit Tests, Übergang an den Kunden, etc. Damit können Sie als Projektleiter auch gutes Monitoring betreiben, also das Timing des Teams messen: wenn die erste Iterationsstufe 8% über Plan war und die zweite 12%, wie können Sie dann annehmen, dass die restlichen Iterationsstufen diese Zeit schon wieder rausholen werden? Sie sollten stattdessen mit dem Team die Ursachen diskutieren, nach Lösungen suchen und dies in der nächsten Projektlenkungskreissitzung anbringen, denn genau dafür sind diese Dinger da! Je enger der Plan wird und je weniger Zeit Sie haben, desto mehr sollten Sie die Ursachen suchen und darüber berichten, denn diese Zeit haben Sie immer (siehe Spruch oben auf der Seite).