Traditionell oder agil oder beides?

Ein Vergleich traditioneller und agiler Entwicklungsmodelle

In meiner Tätigkeit als Berater für Softwarequalität ist es mir schon mehrfach begegnet, dass gerade in heißen Phasen traditioneller Projekte die Idee aufkommt, dass man agil entwickeln könne. Darunter wird dann meist verstanden, dass man auf die Dokumentation notwendiger Änderungen verzichtet oder deren Erstellung auf die Zeit nach der Produktivnahme verschiebt. Ob diese Nachdokumentation dann auch tatsächlich erfolgt, ist noch mal ein ganz anderes Thema. Die Änderungen werden nur zwischen dem Entwicklungsteam und dem Fachbereich abgestimmt und basierend auf diesen Absprachen wird die Umsetzung der Änderungen durchgeführt. Bei diesen Absprachen ist das Testteam jedoch selten beteiligt, was unter anderem dazu führt, dass Testfälle veraltet sind. Dies wiederum hat zur Folge, dass viele Abweichungen im Test gefunden werden, die mit hohem Zeitaufwand aller Beteiligten analysiert werden müssen. In der Analyse wird dann fest gestellt, dass das Verhalten der Software den abgesprochenen Änderungen entspricht. Der gewonnene Zeitvorteil durch den Verzicht auf Dokumentation wird durch den Analyseaufwand der Abweichungen häufig wieder aufgehoben. Weiterhin kann die vernachlässigte Dokumentation im operativen Betrieb und in der Wartung der Software zu Problemen führen.

An dieser Stelle soll versucht werden beide Ansätze miteinander zu vergleichen, um so Stärken und Schwächen beider Modelle aufzuzeigen.

Stellvertretende Modelle

Traditionelles Modell „Wasserfall“

Das am weitesten verbreitete traditionelle Modell ist der sogenannte „Wasserfall“. Daher wurde dieses Modell als Stellvertreter für die traditionellen Ansätze gewählt. Zur Erläuterung soll eine vereinfachte und grobe Darstellung des Modells wiedergegeben werden.In diesem Modell werden die einzelnen Phasen sequentiell abgearbeitet.

traditionell oder agil

Am Anfang steht die Definition dessen, was die Software können soll. Aufbauend auf diesen Anforderungen wird die Architektur der Software festgelegt. Man könnte also sagen, dass der Konstruktionsplan erstellt wird. Nachdem dieser fertig gestellt ist, erfolgt die Umsetzung im Code, der an die Qualitätssicherung zum Test übergeben wird.

Die Idee dahinter ist, dass man sich auf eine Aufgabe konzentriert und Probleme identifiziert sowie löst, bevor diese im Code umgesetzt werden. Leider ist es in der Realität jedoch so, dass sich Anforderungen jederzeit im Projektverlauf ändern können, was Auswirkungen bis auf die Architektur haben kann.

Agiles Modell „Scrum“

Als Stellvertreter für die agilen Modelle fiel die Wahl auf Scrum, da es das Modell ist, was derzeit wohl am häufigsten zum Einsatz kommt. Auch für dieses Modell soll hier eine vereinfachte Erklärung gezeigt werden.

traditionell oder agil

In Scrum werden die Anforderungen im sogenannten Product Backlog gesammelt. Das Product Backlog ist jedoch kein vollständiges Anforderungsdokument, sondern eine formlose Sammlung dessen, was die Software können soll. Aus diesem Pool von Anforderungen werden für alle Iterationen, die Sprint genannt werden und in der Regel zwei bis vier Wochen dauern, Anforderungen ausgewählt und in den sogenannten Sprint Backlog verschoben. Innerhalb eines Sprints wird dann die Software für die ausgewählten Anforderungen im Sprint Backlog geplant, konstruiert, codiert und getestet. Ziel jedes Sprints ist es, am Ende lauffähige Software zu haben, welche die gewählten Anforderungen sowie alle bereits vorher umgesetzten Anforderungen erfüllt. Anforderungen, die noch nicht im Sprint Backlog sind, können jederzeit geändert werden, ohne dass dies Auswirkungen auf die laufende Entwicklung hat. Ergibt es sich, dass Änderungen an bereits umgesetzten Anforderungen gewünscht sind, so werden diese Änderungen als eigene Anforderungen in den Product Backlog aufgenommen und je nach aktueller Priorisierung in das Sprint Backlog für den nächsten Sprint übernommen oder auch nicht.

