In der Konzeptionsphase sind die größten Risiken häufig wirtschaftliche oder technische Risiken. Das von Anfang an
dominierende Risiko ist in der Regel die Sicherung der Projektfinanzierung. Deshalb ist das Ergebnis der
Konzeptionsphase häufig ein Prototyp für eine Machbarkeitsstudie. Dieser Prototyp demonstriert Schlüsselfunktionalität
oder grundlegende technologische Aspekte.
Die erste Iteration eines neuen Produkts ist in der Regel die schwierigste. Es gibt viele neue Aspekte, die eine erste
Iteration neben der Produktion von Software berücksichtigen muss, z. B. Umsetzung des Prozesses, Zusammenstellung der
Teams, Einarbeitung in eine neue Domäne, Einarbeitung in neue Tools usw. Ihre Erwartungen in Bezug darauf, wie viel der
Architektur Sie ausarbeiten oder wie viel verwendbare Funktionalität Sie erreichen können, sollten Sie nicht zu hoch
ansetzen. Wenn Sie sich zu hohe Ziele setzen, laufen Sie Gefahr, den Abschluss der ersten Iteration zu verzögern, die
Gesamtanzahl der Iterationen zu minimieren und somit den Nutzen eines iterativen Ansatzes zu schmälern. Die ersten
Iterationen sollten sich darauf konzentrieren, die Architektur sauber aufzubauen. Deshalb müssen Sie die
Softwarearchitekten in den Planungsprozess früher Iterationen einbeziehen.
In der Ausarbeitungsphase konzentrieren sich die Iterationen auf die Definition einer stabilen Architektur, auf das
Design und die Implementierung des grundlegenden Verhaltens des Systems und die Untersuchung technischer Aspekte der
Architektur mit Hilfe einer Reihe von Architekturprototypen. "Architektonisch relevante" Szenarios sind untergeordnete
Abläufe, die die Architektur des Systems auf vordefinierte Weise testen.
Gegen Ende der Ausarbeitungsphase und während der Konstruktions- und Übergangsphase beginnen Änderungsanfragen (auch
SCOs, Software Change Order, Softwareänderungsaufträge) den Iterationsprozess zu steuern. SCOs ergeben sich aus:
-
Verbesserungsvorschlägen,
-
Änderungsanfragen, deren Reichweite über das jeweilige Paket bzw. die jeweilige Klasse hinausgeht,
-
Änderungen im Iterationsumfang und in den Zielsetzungen,
-
Änderungen in den Anforderungen, die eine Änderung der Referenzanforderungen oder die Aufnahme einer genehmigten
Änderung in die Referenzanforderungen nahelegen.
Diese SCOs werden auf der Basis des vorhandenen Projektplans, den Iterationsplänen und der vorhandenen Liste der
Risiken abgewogen. SCOs können eine erneute Bewertung der Anforderungsprioritäten oder eine erneute Priorisierung der
Risiken mit sich bringen. SCOs müssen jedoch sorgfältig verwaltet werden, damit Sie die Gewalt über die
Projektsteuerung nicht verlieren.
In den Konstruktions- und Übergangsphasen liegt der Fokus auf der Ausarbeitung der Architektur und der Implementierung
aller verbleibenden Anforderungen.
Anders als beim Wasserfallmodell, wo sofort das gesamte System betrachtet wird, wird in jeder Iteration nur ein Teil
der Systemfunktionalität betrachtet. In jeder Iteration wird ein Teil des Gesamtsystems analysiert, entworfen und
implementiert. Um welchen Teil es sich handelt und wie eingehend auf diesen Teil eingegangen wird, sind kritische
Faktoren, um Risiken in den nachfolgenden Iterationen zu minimieren. Es gibt zwei grundlegende Strategien: Viel/Flach
(Wide/Shallow) und Wenig/Tief (Narrow/Deep)
Bei dieser Strategie wird die gesamte Problemdomäne analysiert, aber es werden nur die oberflächlichen Details
betrachtet. Alle Anwendungsfälle werden definiert, und die meisten werden detailliert ausgearbeitet, um ein klares
Verständnis des vorliegenden Problems zu erhalten. Die Architektur wird ebenfalls weitgehend definiert, und die
Schlüsselmechanismen und -services der Architekturkomponenten werden definiert. Die Schnittstellen von Subsystemen
werden definiert, aber ihre internen Details werden nur dann detailliert beschrieben, wenn maßgebliche Risiken oder
Unsicherheiten ausgeräumt werden müssen. Bis zur Konstruktion, wo die meisten Iterationen stattfinden, wird nur sehr
wenig implementiert.
Die Strategie "Viel und Flach" eignet sich, wenn
-
das Team unerfahren ist, entweder in der Problemdomäne oder in der Vorgehensweise (einschließlich Methodik und
Prozess),
-
eine solide Architektur die Schlüsselvoraussetzung für künftige Funktionalität ist und die Architektur neuartig
ist.
Die Strategie hat jedoch auch einige "Fallstricke":
-
Das Team kann in eine Analysestarre verfallen (die unlogische Haltung, dass erst dann etwas implementiert
werden kann, wenn das Design perfekt ist).
-
Frühe Ergebnisse sind häufig wichtig, um Vertrauen und Glaubwürdigkeit aufzubauen. Je länger es dauert, bis das
Projektteam etwas "Ausführbares" produziert, desto weniger Vertrauen haben sie in ihr eigenes Vermögen, es
schließlich doch noch zu schaffen.
-
Es werden nicht genügend technische Details und Anforderungen an die Architektur offen gelegt, um ein Gefühl für
die wirklichen technischen Risiken zu bekommen.
Bei dieser Strategie wird ein Teil der Problemdomäne gründlich analysiert. Die Anwendungsfälle, die sich auf
diesen begrenzten Teil beziehen, werden detailliert definiert und ausgearbeitet, um ein klares Verständnis des
vorliegenden Problems zu erhalten. Die erforderliche Architektur für die Unterstützung des gewünschten Verhaltens wird
definiert, und das System wird entworfen und implementiert. Nachfolgende Iterationen konzentrieren sich auf die
Analyse, das Design und die Implementierung zusätzlicher vertikaler Stücke.
Die Strategie "Wenig und Tief" eignet sich, wenn
-
frühe Ergebnisse erforderlich sind, um zu demonstrieren, dass ein dominierendes Risiko bewältigt werden kann, um
Unterstützung zu erhalten und die Machbarkeit nachzuweisen,
-
die Anforderungen ständig zunehmen und es schwierig ist, alle Anforderungen vor dem Beginn des detaillierten
Designs oder der Implementierung vollständig zu definieren,
-
der Endtermin verbindlich ist, so dass ein früher Entwicklungsstart der Schlüssel für eine erfolgreiche
Auslieferung ist,
-
eine Wiederverwendbarkeit in hohem Maße möglich ist und damit die inkrementelle Auslieferung begünstigt wird.
Die Strategie ist jedoch nicht ohne Nachteile:
-
Diese Strategie weist die Neigung auf, für jede Iteration Software zu entwickeln, die zwar vertikal integriert
wird, aber horizontal nicht kompatibel ist. Dieses so genannte Kaminsyndrom erschwert die Integration des
Systems.
-
Sie eignet sich nicht besonders gut für die Entwicklung von Systemen in einer völlig neuen Problemdomäne oder von
Systemen, die auf einer neuartigen Architektur basieren, da ein großer Teil der Funktionalität solcher Systeme
getestet werden muss, um eine stabile Architektur zu erhalten.
Frühe Iterationen haben im Allgemeinen einen Viel/Flach-Charakter, wohingegen spätere Iterationen (in denen bereits
eine stabile Architektur entwickelt wurde) eher der Wenig/Tief-Strategie folgen.
Die erste Iteration ist in der Regel die schwierigste, da sie die gesamte Entwicklungsumgebung und einen Großteil des
Projektteams in Anspruch nimmt. Toolintegration und Teamzusammenstellung tragen zur Komplexität der ersten Iteration
bei. Mit dem Fokus auf den architektonischen Aspekten kann die eingeschlagene Zielrichtung eingehalten und verhindert
werden, dass das Team sich zu früh in Details verliert.
-
Wenig/Tief-Strategie in der Konzeption
Diese Strategie wird verwendet, wenn der Einsatz einer neuen Technologie für die Durchführbarkeit des Projekts
grundlegend ist. In vielen e-business-Projekten müssen neue Technologien sehr viel mehr als in herkömmlichen
Projekten erprobt werden. Der Prototyp ist auch hier ein "Wegwerfprodukt" und dient lediglich als Studie zur
Durchführbarkeit des Projektkonzepts.
-
Viel/Flach-Strategie in der Konzeption
Mit dieser Strategie wird das Ziel verfolgt, den Umfang des Systems und die Breite der Systemfunktionalität zu
erfassen, um sicherzustellen, dass die Architektur das gewünschte Leistungsspektrum abdeckt.
-
Viel/Flach-Strategie in der Ausarbeitung
Dieser Ansatz kann zur Entwicklung einer stabilen Architektur beitragen, wenn der selektiv die
Wenig/Tief-Strategie auf spezifische technische Risiken angewendet wird. Wenn in der Konstruktion eine stabile
Architektur vorliegt, kann der Fokus wieder auf die Wenig/Tief-Strategie verlagert werden, wenn Funktionalität
in einer Serie integrierter Inkremente entwickelt und bereitgestellt wird.
-
Wenig/Tief-Strategie in der Konstruktion
Konstruktionsiterationen folgen immer der Wenig/Tief-Strategie. Teams arbeiten parallel, um die erforderliche
Funktionalität zu entwickeln und bereitzustellen.
Neue Teams sind in der Regel zu optimistisch in Bezug auf das, was sie zu leisten in der Lage sind. Um diesem
entgegenzuwirken und zu vermeiden, dass das Betriebsklima sich verschlechtert, wenn die tatsächlichen Ergebnisse hinter
den Erwartungen zurückbleiben, sollten Sie in Bezug auf die in der ersten Iteration erreichbare Funktionalität
zurückhaltend sein. Versuchen Sie, Wissen aufzubauen, den Mitarbeitern Erfolgserlebnisse zu verschaffen und Schwung in
das Projekt zu bringen.
Wenn die Entwicklungsumgebung und/oder die Methoden neu für das Team sind, sollten Sie den Funktionsumfang der ersten
Iteration auf ein Minimum beschränken. Konzentrieren Sie sich auf die Integration und Optimierung der Umgebung und den
sicheren Umgang mit den Tools und stocken Sie dann den Funktionsumfang in den nachfolgenden Iterationen auf.
Nacharbeiten sind bis zu einem gewissen Punkt durchaus in Ordnung. Einer der Hauptvorteile einer iterativen Entwicklung
ist genau der, dass Fehler gemacht werden können und experimentiert werden kann. Dies muss jedoch zu einem zu frühen
Zeitpunkt geschehen, dass Korrekturmaßnahmen vorgenommen werden können. Insbesondere IT-Leute neigen dazu, einen
"Goldrahmen" um ihre Arbeit ziehen oder zwischen Iterationen ihre Arbeit perfektionieren zu wollen.
Am Ende jeder Iteration, während der Iterationsauswertung, muss das Team entscheiden, welcher Teil des aktuellen
Release überarbeitet wird. In den einzelnen Phasen sollten die folgenden Prozentzahlen (relativ zum Gesamtsystem) für
Nacharbeiten veranschlagt werden:
-
In der Konzeption 40-100 % - Hier werden vorläufige, explorative Prototypen erstellt.
-
In den frühen Iterationen der Ausarbeitung 25-60 %, weniger als 25 % in späteren Iterationen oder für einen
Weiterentwicklungszyklus.
-
In der Konstruktion nach der Erstellung der Referenzarchitektur 10 % oder weniger pro Iteration und 25 % insgesamt.
-
Im Übergang weniger als 5 %.
Nacharbeiten sind unerlässlich. Wenn niemand einen Bedarf an Nacharbeiten sieht, sollten Sie misstrauisch werden. Es
können folgende Gründe vorliegen:
-
Der Zeitdruck ist zu groß.
-
Es wurde zu wenig testet oder ausgewertet.
-
Es fehlt an Motivation oder Fokus.
-
Nacharbeiten werden als negativ, als Verschwendung von Ressourcen oder Eingeständnis von Inkompetenz oder Versagen
betrachtet.
Zu viele Nacharbeiten sind alarmierend. Sie können darauf zurückzuführen sein, dass jemand einen 'Goldrahmen' um seine
Arbeit ziehen will oder dass die Anzahl der Änderungsanfragen unverhältnismäßig hoch ist. In diesem Fall sollte eine
Kosten-Nutzen-Analyse durchgeführt werden, um die Erforderlichkeit bestimmter Nacharbeiten zu bewerten.
Arbeiten, die in der vorherigen Iteration (wegen des vom Iterationsmanagement vorgegebenen Zeitrahmens) nicht fertig
gestellt wurden, fallen nicht in die Kategorie "Nacharbeiten". Der Projektleiter muss diese Arbeiten in den
Funktionalitätspool stellen, aus dem der Inhalt der nächsten Iteration definiert wird. Es ist offensichtlich, dass
solche Arbeiten normalerweise eine hohe Priorität haben. Der Projektleiter muss sorgfältig untersuchen, warum die
geplanten Ziele in der vorherigen Iteration nicht erreicht wurden. Obwohl es nicht empfohlen wird, zusätzliche
Mitarbeiter einzusetzen, nur um einen Zeitplan einhalten zu können, ist es ebenso unsinnig, ein Projekt mit chronischer
Unterbesetzung durchzuführen, aber trotzdem immer wieder ehrgeizige Pläne für jede Iteration zu schmieden. Dies
führt normalerweise zu einer schlechten Teammoral und zu Unverständnis beim Kunden. Es muss die richtige Balance
gefunden werden, und Schätzmodelle wie COCOMO II (siehe [BOE00]) können dabei
helfen. Jede Iteration ist auch eine Dokumentation des Erreichten, sowohl in Produktivität als auch in Qualität. Ein
wichtiger Indikator für einen Projektleiter ist bei der Planung der nächsten Iteration, was in der vorherigen erreicht
wurde.
Wenn der erste Iterationsplan vollständig ist, können die Teamleiter, möglicherweise in Zusammenarbeit mit dem
Projektleiter, diesen Iterationsplan zu einem Arbeitsplan auf Aufgabenebene verfeinern. Die mitgelieferten
Microsoft®-Project-Vorlagen (auf Aufgabenebene) zeigen, wie dieses funktioniert. Obwohl diese Arbeitspläne vom
Iterationsplan abgeleitet werden, sind sie keine gesondert erzeugten, unabhängigen Arbeitsergebnisse. Wenn der
Projektleiter die Kontrolle behalten soll, ist es wichtig, dass die Arbeitspläne im Iterationsplan des Projektleiters
aufgeführt sind.
|