Scrum Abgrenzung zum Wasserfallmodell

Das klassische Wasserfallmodell im Bezug zu Scrum

Das Wasserfallmodell ist eine sehr starre Vorgehensmethode bei der Phase für Phase die einzelnen Projektschritte abgearbeitet werden.

Das Wasserfallmodell, ein klassisches Vorgehensmodell welches sehr schwergewichtig, monolithisch und daher träge und teuer ist. Es wird Phase für Phase abgearbeitet.

Es wird zuerst Anforderungsspezifikation-Phase durchlaufen, danach die Planung, das Design und der Entwurf erstellt und danach die Entwicklung und das Testing durchgeführt und letzten Endes die Fertigstellung und Abnahme und der Betrieb der Software sichergestellt. Dabei stellt jede Phase eigene Artefakte her, welche der nächsten Phase weitergereicht werden. Tritt spät im Prozess ein Fehler auf, müssen einzelne Phasen oder mehrere Phasen zurückgerollt werden. Der Fehler wird dann im Artefakt der Phase behoben in dem er aufgetreten ist. Danach wird wieder Phase für Phase aufgerollt. Dieses Vorgehen ist daher sehr schwergewichtig, monolithisch und daher träge und daher teuer.

 

Abgrenzung zu klassischen Vorgehensmodellen am Beispiel Wasserfallmodell

Wenn man frühere Softwareentwicklungs-Vorgehensmodelle betrachtet, wie beispielsweise das Wasserfallmodell, so hat man als Kunde (User oder Produktverantwortlicher) oft eine Blackbox vor sich.

Der Kunde schreibt gemeinsam mit Experten ein Spezifikationsdokument. Der Auftragnehmer löst diese Aufgaben dann in einer Blackbox. Erst am Schluss nach der Test- und Release-Phase bei der Endabnahme, oder bei der Abnahme von Meilensteinen kann der Kunde dann die Software gegen die geforderten Spezifikationen testen.

Wasserfallmodell mit Blackbox aus Kundensicht. Der Kunde sieht nur was er spezifiziert hat und die entwickelte Software. Er ist aber nicht im Entwicklungsprozess mit eingebunden

Sollten hier Fehler gefunden werden, oder Spezifikationen falsch beurteilt worden sein, so entsteht ein Changerequest. Es ist dann ebenfalls zu klären wer die Kosten für diesen Changerequest trägt. So sitzen Auftraggeber und Auftragnehmer im Extremfall nicht im selben Boot und die Verantwortung für den aufgetretenen Zusatzaufwand wird hin und hergeschoben. Eine unharmonische und unkomfortable Situation entsteht.

Anders bei Scrum. Bei Scrum wird versucht Kommunikation über Dokumentation zu stellen. Anforderungen werden zwar erfasst, teilweises sogar detaillierter als beim Wasserfallmodellen. Die Anforderungen werden aber zielgerichteter in Zusammenarbeit mit dem Umsetzungsteam in sogenannten Product Backlog Items (=PBI) erfasst und nicht wie beim Wasserfallmodell monolithisch in einem Lastenheft gesammelt.

Scrum bietet aber noch weit mehr …

… hier gehts zu den Vorteilen von Scrum…

Create a website or blog at WordPress.com

Nach oben ↑

%d Bloggern gefällt das: