Vorgehensmodelle: klassisch und agil

Vorgehensmodelle: klassisch und agil

https://bildung.social/@oerinformatik/

https://oer-informatik.de/vorgehensmodelle

Vorgehensmodelle, Wasserfallmodell, V-Modell, Spiralmodell, Agiles Manifest, Scrum, Kanban, Minimum Viable Product, Rapid Prototyping, Softwareergonomie, Projektmanagement, Verifikation und Validierung

tl/dr; (ca. 31 min Lesezeit): Ein Vorgehensmodell legt fest, in welchen Schritten ein Softwareprojekt abläuft, welche Ergebnisse dabei entstehen und wer wofür zuständig ist. Der Artikel unterscheidet klassische (plangetriebene) und agile Vorgehensmodelle, erklärt das Wasserfallmodell, das V-Modell mit seinen Verlaufsrichtungen und Dokumenten, das Spiralmodell, das Agile Manifest, Scrum mit Verantwortlichkeiten, Ereignissen und Artefakten sowie Kanban. Prototypen und das Minimum Viable Product zeigen, wie Du früh Rückmeldung bekommst. Zum Schluss geht es darum, wie Du für eine konkrete Projektsituation ein passendes Vorgehensmodell auswählst und begründest [AI-Assisted]. (Zuletzt geändert am 29.10.2026)

Dieser Artikel ist Teil einer Artikelreihe über Projektmanagement: Vorbereitung eines Projekts / Projektorganisation / Stakeholderanalyse / Vorgehensmodelle / Netzplan / Anforderungsanalyse / Übungsaufgaben zu Vorgehensmodellen

Schon fit in diesem Thema? Nutze die Kann-Liste und die Leitfragen unter dem Artikel als Checkliste, ob Du die relevanten Kompetenzen bereits hast. Hier klicken, um Kann-Liste ein- oder auszublenden

Als Projektmanagement-Grundlagen kann ich nach Durchlesen des Artikels…

• … erklären, wozu ein Vorgehensmodell dient, und die Kategorien klassisch (plangetrieben) und agil beschreiben sowie je zwei Beispiele nennen.

• … klassisches und agiles Vorgehen hinsichtlich Planung und Anforderungen, Umgang mit Änderungen, Einbindung der Auftraggebenden und Dokumentation vergleichen.

• … das Wasserfallmodell mit seinen Phasen in der richtigen Reihenfolge beschreiben und seine Vor- und Nachteile nennen.

• … den Aufbau des V-Modells erklären, Entwurfs- und Testphasen einander zuordnen, die Verlaufsrichtungen erläutern und Fehler in einer V-Modell-Darstellung erkennen; Testfälle der passenden Teststufe und ihrem Vorgabedokument zuordnen.

• … Scrum beschreiben und seine Elemente (Product Owner, Scrum Master, Developers, Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective, Product Backlog, Sprint Backlog, Increment) erläutern.

• … sequenzielle, iterative und agile Vorgehensmodelle an ihren Merkmalen unterscheiden.

• … prüfen, ob vor dem ersten Sprint alles Nötige vereinbart ist, und beurteilen, wann ein agiles Vorgehen ungeeignet ist.

• … erklären, was ein Minimum Viable Product (MVP) ist, Vorteile eines MVP beschreiben und an Beispielen zeigen, wie Weiterentwicklungen den Nutzen für die Kundschaft steigern.

• … Rapid Prototyping und Softwareergonomie erläutern und begründen, warum Prototypen zu gut benutzbarer Software beitragen.

• … für eine Projektsituation ein passendes Vorgehensmodell auswählen und die Wahl begründen.

Darüber hinaus kann ich als Projektmanagement-Expertenwissen…

• … die vier Werte des Agilen Manifests nennen und an Beispielen erläutern.

• … Kanban mit Board, WIP-Limit und Pull-Prinzip beschreiben und von Scrum abgrenzen.

• … das Spiralmodell als risikogetriebenes, iteratives Modell beschreiben und hybride Vorgehensweisen beurteilen.

• … typische Missverständnisse über Scrum (z. B. Scrum Master als Chef, Daily als Statusbericht) erkennen und richtigstellen.

Die Fahrradmanufaktur CSB-Rad in Bielefeld lässt ein Werkstattportal entwickeln: fester Termin, festes Budget, eine klare Liste von Funktionen im Pflichtenheft. Ein paar Kilometer weiter baut das Start-up Let’s Meet seine Freizeit-App neu auf: Niemand weiß genau, welche Funktionen die Nutzenden in einem halben Jahr am meisten brauchen, und der Markt ändert sich ständig. Beide Teams entwickeln Software, aber sie werden ihre Projekte sehr unterschiedlich organisieren. Genau darum geht es bei Vorgehensmodellen.

Wozu braucht ein Projekt ein Vorgehensmodell?

Ein Vorgehensmodell (process model, im Projektmanagement auch Projektmanagementmethode) beschreibt den Ablauf eines Projekts in einer wiederverwendbaren Form. Es legt fest,

• welche Schritte (Phasen, Iterationen, Aktivitäten) in welcher Reihenfolge durchlaufen werden,

