Methodik in der Softwareentwicklung: Agil versus Wasserfall

In der Softwareentwicklung gilt das Wasserfallmodell heute fast als verpönt und antiquiert. Es gibt aber durchaus Verbindungen zu agilen Methodiken. [...]

Keine Softwaremethodik ist per se gut oder schlecht. Vielmehr muss es stets darum gehen, die richtige Methodik für das richtige Produkt und die gegebenen Rahmenbedingungen auszuwählen (c) pixabay.com

Agilität ist ein Schlagwort, das fast alle Unternehmen erfasst hat. Auf Entscheiderebene gewinnt das Thema Business Agility, also die agile Arbeitsweise eines Unternehmens, beständig an Bedeutung. In der Folge versuchen Unternehmen, ihre Innovations- und Anpassungsgeschwindigkeit mit Hilfe entsprechender Initiativen signifikant zu erhöhen – besonders in der Softwareentwicklung. Gegen Entwicklungen im stillen Kämmerlein und fernab der Auftrag gebenden Fachabteilung soll auch hier die Agilität Abhilfe schaffen. Bevor Projektleiter aber blindlings auf die Versprechungen von Scrum und Kanban vertrauen, ist es wichtig, die Ideen hinter den Methoden zu verstehen und auf das Unternehmen anzupassen.

Seit Beginn der modernen Softwareentwicklung gibt es verschiedene Vorgehensweisen, um Software zu erstellen. Die bekanntesten und in den letzten zehn Jahren am weitesten verbreiten Methoden sind:

  • Wasserfall, das heißt die Entwicklung von Software sukzessiv in Stufen mit Rückkopplung.
  • Das V-Modell, das die Integration der Aspekte der Qualitätssicherung in das Wasserfallmodell beinhaltet.
  • Evolutionäre oder inkrementelle Modelle, also die stufenweise Entwicklung des Softwareproduktes und
  • als Weiterentwicklung daraus die heutigen gängigen agilen Methoden wie beispielsweise Scrum.

Mittlerweile geht der Trend ganz klar zu agil als De-facto-Standard, um moderne Software zu bauen, wobei Scrum und Kanban als verwendeten Methoden dominieren.

Ein Grund für diese Entwicklung ist in der Geschwindigkeit zu sehen, mit der neue Geschäftsmodelle sowie Produkte und Services auf die Märkte kommen.

Ein Blick auf die Fortune-500-Unternehmen zeigt die Auswirkungen der Marktveränderungen auf Unternehmen und die Notwendigkeit, sich anpassen zu können. Und das in immer kürzeren Zyklen, um am Markt zu bestehen. Vielfach dominieren Digital Natives den Markt und haben ihn durch moderne Arbeitsmodelle erobert. Diese Companies bringen Innovationen in viel schnelleren Intervallen Zyklen auf den Markt als viele der etablierten deutschen Betriebe.

Wasserfall als Schimpfwort

Vor diesem Hintergrund gilt „Wasserfall“ schon beinahe als Schimpfwort und als Zeichen, dass Unternehmen, die diese Methode der Softwareentwicklung noch anwenden, noch nicht in der Neuzeit angekommen sind. Hierbei ist jedoch zu beachten:

1. Keine Softwaremethodik ist per se gut oder schlecht. Vielmehr muss es stets darum gehen, die richtige Methodik für das richtige Produkt und die gegebenen Rahmenbedingungen auszuwählen. Das war schon immer so. Leider ist es häufig der Fall, dass tiefgehendes Wissen über die verschiedenen Methodiken und deren Umsetzung nicht vorhanden ist. Zudem scheint die Hoffnung auf die „eine Methodik“, die alles löst, zu unerwünschten Vereinfachungen zu führen.

2. Wasserfall wird heutzutage gerne wie folgt verbal beschrieben: „Monatelang werden Anforderungen erfasst, danach monatelang die Software gebaut und danach erst sieht die Fachabteilung die Software im Rahmen des Tests.“ In diesem Szenario, so die Kritik, würden die Fachabteilungen die Software viel zu spät präsentiert bekommen, Änderungen wären sehr teuer und Flexibilität sei nicht wirklich vorhanden. Vor diesem Hintergrund lohnt es sich nachzulesen, was die Wasserfallmethodik wirklich aussagt.

