Direkt zum Inhalt wechseln

Agile vs. klassische Softwareentwicklung

Das passende Vorgehensmodell für Ihr Projekt

von DI (FH) Andreas Lettner

Klassische Ansätze wie beispielsweise Wasserfall, V-Modell oder Spiralmodell oder agile Ansätze wie zum Beispiel Scrum oder Kanban? Zu Projektbeginn stellt sich die Frage, welches der existierenden Vorgehensmodelle wohl am Besten für das aktuelle Vorhaben geeignet ist. Die RISC Software GmbH greift auf langjährige Erfahrung mit verschiedenen Vorgehensmodellen zurück und berät ihre Kund*innen zu Beginn eines Projektes, welches Vorgehensmodell zu empfehlen ist.

Inhalt

  • Veränderungen
  • Feedback
  • Komplexität
  • Fazit
  • Quellen
  • Autor
Development

Veränderungen

Klassische Vorgehensmodelle verfolgen einen linearen Ansatz, wo von Anfang an auf einen definierten Endzustand hingearbeitet wird. Hierbei passiert das Projekt verschiedene Phasen in sequenzieller Abfolge. Die Phasen werden üblicherweise durch Meilensteine abgeschlossen. Aufgrund der starren Übergänge und Abfolge der Phasen wird möglichst vermieden, neue Anforderungen oder eine Veränderung von Anforderungen in ein Projekt einzubringen. Dies ist meist mit den budgetierten und zeitlichen Zielen nicht vereinbar.

Agile Vorgehensweisen setzen anstelle dieser sequenziellen Abfolge auf ein iterativ-inkrementelles Modell. Iterativ bedeutet, dass die Produktentwicklung in Zyklen geschieht, während inkrementell bedeutet, dass bei jedem Zyklus ein potentiell nutzbares Produktinkrement entsteht. Dies hat zur Folge, dass notwendige Planabweichungen frühzeitig erkannt werden können.

Klassische und agile Vorgehensweise

Feedback

Das Erkennen der Notwendigkeit von konkreten Veränderungen stellt jedes Projektteam vor eine Herausforderung. In klassischen Vorgehensmodellen geschieht dies bestenfalls bei den Meilensteinen, also zwischen zwei Phasen – schlimmstenfalls erst zu Projektende. Bei agilen Vorgehensweisen beinhaltet jede Iteration das zeitnahe Feedback der Kund*innen, wodurch vermieden wird, dass das Endprodukt nicht den Marktanforderungen genügt.

Feedback

Komplexität

Projekte scheitern aufgrund der Fehleinschätzung ihrer Komplexität. Die Definition von Komplexität gem. Cynefin-Framework (2) ergibt sich daraus, dass der Zusammenhang zwischen Ursache und Wirkung nicht im Voraus vorhersagbar ist. Komplexe Systeme benötigen ermergente Praktiken, um ein Produktziel zu erreichen. Im Gegensatz dazu stehen komplizierte Systeme, bei denen, mit der entsprechenden Wissensbasis, der Zusammenhang zwischen Ursache und Wirkung vorhersagbar ist. Somit können komplizierte Systeme bzw. Produkte durchaus im Voraus geplant werden. Agile Vorgehensweisen beruhen in ihren Prinzipien auf emergenter Produktentwicklung und fördern durch ihre iterativ-inkrementellen Praktiken die Verminderung der Komplexität.

Planbar vs Emergent

Fazit

Beide Ansätze – die klassischen und die agilen – haben ihre jeweiligen Vorteile. Letztendlich beruht die Einschätzung, welches Vorgehensmodell das geeignete ist, auf der Erfahrung beider Partner – den Auftraggeber*innen und den Umsetzungspartner*innen. Dennoch können folgende Grundregeln für eine Entscheidungsfindung herangezogen werden:

Projekte, die in einer kurzen Zeit mit kleinen Teams realisiert werden können und sich in einem klar definierten Kontext bewegen, sind ggf. geeignet für klassische Vorgehensmodelle. Auch bei einer klassischen Vorgehensweise arbeitet die RISC Software GmbH nach den agilen Werten und ergänzt üblicherweise die Projektprozesse durch agile Praktiken. Vor allem rege und kontinuierliche Kommunikation mit den Kund*innen ist ein Grundsatz, der nie vernachlässigt wird.

Für alle anderen Projekte empfehlen sich agile Vorgehensweisen. Die Lenkung der Produktentwicklung und die Verminderung der Komplexität sind elementare Prinzipien der agilen Werte und auch langfristige Projekte mit mehreren Teams können durch Skalierungstechniken koordiniert werden.

Ein Spezialist*innenteam der RISC Software GmbH berät ihre Kunden bereits bei der Projektanbahnung individuell bzgl. der möglichen Vorgehensmodelle und verfolgt auch noch laufend während er Projektumsetzung die Ergebnisse um rechtzeitig ggf. notwendige Anpassungen am Vorgehensmodell mit den Kund*innen vornehmen zu können.

Entwicklung

Kontakt









    Autor

    DI (FH) Andreas Lettner

    Head of Unit Domain-Specific Applications, Head of Coaches

    Quellen

    (1) https://www.standishgroup.com/

    (2) D. Snowden. (2000) “Cynefin, A Sense of Time and Place: an Ecological Approach to Sense Making and Learning in Formal and Informal Communities”

    This site is registered on wpml.org as a development site.