• welche Ergebnisse dabei entstehen (Podukte, Artefakte, Dokumente, Software, Prüfprotokolle),

• wer welche Aufgaben und Verantwortung hat (Rollen),

• und wann und wie geprüft wird, ob ein Schritt erfolgreich war.

Ein einheitliches Vorgehensmodell macht Projekte planbar und vergleichbar, erleichtert neuen Teammitgliedern den Einstieg und ist eine Maßnahme der Qualitätssicherung: Wer nach einem anerkannten, standardisierten Modell arbeitet, vergisst seltener wichtige Schritte wie Tests, Reviews oder die Abnahme.

Zwei Kategorien: klassisch und agil

Vorgehensmodelle werden üblicherweise in zwei Kategorien eingeteilt.

Klassische Vorgehensmodelle (auch plangetrieben, traditionell oder schwergewichtig) gehen davon aus, dass sich die Anforderungen zu Beginn vollständig ermitteln lassen. Das Projekt wird in Phasen eingeteilt, die nacheinander (sequenziell) durchlaufen werden. Am Anfang steht eine detaillierte Planung von Umfang, Terminen und Kosten; jede Phase endet mit einem festgelegten Ergebnisdokument. Klassische Modelle sind stark standardisiert, gut dokumentiert und als Referenz anerkannt. Beispiele sind das Wasserfallmodell und das V-Modell.

Agile Vorgehensmodelle (auch leichtgewichtig) gehen davon aus, dass sich Anforderungen im Laufe des Projekts ändern und erst durch Erfahrung mit ersten Ergebnissen klar werden. Gearbeitet wird in kurzen Zyklen (iterativ), in denen jeweils ein lauffähiges Stück Software entsteht (inkrementell). Geplant wird schrittweise und nur so weit im Voraus wie nötig. Die Auftraggebenden arbeiten eng und regelmäßig mit, Änderungen sind ausdrücklich erwünscht. Beispiele sind Scrum, Kanban und Extreme Programming (XP).

Drei Begriffe helfen beim Einordnen:

• sequenziell: Phasen werden nacheinander abgearbeitet; eine Phase startet erst, wenn die vorige abgeschlossen ist (Wasserfall, V-Modell).

• iterativ: Festgelegte Phasen oder Tätigkeiten werden wiederholt durchlaufen, jedes Mal mit mehr Wissen (z. B. das Spiralmodell).

• inkrementell: Das Produkt wächst in Stücken (Inkrementen), die jeweils schon nutzbar sind. Agile Modelle sind iterativ und inkrementell.

Nicht jedes Modell passt sauber in eine Schublade: Das Spiralmodell ist iterativ, wird wegen seiner umfangreichen Planung und Dokumentation aber meist zu den klassischen Modellen gezählt.

Darüber hinaus gibt es Projektmanagementmethoden, die die Projektstruktur und den Ablauf auf höherer Ebene regeln: ein Beispiel hierfür wäre PRINCE2, das kein agiles Modell ist, sondern eine prozessorientierte, klassische Projektmanagementmethode (es gibt allerdings die Variante PRINCE2 Agile, die agile Teams in einen PRINCE2-Rahmen einbettet).

Das Wasserfallmodell

Beim Wasserfallmodell fließt das Projekt wie Wasser über Stufen von einer Phase in die nächste.

Da es ein dokumentengetriebenes Vorgehensmodell ist, muss am Ende jeder Phase mindestens ein Artefakt erzeugt werden, was den Abschluss der jeweiligen Phase definiert. Die Artefakte der vorgelagerten Phasen bilden jeweils die Basis der darauf folgenden Phasen.

Typische Phasen der Softwareentwicklung sind:

1. Analyse: Anforderungen erheben und festschreiben (Artefakte: z.B. Lastenheft, später Pflichtenheft).

2. Entwurf: Architektur, Datenmodell, Module und Schnittstellen planen (Artefakte: z.B. Entwurfsdiagramme und -dokumente).

3. Implementierung (Realisierung): programmieren (Artefakte: z.B. Programmcode).

4. Test: prüfen, ob die Software die Anforderungen erfüllt; Abnahme durch die Auftraggebenden (Artefakte: z.B. Testprotokoll).

5. Einsatz und Wartung: übergeben, in Betrieb nehmen, Fehler beheben, pflegen (Artefakte: z.B. Abnahmeprotokoll).

Manchmal werden mehr oder anders benannte Phasen verwendet (z. B. Planung vor der Analyse oder ein getrennter Abnahmetest). Entscheidend ist das Prinzip: Jede Phase wird vollständig abgeschlossen, bevor die nächste beginnt, und ihr Ergebnis ist die verbindliche Grundlage der nächsten Phase.

Werden im Wasserfallmodell Probleme oder Fehler in einer der vorgelagerten Phase erkannt, müssen alle Artefakte der darauf nachfolgenden Phasen neu erstellt oder angepasst werden. Im Netz ist häufig die Rede von einer Art strengem Wasserfallmodell, in dem Rücksprünge nicht erlaubt sind. Das ist natürlich in der Praxis Unsinn, man müsste ja wissend ein fehlerhaftes Produkt ausliefern. Statt von einem erweiterten Wasserfallmodell zu sprechen wäre es also wichtiger, hervorzuheben, dass alle Artefakte bei Rücksprüngen nachgezogen werden müssen.