1970 veröffentlichte Winston W. Royce sein Paper „Managing the development of large software systems“, er gilt damit als einer der Begründer der Wasserfallmethodik. Bei der Lektüre fällt auf: Dokumentation ist für Royce ein absoluter Schlüsselfaktor in der Entwicklung von Software. Dies scheint konträr zur heutigen AgilMethodik zu sein. Hier ist aber Folgendes zu bedenken:

  • Zum einen spricht das bekannte Agile Manifesto nicht davon, keine Dokumentation zu benötigen, sondern gewichtet „Working Software“ einfach höher als „Comprehensive Documentation“.
  • Zum anderen hängt der notwendige Dokumentationsgrad auch immer von der Art des zu entwickelnden Systems ab.

Royce beschäftigte sich in seiner Arbeit mit der Erstellung von Software für die Planung, Durchführung und Analyse von Raumfahrtmissionen. Man kann sich vorstellen, dass derartige Systeme einen sehr hohen Grad an Dokumentation erfordern.

Beachtlich ist ferner, dass Royce damals schon die Risiken seiner Wasserfallmethodik erkannte und in seinem Paper auch vorschlägt, wie dieses Risiko minimiert werden kann, nämlich durch die

  • Erstellung einer Vision und eines initialen Designs des zu erreichenden Zielproduktes zu Projektbeginn,
  • Erstellung eines frühen Prototyps im Sinne von lauffähiger Software, der ständig weiterentwickelt wird, und
  • Einbeziehung des Endkunden in jede Phase des Entwicklungsprozesses.
  • All diese Dinge würde man heute eher dem Lager der „Agilisten“ zuschreiben.

Außerdem ist zu berücksichtigen, dass viele der Konzepte, die hinter den agilen Ansätzen von heute stehen, nicht notwendigerweise neu sind. Zur Hochzeit des Mainframes interagierten die Entwickler in der Regel direkt mit den Fachabteilungen und wurden neue Produktversionen in kleinen Zyklen live geschaltet. Leider wurden im Zeitalter von Industrialisierung und CMMI jedoch zahlreiche hierarchische Strukturen und Prozesse eingeführt, die den Entwickler immer weiter vom Endanwender entfernt haben.

Agile Prinzipien

Um es klar zu sagen: Die agilen Prinzipien sind für Unternehmen in der heutigen Zeit unabdingbar. Das Zeitalter der industrialisierten Softwareentwicklung hat zu vielen Auswüchsen geführt, welche durch die agile Bewegung korrigiert wurden. Das ist elementar, richtig und eine Grundvoraussetzung, um das eigentliche Thema – nämlich das Unternehmen in der Gesamtheit „agiler“ zu machen – umzusetzen und die eigene Innovationsgeschwindigkeit signifikant zu erhöhen.

Sie sehen gerade einen Platzhalterinhalt von YouTube. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.

Mehr Informationen

Es ist jedoch wichtig, hier nicht in die Falle zu tappen und einer Methodik wie Scrum oder SAFe blind zu vertrauen. Viel entscheidender als die Methodik sind die Prinzipen dahinter, diese zu verstehen und die Methodiken mit erfahrenen Leuten an die eigene Situation anpassen. Und eine agile Softwareentwicklung wiederum ist nur ein kleiner Baustein hin zu einem wirklichen agilen Unternehmen.

*Jochen Malinowski ist bei Accenture Geschäftsführer für den Bereich New IT und Experte darin, wie sich Unternehmen „lean“ und „agil“ aufstellen können. Er leitet außerdem die Plattform Intelligent Engineering Services (IES) sowie das Master Technology Architect (MTA) Programm von Accenture.


Mehr Artikel

News

UBIT Security-Talk: Cyberkriminalität wächst unaufhaltsam

Jedes Unternehmen, das IT-Systeme nutzt, ist potenziell gefährdet Opfer von Cyberkriminalität zu werden, denn die Bedrohung und die Anzahl der Hackerangriffe in Österreich nimmt stetig zu. Die Experts Group IT-Security der Wirtschaftskammer Salzburg lädt am 11. November 2024 zum „UBIT Security-Talk Cyber Defense“ ein, um Unternehmen in Salzburg zu unterstützen, sich besser gegen diese Bedrohungen zu wappnen. […]

News

Jahrelanges Katz-und-Maus-Spiel zwischen Hackern und Verteidigern

Sophos hat den umfangreichen Forschungsbericht „Pacific Rim“ veröffentlicht, der detailliert ein jahrelanges Katz-und-Maus-Spiel aus Angriffs- und Verteidigungsoperationen mit mehreren staatlich unterstützten Cybercrime-Gruppierungen aus China beschreibt. Im Lauf der Auseinandersetzung entdeckte Sophos ein riesiges, gegnerisches Cybercrime-Ökosystem. […]

Be the first to comment

Leave a Reply

Your email address will not be published.


*