Schematischer Projektverlauf beider Modelle

Stellt man den Projektverlauf für beide Modelle auf der Zeitachse dar, ergibt sich folgendes vereinfachtes Bild (s. Abb. 3). Im Zeitstrahl für Scrum stehen dabei die Farben für die vergleichbaren Aktivitäten wie im Wasserfall.

traditionell oder agil

Gemeinsamkeiten der Modelle

Zur besseren Differenzierung der beiden Ansätze sollen zuerst einige Gemeinsamkeiten dargestellt werden.

Beide haben das Ziel, Software zu erstellen, die ihre Aufgabe erfüllt. Weitere Gemeinsamkeiten sind, dass es in beiden Modellen Vorgehensregeln gibt. In beiden Modellen kommt ein Team aus Menschen mit unterschiedlichen Persönlichkeiten, Kenntnissen und Fähigkeiten zum Einsatz. Weiterhin wird vor der Umsetzung festgelegt, welche Charakteristik die Software haben soll. In beiden Ansätzen wird eine Softwarearchitektur entworfen und es wird Code geschrieben und getestet. Schlussendlich wird ein Softwarepaket erstellt, das in Produktion geht.

Unterschiede der Modelle

Nachdem einige Gemeinsamkeiten aufgezeigt wurden, soll nun auf Unterschiede eingegangen werden, wobei kein Anspruch auf Vollständigkeit vorliegt.Wie bereits aufgeführt arbeitet das Wasserfallmodell sequentiell. Das heißt, dass eine Phase nach der anderen abgearbeitet wird, auch wenn in der Praxis meist Überlappungen der einzelnen Phasen zu beobachten sind. Im Gegensatz dazu ist Scrum iterativ. Man könnte das Vorgehen auch so beschreiben, dass das Projekt in viele kleine Miniprojekte zerlegt wird, die nacheinander abgearbeitet werden, um am Ende zu einem Gesamtergebnis zu kommen.

Ein weiterer Unterschied, der bei der Auswahl des genutzten Modells nicht vernachlässigt werden sollte, liegt darin, dass mit dem Wasserfall sehr viele Erfahrungen bei den meisten Mitarbeitern vorliegen, wohingegen mit agilen Vorgehensmodellen bei vielen Mitarbeitern noch keine oder wenige Erfahrungen vorhanden sind. Wenn man mit einem Team ohne die entsprechenden Erfahrungen auf agile Vorgehensweisen umsteigt, ist in der Übergangsphase häufig mit zusätzlichem Lernaufwand und Reibungsverlusten zu rechnen.

Die Aufgabenverteilung unterscheidet sich ebenfalls. In traditionellen Modellen kommen klare Rollen und Verantwortlichkeiten zum Einsatz, wohingegen agile Vorgehensweisen auf das Team und Kommunikation setzen. Gerade für das Management ist dies ein schwieriger Punkt, da nun nicht mehr Einzelpersonen zur Verantwortung gezogen werden können, sondern die Verantwortung auf das Team verteilt ist. Auch Mitarbeiter können sich schwer damit tun, wenn die Verantwortung nicht mehr bei einem Vorgesetzten liegt. Weiterhin kann es für Mitarbeiter eine große Herausforderung sein, wenn es keine klare Anweisungen gibt, die auf im Voraus festgelegten Plänen und Prioritäten basieren, und sie stattdessen einen Teil der Verantwortung selber tragen und gemeinsam im Team entscheiden müssen, wie vorgegangen werden soll, um dynamisch auf Veränderungen zu reagieren. Gleichzeitig ist es aber für viele Mitarbeiter ein Motivator, wenn sie selbst die Verantwortung tragen und über das Vorgehen entscheiden können.

Im Zusammenhang mit der oben beschriebenen Rollenverteilung steht, dass traditionelle Ansätze eher plan- und prozessorientiert sind, wohingegen agile Methoden eher Ziele und individuelle Fähigkeiten in den Fokus stellen. Es ist also nicht die Frage, wer für eine Aufgabe zuständig ist, sondern wer sie unter den gegebenen Umständen am besten kann.