Vorteile: einfach zu verstehen und zu steuern, klare Meilensteine an den Phasenübergängen, Kosten und Termine früh planbar, umfangreiche Dokumentation, gut geeignet für Festpreisverträge und für Projekte mit stabilen, gut bekannten Anforderungen.

Nachteile: Fehler in den Anforderungen fallen oft erst im Test auf, wenn ihre Behebung teuer ist. Die Auftraggebenden sehen lauffähige Software erst ganz am Ende. Späte Änderungen erfordern umfangreiche Umplanung und führen zu Verzögerungen und Mehrkosten.

Interessant: Winston W. Royce, auf den das Wasserfallmodell oft zurückgeführt wird, hat es 1970 gerade als problematisches Vorgehen beschrieben und Verbesserungen vorgeschlagen, etwa einen Prototyp („do it twice“) und die frühe Einbindung der Kundschaft. Mehr dazu im Artikel Leitfragen zu Royce’ Kritik am „Wasserfallmodell“.

Das V-Modell: Zu jedem Entwurf gehört ein Test

Das V-Modell ist eine Weiterentwicklung des Wasserfallmodells, das die Qualitätssicherung in den Mittelpunkt stellt. Die Phasen werden in Form eines „V“ angeordnet:

• Der linke Ast führt von oben nach unten durch Spezifikation und Entwurf. Das System wird schrittweise zerlegt und immer genauer beschrieben (top-down).

• An der Spitze unten steht die Implementierung.

• Der rechte Ast führt von unten nach oben durch Integration und Test. Die Teile werden zusammengesetzt und auf jeder Ebene geprüft (bottom-up).

Jeder Testphase rechts steht eine Entwurfsphase links auf gleicher Höhe gegenüber. Die Testfälle und Prüfkriterien werden schon beim Entwurf festgelegt: Wer die Anforderungen schreibt, legt gleich fest, wie die Abnahme sie prüft.

Die Benennung der Phasen unterscheidet sich je nach Quelle (z. B. „Grobentwurf“ statt Systementwurf, „Feinentwurf“ statt Komponentenentwurf, „Modultest“ statt Komponententest). Architekturen werden häufig nur bei wirklich großen Projekten individuell entworfen - häufig gibt die Wahl eines bestimmten Frameworks hier bereits sehr viel vor. Begegnen Dir Phasen unter anderen Namen, hilft beim Einordnen die Frage: Was wird hier beschrieben, und welcher Test prüft genau das?

Verlaufsrichtungen im V-Modell

• Phase erfolgreich abgeschlossen: Links geht es abwärts in die nächste Entwurfsphase, nach der Implementierung rechts aufwärts in die nächste Testphase.

• Test nicht bestanden: Es geht waagerecht zurück zur gegenüberliegenden Entwurfsphase. Fällt der Integrationstest durch, wird der Systementwurf (Schnittstellen, Architektur) überarbeitet; danach wird der Weg erneut abwärts und wieder aufwärts durchlaufen.

Dokumente: Das V-Modell ist dokumentengetrieben

Jede Phase endet mit einem prüfbaren Dokument. Zu den Testphasen gehören Testprotokolle bzw. Testberichte (welcher Testfall, welche Eingabe, erwartetes und tatsächliches Ergebnis, Datum, Prüfende), zum Abnahmetest das Abnahmeprotokoll, zur Übergabe ein Übergabeprotokoll und das Benutzerhandbuch. Diese Dokumente sind zugleich Nachweise gegenüber den Auftraggebenden.

Verifikation und Validierung

Das V-Modell macht zwei Prüffragen sichtbar:

• Verifikation: Bauen wir das Produkt richtig? Stimmt das Ergebnis einer Phase mit seiner Vorgabe überein (z. B. Modul mit Modulbeschreibung)? Das prüfen vor allem Komponenten-, Integrations- und Systemtest.

• Validierung: Bauen wir das richtige Produkt? Erfüllt das System den tatsächlichen Zweck der Nutzenden? Das zeigt sich spätestens beim Abnahmetest.

Für IT-Projekte des Bundes gibt es mit dem V-Modell XT eine umfangreiche, anpassbare Weiterentwicklung (XT steht für eXtreme Tailoring). Sie beschreibt Rollen, Produkte und Entscheidungspunkte und lässt sich auch mit iterativen Abläufen kombinieren.

Stärken des V-Modells: Tests werden früh geplant, jedes Ergebnis wird geprüft, Fehler werden einer Ebene zugeordnet, die Nachweise sind lückenlos. Das passt gut zu sicherheitskritischen Systemen, Hardware-nahen Projekten oder Projekten mit vertraglich vereinbarter Abnahme. Schwächen: Wie beim Wasserfall sind späte Änderungen der Anforderungen teuer, der Dokumentationsaufwand ist hoch, und lauffähige Software gibt es erst spät.

Iterativ und risikogetrieben: das Spiralmodell

