Konzept: Wert iterativ demonstrieren
Dieses Prinzip demonstriert den Wert der iterativen Entwicklung.
Hauptbeschreibung

Einführung

Dieses Prinzip erläutert, warum der iterative Ansatz für die Softwareentwicklung so wertvoll ist. In einem iterativen Prozess können Änderungen und Feedback problemlos im Projekt untergebracht, Risiken früh minimiert und Prozessanpassungen dynamisch vorgenommen werden.

        
Vorteile
  • Verminderung von Risiken in einem frühen Stadium
  • höhere Vorhersagbarkeit im ganzen Projekt
  • Vertrauen der Stakeholder
Muster
  1. Berücksichtigung von Feedback durch Bereitstellung von Produkten in jeder Iteration
  2. Pläne in einem iterativem Prozess anpassen
  3. Änderungen behandeln und verwalten
  4. Bedeutende technische, wirtschaftliche und programmbezogene Risiken in einem frühen Stadium angehen
Antimuster
  • Gesamten Lebenszyklus im Detail planen, Abweichungen vom Plan verfolgen (die zu einem Scheitern des Projekts beitragen können)
  • Status in den ersten zwei Dritteln des Projekts auf der Basis von Prüfungen der Spezifikationen anstatt den Status von Testergebnissen und Demonstrationen funktionierender Software bewerten.

Beschreibung

Dieses Prinzip baut auf mehreren Grundsätzen auf. Der erste Grundsatz lautet wie folgt: Wir müssen einen Wertzuwachs liefern, um frühes und kontinuierliches Feedback zu ermöglichen.. Hierfür wird das Projekt in eine Reihe von Iterationen eingeteilt. In jeder Iteration führen wir einige Aufgaben in den Bereichen Anforderungen, Design, Implementierung und Test aus und erzeugen damit ein Liefergegenstand, der der endgültigen Lösung jeweils einen Schritt näher kommt. Auf diese Weise können wir den Benutzern und anderen Stakeholdern die Anwendung demonstrieren oder zur direkten Verwendung bereitstellen und geben ihnen damit die Möglichkeit, schnelles Feedback zu unserem Fortschritt zu geben. Bewegen wir uns in die richtige Richtung? Sind die Stakeholder mit dem, was wir bisher produziert haben, zufrieden? Müssen wir die bisher implementierten Features ändern? Und schließlich, welche weiteren Features müssen implementiert werden, um den Wert des Produkts zu steigern? Wenn wir diese Fragen zufriedenstellend beantworten können, gewinnen die Stakeholder mehr Vertrauen darin, dass das System, das wir entwickeln, auch ihre Anforderungen berücksichtigt. Außerdem laufen wir weniger Gefahr, es mit unserem Engineering zu übertreiben oder Funktionalität hinzuzufügen, die für den Endbenutzer nicht von Nutzen ist.

Der zweite Grundsatz ist der, Demonstrationen und Feedback zu nutzen, um unsere Pläne anzupassen. Anstatt auf die Bewertung von Spezifikationen, z. B. Anforderungsspezifikationen, Designmodelle oder Pläne, zu vertrauen, müssen wir bewerten, wie gut der bis dahin entwickelte Code wirklich funktioniert. Das bedeutet, wir müssen den Stakeholdern Testergebnisse und Demonstrationen funktionierenden Codes liefern, damit diese unseren Fortschritt beurteilen können. Auf diese Weise geben wir ein Bild von uns ab, zeigen, welche Fortschritte das Team macht, und erkennen, ob wir Kurskorrekturen vornehmen müssen, um das Projekt erfolgreich durchzuführen. Diese Informationen können anschließend verwendet werden, um den Gesamtplan für das Projekt zu überarbeiten und detaillierte Pläne für die nächste Iteration zu entwickeln.

Der dritte Grundsatz ist, Änderungen willkommen zu heißen und zu verwalten. Die heutigen Anwendungen sind zu komplex, um Anforderungen, Design, Implementierung und Test perfekt im ersten Durchgang zu gestalten. Die effektivsten Methoden für die Anwendungsentwicklung heißen die Zwangsläufigkeit von Änderungen willkommen. Durch frühes und kontinuierliches Feedback lernen wir, wie wir die Anwendung verbessern müssen, und der iterative Ansatz gibt uns die Möglichkeit, diese Änderungen inkrementell zu implementieren. Für die Verwaltung dieser Änderungen müssen Prozesse und Tools bereit stehen, damit wir Änderungen effektiv verwalten können, ohne die Kreativität zu behindern.

Der vierte Grundsatz dieses Prinzips ist die Erfordernis, Schlüsselrisiken so früh wie möglich im Lebenszyklus zu eliminieren. Dies wird in der folgenden Abbildung veranschaulicht. Wie müssen die wichtigsten technischen, wirtschaftlichen und programmatischen Risiken so früh wie möglich angehen, anstatt die Risikolösung bis zum Projektende hinauszuschieben. Dazu müssen wir die Risiken, denen wir gegenüber stehen, ständig bewerten und die vorrangigen Risiken in der jeweils nächsten Iteration angehen. In erfolgreichen Projekten werden Stakeholder an den früheren Iterationen, d. h. an der Entwicklung der Vision und übergeordneter Anforderungen, zu denen das Architekturdesign, die Implementierung und Tests gehören, beteiligt, um technische Risiken zu mindern. Außerdem müssen Informationen zusammengestellt werden, die für die Entscheidungen bezüglich der wichtigsten wiederverwendbaren Assets und des Einsatzes kommerzieller Software (COTS, Commercial-of-the-Shelf) herangezogen werden.

Abbildung, die veranschaulicht, dass ein iterativer Prozess eine schnellere Risikominimierung ermöglicht als ein Wasserfallprozess

Risikominimierungsprofile für Wasserfallentwicklung und iterative Entwicklung.

Ein übergeordnetes Ziel bei der iterativen Entwicklung ist eine frühere Risikominimierung. Hierfür werden die vorrangigen Risiken in jeder Iteration analysiert, priorisiert und in Angriff genommen (siehe Unterstützendes Material: Iterative Entwicklung). Zusätzliche Anleitung zur Organisation des Entwicklungszyklus mit Iterationen finden Sie in den Abschnitten Konzept: Iteration und Konzept: Phase.