Richtlinie: Iterationsplan
Iterationen sind der Herzschlag moderner Softwareentwicklung. Diese Richtlinien beschreibt Strategien für die Planung von Iterationen.
Beziehungen
Zugehörige Elemente
Hauptbeschreibung

Iterationsmuster

Konzeptionsiterationen

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.

Ausarbeitungsiterationen

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.

Konstruktions- und Übergangsiterationen

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.

Iterationsstrategien

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)

Viel und Flach

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.

Wenig und Tief

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.

Erfahrungswerte

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.

Hybridstrategien

  • 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.  

Spezielle Hinweise für neue Teams

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.

Erwartete Nacharbeiten

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.

Planungsebene

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.