Das Spiralmodell (Barry Boehm, 1986) durchläuft dieselben vier Tätigkeiten immer wieder in einer Spirale, die mit jeder Runde größer wird:

1. Ziele, Alternativen und Randbedingungen festlegen,

2. Risiken bewerten und verringern (z. B. durch einen Prototyp),

3. entwickeln und prüfen,

4. die nächste Runde planen.

Bei jedem Umlauf wächst das Produkt, und vor jedem Umlauf wird entschieden, ob das Projekt weitergeführt wird. Das Spiralmodell ist damit iterativ und risikogetrieben. Es eignet sich für große, riskante Vorhaben, ist aber aufwendig zu steuern.

Agile Werte: das Agile Manifest

2001 formulierten 17 Softwareentwickler*innen das Manifest für Agile Softwareentwicklung. Es stellt vier Werte gegenüber:

• Individuen und Interaktionen mehr als Prozesse und Werkzeuge,

• Funktionierende Software mehr als umfassende Dokumentation,

• Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung,

• Reagieren auf Veränderung mehr als das Befolgen eines Plans.

Wichtig ist der Nachsatz: Die Werte auf der rechten Seite sind durchaus wichtig, die auf der linken werden aber höher geschätzt. Agil heißt also nicht „ohne Dokumentation“ oder „ohne Plan“, sondern: so viel Dokumentation und Planung wie nötig, so viel lauffähige Software und Rückmeldung wie möglich. Zwölf Prinzipien konkretisieren die Werte, etwa „Liefere funktionierende Software regelmäßig innerhalb weniger Wochen“ oder „Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen“.

Scrum: das verbreitetste agile Rahmenwerk

Scrum ist ein Rahmenwerk (framework) für die Entwicklung komplexer Produkte in kleinen Teams. Es wird im Scrum Guide von Ken Schwaber und Jeff Sutherland beschrieben (aktuelle Fassung von November 2020). Scrum legt nur wenige, verbindliche Elemente fest: drei Verantwortlichkeiten, fünf Ereignisse und drei Artefakte.

Das Scrum Team: drei Verantwortlichkeiten

Ein Scrum Team ist klein (in der Regel zehn Personen oder weniger), funktionsübergreifend und organisiert sich selbst. Es hat keine Hierarchie und keine Unterteams.

• Product Owner: verantwortet den Wert des Produkts. Pflegt und priorisiert das Product Backlog, formuliert das Produktziel und spricht mit den Stakeholdern. Es ist eine Person, kein Gremium; sie entscheidet, was als Nächstes entwickelt wird. Für Auftraggebende und Fachabteilungen ist der Product Owner deshalb die Ansprechperson für Anforderungen: Wer einen Wunsch hat, wendet sich an ihn, nicht an einzelne Developers.

• Scrum Master: verantwortet, dass Scrum wirksam gelebt wird. Unterstützt Team und Organisation, moderiert bei Bedarf, beseitigt Hindernisse (impediments), schützt das Team vor Störungen. Der Scrum Master ist keine Projektleitung und verteilt keine Aufgaben.

• Developers: alle, die im Sprint das Increment erstellen (Programmierung, Test, UX, Datenbank …). Sie planen die Arbeit des Sprints selbst und sind für die Qualität verantwortlich. (Ältere Fassungen sprachen vom Entwicklungsteam.)

Fünf Ereignisse

• Sprint: Container für alle anderen Ereignisse; ein Zeitraum fester Länge von höchstens einem Monat (häufig zwei bis vier Wochen). Ein neuer Sprint beginnt direkt nach dem Ende des vorigen. Während des Sprints wird das Sprintziel nicht geändert und die Qualität nicht gesenkt.

• Sprint Planning: Zu Beginn legt das Scrum Team fest, warum der Sprint wertvoll ist (Sprintziel), was umgesetzt werden kann (Auswahl aus dem Product Backlog) und wie die Arbeit erledigt wird. Höchstens acht Stunden bei einem einmonatigen Sprint.

• Daily Scrum: tägliches Treffen der Developers von höchstens 15 Minuten, immer zur gleichen Zeit am gleichen Ort. Sie prüfen den Fortschritt zum Sprintziel und passen ihre Planung für den nächsten Tag an. Die bekannten drei Fragen („Was habe ich gestern gemacht? Was mache ich heute? Was behindert mich?“) sind eine mögliche Form, seit 2020 aber nicht mehr vorgeschrieben.

• Sprint Review: Am Ende des Sprints stellt das Scrum Team den Stakeholdern das Ergebnis vor; gemeinsam wird besprochen, was erreicht wurde und was sich geändert hat. Das Product Backlog wird angepasst. Das Review ist eine Arbeitssitzung, keine reine Präsentation.

• Sprint Retrospective: Zum Abschluss des Sprints reflektiert das Scrum Team seine Zusammenarbeit: Was lief gut, was nicht, was ändern wir im nächsten Sprint? Es geht um Personen, Abläufe, Werkzeuge und die Definition of Done, nicht um das Produkt selbst.

Drei Artefakte und ihre Verpflichtungen