In der Projektplanung liegt ebenfalls ein großer Unterschied. Traditionelle Modelle arbeiten mit definierten Phasen und festen Zielen pro Phase, die normalerweise sehr früh im Projektverlauf festgelegt werden. Die Umsetzung erfolgt dann nach Plan. Dies führt in der Praxis häufig zu sehr unterschiedlichen Arbeitsbelastungen der Mitarbeiter. Agile Ansätze bieten im Vergleich dazu eine gleichmäßigere Arbeitsauslastung. In Scrum wird dies dadurch erreich, dass für jeden Sprint nur so viel in den Sprint Backlog übernommen wird, dass das Ziel lauffähige Software erreicht werden kann. Die Auswahl, welche Anforderungen umgesetzt werden, erfolgt dabei nach den aktuellen Bedürfnissen des Kunden oder der User und nicht nach einem im Voraus festgelegten Plan. Der Kunde oder User ist viel stärker in die Entwicklung involviert, als dies bei traditionellen Ansätzen der Fall ist.

Ein weiterer großer Unterschied liegt in der Dokumentation. In Projekten, die nach dem Wasserfall arbeiten, wird vorab sehr viel Zeit in die formale Dokumentation investiert – häufig sogar in den Stil der Dokumentation, damit diese für den Auftraggeber oder Abnehmerkreis möglichst angenehm zu lesen ist. Dies kann so weit gehen, dass ein nicht zu vernachlässigender Teil des Zeitaufwandes in diesen Punkt investiert wird. Der Autor war in Projekten involviert, wo etwa zwei Drittel des Zeitaufwandes für die Dokumentation zum Optimieren der Texte aufgewendet wurde und nur etwa ein Drittel für die Erstellung der relevanten Inhalte. Dabei ging es jedoch nicht um eine Optimierung für die Verwendung in der Entwicklung und im Test, sondern rein um stilistische Optimierungen mit dem Ziel, „schönere Prosa“ zu erstellen. Agile Modelle wie Scrum nutzen einen wesentlich schlankeren Ansatz und erstellen nur das an Dokumentation, was wirklich benötigt wird. Häufig erfolgt die Dokumentation sogar parallel zur Entwicklung. Dabei wird selten „Prosa“ erzeugt. Stattdessen kommen kurze, aber prägnante Darstellungen der Anforderungen oder Charakteristik zum Einsatz.

Weiterhin unterscheiden sich die Modelle in der Erstellung der Architektur. In den traditionellen Modellen sind theoretisch alle, auch nicht-funktionale, Anforderungen bekannt, so dass die Architektur bereits mit Blick auf den gesamten Leistungsumfang entworfen werden kann. Bei den agilen Modellen ist dies nicht möglich, da noch nicht alle Anforderungen bekannt sind. Dies ist eine große Herausforderung für die Architekten, denn ihre Architektur muss flexibel und leistungsfähig genug sein, die erst später formulierten Anforderungen zu unterstützen.

Bei der Programmierung gibt es ebenfalls Unterschiede. In traditionellen Modellen erfolgt die erste Lieferung von testbarem Code relativ spät im Projekt. Der Test erfolgt häufig in wenigen Phasen und Zyklen, und dies mit hohem manuellem Aufwand. In agilen Projekten hingegen ist es das Ziel, nach jedem Sprint lauffähige Software zu haben, deren Funktionsumfang mit jeder Iteration wächst. Aufgrund der kurzen Sprintdauer wird die Software sehr häufig, teilweise bis zu mehrfach täglich gebaut. Jeder neue Build wird anschließend in der Regel automatisiert getestet. Insbesondere in der Anfangsphase oder in Sprints, in denen viele grundlegende Änderungen durchgeführt werden, kann dies zu hohem Aufwand für die Pflege der automatisierten Testfälle führen.

Fazit

Beide Ansätze haben Stärken und Schwächen. Beide können erfolgreich sein oder scheitern. Somit sollte die Frage nicht lauten, ob nach einem agilen oder traditionellem Ansatz entwickelt werden soll. Stattdessen sollte das passende Modell für Umfeld, Unternehmen, Aufgabe und Team ermittelt werden. Es ist unerheblich, ob dies Scrum, Wasserfall, ein weiteres agiles oder traditionelles Modell oder auch ein eigenes Modell, das Eigenschaften von agilen und traditionellen Ansätzen vereint, ist. Wichtig ist lediglich, dass das gewählte Vorgehen den eigenen Anforderungen an die Entwicklung gerecht wird.

Weitere Artikel vom testing experience Magazin

Wie kann Crowdtesting den agilen Entwicklungsprozess unterstützen?
von Jan Wolter & Jannis Reuter

Autisten als Softwaretester und IT-Spezialisten

Jenny Siotka

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Kategorien

Recent Posts