• Product Backlog: geordnete Liste aller bekannten Anforderungen und Arbeiten am Produkt, gepflegt vom Product Owner. Die Einträge werden oft als User Stories formuliert („Als Nutzerin möchte ich …, damit …“). Verpflichtung: das Produktziel (Product Goal).

• Sprint Backlog: die für den Sprint ausgewählten Einträge plus der Plan der Developers, wie sie umgesetzt werden. Verpflichtung: das Sprintziel (Sprint Goal).

• Increment: das im Sprint fertiggestellte, nutzbare Ergebnis, das zu allen früheren Increments passt. Verpflichtung: die Definition of Done, also die gemeinsam festgelegten Qualitätskriterien („getestet, Code-Review erfolgt, dokumentiert, auf dem Testserver installiert …“). Was die Definition of Done nicht erfüllt, ist nicht fertig.

Zusammen ergeben sich die Elemente, die der Scrum Guide verbindlich festlegt:

Wie geht Scrum mit Änderungen um?

Neue Wünsche kommen nicht in den laufenden Sprint, sondern als neuer Eintrag ins Product Backlog. Der Product Owner priorisiert ihn, und schon im nächsten Sprint Planning kann er umgesetzt werden. So bleibt der Sprint für die Developers planbar, und trotzdem kann das Projekt alle paar Wochen die Richtung ändern. Nur wenn das Sprintziel völlig überholt ist, darf der Product Owner einen Sprint abbrechen.

Bei Let’s Meet könnte das so aussehen: Im Sprint Review zeigt das Team die neue Aktivitätensuche. Eine Testnutzerin im Rollstuhl merkt an, dass sie zuerst wissen muss, ob der Treffpunkt barrierefrei ist. Die Product Owner nimmt einen Filter „barrierefreier Treffpunkt“ als neue User Story ins Product Backlog auf und setzt ihn weit nach oben. Zwei Wochen später ist er online.

Ein agiles Projekt starten

Wer ein Projekt agil beginnen will, muss vor dem ersten Sprint einiges vereinbaren. Typische Aktivitäten sind:

• Verantwortlichkeiten besetzen: Wer ist Product Owner, wer Scrum Master, wer gehört zu den Developers?

• Product Backlog anlegen: erste Anforderungen als User Stories sammeln, schätzen und priorisieren; ein Produktziel formulieren.

• Takt festlegen: Sprintlänge (z. B. zwei Wochen) sowie feste Termine für Sprint Planning, Daily Scrum, Sprint Review und Retrospective.

• Definition of Done vereinbaren: Wann gilt ein Eintrag als fertig (getestet, Code-Review, dokumentiert …)?

• Arbeit sichtbar machen: ein Board (analog oder digital) für das Sprint Backlog einrichten.

• Technische Praktiken einführen: z. B. testgetriebene Entwicklung, Versionsverwaltung und kontinuierliche Integration, damit am Sprintende wirklich ein lauffähiges Increment steht.

Während des Projekts wiederholen sich die Ereignisse in jedem Sprint; in der Retrospective wird auch der Ablauf selbst immer wieder verbessert.

Typische Missverständnisse

Typische Missverständnisse über Scrum

Missverständnis	richtig ist
Der Scrum Master ist der Chef und verteilt die Aufgaben.	Die Developers organisieren sich selbst; der Scrum Master unterstützt und beseitigt Hindernisse.
Das Daily Scrum ist ein Statusbericht an die Leitung.	Es ist ein kurzes Planungstreffen der Developers für die nächsten 24 Stunden.
Sprints sind so lang, wie die Arbeit eben dauert.	Sprints haben eine feste Länge von höchstens einem Monat; der Umfang passt sich an, nicht die Dauer.
Neue Wünsche kommen sofort in den laufenden Sprint.	Neue Wünsche kommen ins Product Backlog und werden ab dem nächsten Sprint berücksichtigt.
Im Review geht es um die Zusammenarbeit im Team.	Im Review geht es um das Produkt (mit Stakeholdern), in der Retrospective um die Zusammenarbeit (im Scrum Team).
Agil bedeutet: keine Dokumentation.	Dokumentiert wird, was Wert hat; die Definition of Done kann Dokumentation ausdrücklich verlangen.

Kanban: Arbeit sichtbar machen und begrenzen

Kanban stammt aus der Produktion (Toyota) und wurde für die Wissensarbeit angepasst. Es kennt keine Sprints und keine festen Rollen. Stattdessen:

• Visualisieren: Alle Aufgaben stehen als Karten auf einem Kanban-Board mit Spalten wie „Offen – In Arbeit – Test – Erledigt“.

• Arbeit in Arbeit begrenzen (WIP-Limit, work in progress): Jede Spalte darf nur eine bestimmte Zahl von Karten enthalten. So wird erst fertiggestellt, bevor Neues begonnen wird.

• Pull-Prinzip: Wer frei ist, zieht sich die nächste Karte, statt dass Arbeit zugeteilt wird.

• Fluss messen und verbessern: z. B. die Durchlaufzeit einer Karte vom Start bis „Erledigt“.

Kanban eignet sich besonders für fortlaufende Arbeit mit unvorhersehbarem Eingang, etwa Support, Wartung oder Betrieb. Viele Teams kombinieren Scrum mit einem Kanban-Board für das Sprint Backlog.

Extreme Programming (XP) ergänzt diese Rahmenwerke um technische Praktiken: Programmieren in Paaren, testgetriebene Entwicklung, kontinuierliche Integration, kleine Releases und gemeinsames Code-Eigentum.

Früh ausprobieren: Prototypen und Minimum Viable Product

Agile Vorgehensmodelle leben von Rückmeldungen. Zwei Techniken sorgen dafür, dass diese Rückmeldungen möglichst früh kommen: Prototypen und das Minimum Viable Product. Beide werden auch in klassischen Projekten genutzt, etwa für die Oberfläche.

Rapid Prototyping und Softwareergonomie

Ein Prototyp ist ein früher, unvollständiger Entwurf der Software, an dem sich Ideen ausprobieren lassen, z. B. ein klickbares Mockup der Oberfläche. Beim Rapid Prototyping werden solche Prototypen schnell und mit wenig Aufwand erstellt, mit späteren Nutzenden getestet und anhand der Rückmeldungen verbessert. Ein Wegwerf-Prototyp dient nur zum Lernen und wird danach verworfen; ein evolutionärer Prototyp wird schrittweise zum fertigen Produkt ausgebaut.

Softwareergonomie beschreibt, wie gut sich Software an die Menschen anpasst, die damit arbeiten: Sie soll leicht erlernbar, effizient und fehlertolerant bedienbar sein. Maßstab sind die Interaktionsprinzipien der Norm DIN EN ISO 9241-110 (z. B. Aufgabenangemessenheit, Selbstbeschreibungsfähigkeit, Erwartungskonformität, Erlernbarkeit, Steuerbarkeit, Robustheit gegen Benutzungsfehler und Benutzerbindung).

Muss eine Oberfläche besonders gut bedienbar sein, lohnt sich Rapid Prototyping, denn Bedienbarkeit lässt sich kaum am Schreibtisch beurteilen: Erst wenn echte Nutzende einen Prototyp ausprobieren, zeigt sich, wo sie stocken, etwas nicht finden oder Begriffe falsch verstehen. Die Rückmeldung kommt sofort, Änderungen an einem Prototyp sind billig, und die Oberfläche wird in mehreren kurzen Runden an die Nutzenden angepasst, bevor viel programmiert ist.

Das Minimum Viable Product (MVP)

Ein Minimum Viable Product (MVP, sinngemäß minimal überlebensfähiges Produkt) ist die erste Version eines Produkts, die gerade so viele Funktionen hat, dass sie den eigentlichen Zweck erfüllt und von echten Kundinnen und Kunden unter realen Bedingungen genutzt werden kann. Manchmal ist das nur eine einzige Funktion. Bekannt wurde der Begriff durch Eric Ries’ Buch The Lean Startup (2011).

Anders als ein Prototyp ist ein MVP im echten Einsatz: Es wird veröffentlicht, genutzt und gemessen. Danach wird es in kurzen Schritten weiterentwickelt (bauen – messen – lernen). Der Nutzen für die Kundschaft steigt dabei von Version zu Version, weil

• die Rückmeldungen und Nutzungsdaten zeigen, welche Funktionen wirklich gebraucht werden,

• die wichtigsten Wünsche priorisiert und zuerst umgesetzt werden (im Product Backlog),

• Fehler früh behoben und neue Merkmale (Bequemlichkeit, Leistung, Anpassung an Kundenwünsche) ergänzt werden.

Für Unternehmen lohnt sich ein MVP, weil

• das finanzielle Risiko sinkt: Es wird nur wenig investiert, bevor feststeht, ob das Produkt angenommen wird,

• die Akzeptanz am Markt früh geklärt wird,

• frühes Feedback in die weitere Entwicklung einfließt und nötige Anpassungen früh erkannt werden,

• das Produkt schneller auf den Markt kommt und schon Nutzen (und ggf. Umsatz) bringt.

Bei Let’s Meet könnte das MVP der neuen App nur eine Funktion haben: Aktivitäten in Bielefeld anlegen und sich dafür anmelden. Zeigt sich, dass viele Nutzende Aktivitäten absagen, weil sie niemanden kennen, wird als Nächstes eine Gruppenfunktion entwickelt; wünschen sich viele Erinnerungen, folgen Push-Nachrichten. Funktionen, die niemand nutzt, werden gar nicht erst gebaut.

Klassisch und agil im Vergleich

Hinter der Tabelle steckt ein Unterschied im magischen Dreieck (siehe Projektorganisation): Klassisch wird der Umfang festgelegt, Zeit und Kosten werden daraus geschätzt. Agil werden Zeit (Sprints) und Kosten (Team) festgelegt, und der Umfang ergibt sich aus dem, was in dieser Zeit den größten Wert bringt.

Welches Vorgehensmodell passt?

Es gibt kein „bestes“ Vorgehensmodell. Für die Auswahl helfen diese Fragen:

Agil ist also nicht immer die bessere Wahl. Gegen ein agiles Vorgehen sprechen zum Beispiel:

• Ziele und Anforderungen stehen fest und werden sich voraussichtlich nicht ändern (dann bringt die Flexibilität wenig),

• das Vorhaben ist so klein, dass Sprints und Ereignisse mehr Aufwand als Nutzen bringen,

• niemand kann die Verantwortlichkeiten Product Owner oder Scrum Master übernehmen, weil Erfahrung oder Zeit fehlen,

• Auftraggebende, die nicht regelmäßig mitarbeiten können oder wollen,

• ein Festpreisvertrag mit festem Umfang oder formale Nachweise, die vorab vollständig geplant sein müssen,

• eine stark hierarchische Kultur, in der Vorgesetzte Lösung und Weg vorgeben, statt dem Team die Organisation zu überlassen.

In der Praxis sind hybride Vorgehensweisen häufig: Das Gesamtprojekt hat klassische Meilensteine (z. B. Abnahme durch die Schulleitung, Beschaffung der Hardware, Datenschutzfreigabe), innerhalb der Software-Entwicklung wird in Sprints gearbeitet. Wichtig ist, die Wahl bewusst zu treffen und mit der Projektsituation zu begründen: „Wir arbeiten agil, weil die Nutzenden ihre Wünsche erst an ersten Versionen konkretisieren können und die Geschäftsführerin jede zweite Woche zum Review kommt“ ist eine Begründung, „agil ist modern“ ist keine.

Für das Werkstattportal von CSB-Rad mit festem Budget, festem Termin und abgestimmtem Pflichtenheft ist ein klassisches Vorgehen gut begründbar. Für den Neuaufbau von Let’s Meet, bei dem die Geschäftsführerin als Product Owner im Haus sitzt und die Nutzenden laufend Rückmeldung geben, spricht vieles für Scrum.

Leitfragen

1. Wozu dient ein Vorgehensmodell, und warum ist es auch eine Maßnahme der Qualitätssicherung? Antwort

Ein Vorgehensmodell beschreibt den Ablauf eines Projekts wiederverwendbar: welche Schritte in welcher Reihenfolge durchlaufen werden, welche Ergebnisse entstehen, wer welche Verantwortung hat und wann geprüft wird. Es ist eine Maßnahme der Qualitätssicherung, weil man nach einem anerkannten, standardisierten Modell seltener wichtige Schritte wie Tests, Reviews oder die Abnahme vergisst, siehe Abschnitt „Wozu braucht ein Projekt ein Vorgehensmodell?“.

2. Woran unterscheidest Du klassische und agile Vorgehensmodelle, und welche Beispiele gehören jeweils dazu? Antwort

Klassische (plangetriebene) Modelle gehen davon aus, dass sich die Anforderungen zu Beginn vollständig ermitteln lassen, und durchlaufen Phasen nacheinander mit festgelegten Ergebnisdokumenten – Beispiele sind Wasserfallmodell und V-Modell. Agile Modelle rechnen mit sich ändernden Anforderungen, arbeiten iterativ und inkrementell in kurzen Zyklen und binden die Auftraggebenden eng ein – Beispiele sind Scrum, Kanban und Extreme Programming, siehe Abschnitt „Zwei Kategorien: klassisch und agil“.

3. Wie unterscheiden sich klassisches und agiles Vorgehen bei Planung und Anforderungen und beim Umgang mit Änderungen? Antwort

Klassisch wird zu Beginn vollständig geplant (Umfang, Termine, Kosten) und die Anforderungen werden in Lasten- und Pflichtenheft festgeschrieben; Änderungen erfordern Change Requests, Umplanung und oft Mehrkosten. Agil wird schrittweise geplant, die Anforderungen entwickeln sich im priorisierten Product Backlog, und Änderungen sind erwünscht und fließen ab dem nächsten Sprint ein, siehe Abschnitt „Klassisch und agil im Vergleich“.

4. Welche Phasen hat das Wasserfallmodell, und warum werden Fehler in den Anforderungen dort teuer? Antwort

Typische Phasen sind Analyse, Entwurf, Implementierung, Test sowie Einsatz und Wartung; jede Phase wird vollständig abgeschlossen, bevor die nächste beginnt. Fehler in den Anforderungen fallen oft erst im Test auf, wenn schon entworfen und programmiert wurde – ihre Behebung erfordert dann umfangreiche Umplanung und wird teuer, siehe Abschnitt „Das Wasserfallmodell“.

5. Wie ordnest Du Entwurfs- und Testphasen im V-Modell an, welche Verlaufsrichtungen gibt es, und welches Dokument entsteht in welcher Phase? Antwort

Links stehen von oben nach unten die Entwurfsphasen (Anforderungsdefinition mit Lastenheft, Systemspezifikation mit Pflichtenheft, Systementwurf mit Architekturbeschreibung, Komponentenentwurf mit Modulbeschreibungen), unten die Implementierung, rechts aufwärts die zugehörigen Testphasen (Komponenten-, Integrations-, System- und Abnahmetest mit Testprotokollen bzw. Abnahmeprotokoll). Bei Erfolg geht es links abwärts und rechts aufwärts; fällt ein Test durch, geht es waagerecht zurück zur gegenüberliegenden Entwurfsphase, siehe Abschnitt „Das V-Modell: Zu jedem Entwurf gehört ein Test“ und Abschnitt „Verlaufsrichtungen im V-Modell“.

6. Was unterscheidet sequenzielle, iterative und inkrementelle Vorgehensweisen? Antwort

Sequenziell heißt, Phasen werden nacheinander abgearbeitet und jede muss abgeschlossen sein, bevor die nächste beginnt (Wasserfall, V-Modell). Iterativ werden festgelegte Phasen oder Tätigkeiten wiederholt durchlaufen, jedes Mal mit mehr Wissen (z. B. Spiralmodell); inkrementell wächst das Produkt in jeweils schon nutzbaren Stücken – agile Modelle sind iterativ und inkrementell, siehe Abschnitt „Zwei Kategorien: klassisch und agil“.

7. Welche Verantwortlichkeiten, Ereignisse und Artefakte gehören zu Scrum, und was passiert mit einem neuen Wunsch mitten im Sprint? Antwort

Scrum hat drei Verantwortlichkeiten (Product Owner, Scrum Master, Developers), fünf Ereignisse (Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective) und drei Artefakte (Product Backlog, Sprint Backlog, Increment). Ein neuer Wunsch kommt nicht in den laufenden Sprint, sondern als neuer Eintrag ins Product Backlog, wird vom Product Owner priorisiert und kann ab dem nächsten Sprint Planning umgesetzt werden, siehe Abschnitt „Scrum: das verbreitetste agile Rahmenwerk“ und Abschnitt „Wie geht Scrum mit Änderungen um?“.

8. Wie unterscheidet sich Kanban von Scrum? Antwort

Kanban kennt keine Sprints und keine festen Rollen: Die Arbeit wird auf einem Kanban-Board sichtbar gemacht, ein WIP-Limit begrenzt die Karten je Spalte, nach dem Pull-Prinzip zieht sich jeder die nächste Karte, und der Fluss (z. B. Durchlaufzeit) wird gemessen und verbessert. Es eignet sich besonders für fortlaufende Arbeit mit unvorhersehbarem Eingang wie Support oder Wartung, siehe Abschnitt „Kanban: Arbeit sichtbar machen und begrenzen“.

9. Welche Merkmale einer Projektsituation sprechen für ein klassisches, welche für ein agiles Vorgehen? Antwort

Für klassisch sprechen vollständig bekannte, stabile Anforderungen, erprobte Technik, wenig Zeit der Auftraggebenden zur Mitarbeit, geforderte formale Nachweise oder Abnahmen und ein Festpreisvertrag mit festem Umfang. Für agil sprechen unklare oder sich ändernde Anforderungen, neue Technik, regelmäßig mitarbeitende Auftraggebende, früh benötigte Teilergebnisse und ein kleines, erfahrenes Team. Gegen agil sprechen etwa unveränderliche Ziele, ein geringer Umfang oder fehlendes Personal für Product Owner und Scrum Master – wichtig ist, die Wahl mit der konkreten Projektsituation zu begründen, siehe Abschnitt „Welches Vorgehensmodell passt?“.

10. Was ist ein Minimum Viable Product, wie unterscheidet es sich von einem Prototyp, und warum unterstützt Rapid Prototyping die Softwareergonomie? Antwort

Ein MVP ist die erste Version eines Produkts mit gerade so vielen Funktionen, dass es seinen Zweck erfüllt und von echter Kundschaft genutzt werden kann; es senkt das finanzielle Risiko, klärt früh die Akzeptanz und wird anhand der Rückmeldungen schrittweise weiterentwickelt, wobei priorisierte Wünsche zuerst umgesetzt werden. Ein Prototyp dient dagegen nur zum Ausprobieren und ist nicht im echten Einsatz. Rapid Prototyping liefert schnell Rückmeldungen echter Nutzender zur Bedienung, sodass die Oberfläche in kurzen Runden an sie angepasst wird, siehe Abschnitt „Früh ausprobieren: Prototypen und Minimum Viable Product“.

Links und weitere Informationen

• Leitfragen zu Royce’ Kritik am „Wasserfallmodell“

• Lastenheft: Anforderungsdefinition durch den Kunden und Pflichtenheft: Anforderungsanalyse durch Entwickler*innen

• Projekte organisieren: von den Projektzielen bis zum Projektabschluss

• Anforderungsanalyse (Requirements Engineering)

• als Nachschlagewerk: Der Scrum Guide (deutsche Fassung, November 2020)

• für den Einstieg: Manifest für Agile Softwareentwicklung (deutsch)

• zum Weiterlesen: Eric Ries: The Lean Startup (2011), Ursprung des Begriffs „Minimum Viable Product“ in seiner heute verbreiteten Bedeutung

• historisch: Winston W. Royce: Managing the development of large software systems (1970)

---

Hinweis zur Nachnutzung als Open Educational Resource (OER)

Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “Vorgehensmodelle: klassisch und agil” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/vorgehensmodelle veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/vorgehensmodelle/vorgehensmodelle. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 29.10.2026.

[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]