Innovation, Geschwindigkeit und Agilität in der Softwareentwicklung

Von Marko Javornik* |

Anbieter zum Thema

Agilität in den Entwicklungsprozessen hilft großen und kleinen Unternehmen, sich an sich ändernde Anforderungen anzupassen. Dieser Beitrag vergleicht agile Methoden mit dem traditionellen Wasserfall-Verfahren.

Mit Spaß zu mehr Zufriedenheit: Agile Entwicklungsmethoden sind gut dazu geeignet, die Kundenzufriedenheit zu steigern, da der Kunde eng in den Prozess eingebunden ist. Aber auch die Arbeitszufriedenheit im Entwicklerteam ist mit agilen Methoden meist höher.
Mit Spaß zu mehr Zufriedenheit: Agile Entwicklungsmethoden sind gut dazu geeignet, die Kundenzufriedenheit zu steigern, da der Kunde eng in den Prozess eingebunden ist. Aber auch die Arbeitszufriedenheit im Entwicklerteam ist mit agilen Methoden meist höher.
(Bild: Erik Žunec/Comtrade)

Das Geschäftsumfeld ist in den letzten Jahren sehr instabil und unvorhersehbar geworden. Aufgrund ihrer Größe, ihrer komplexen internen Prozesse und Richtlinien reagieren große Firmen nur langsam auf Veränderungen und geraten schnell in Schwierigkeiten. Kleine, flexible, agil organisierte Unternehmen, die Innovationen schneller umsetzen, überholen sie mit rasender Geschwindigkeit.

Anforderungen werden extrem schnell geändert, die Produkte werden immer besser und sind, wenn sie auf den Markt kommen, auf dem neuesten Stand der Technik. Große Unternehmen konkurrieren nicht mehr nur mit anderen großen Unternehmen, sie müssen auch besser sein als die kleineren Firmen. Wie schaffen sie das? Ständige Innovationen und eine agile Organisation sind der Schlüssel zum Erfolg. Agile Unternehmen können sich schnell anpassen und sind immer darauf vorbereitet, eine ganze Reihe von Änderungen innerhalb kurzer Zeit zu meistern.

Agile Methoden sind insbesondere für sehr komplexe Projekte und Projekte geeignet, bei denen sich der Umfang während der Laufzeit verändert (oder am Anfang nicht exakt definiert werden kann). Heute sind solche Projekte immer häufiger, weil wir uns auf dem Weg in eine auf komplexer Technologie basierenden Welt befinden, die sich anders verhält als die physikalische, an die wir gewohnt sind. Veränderungen passieren schneller; sie haben einen größeren Einfluss und sind weniger vorhersehbar. Darunter leiden viele Projekte, die auf einem klassischen Ansatz beruhen.

Die Embedded-Software-Entwicklung hat einige Besonderheiten, aber letztendlich ist auch sie ein Segment der Software-Entwicklung. Ihre Abhängigkeit von Hardware bringt einige Schwierigkeiten mit sich, doch das sind lösbare Probleme. Herkömmlich benutzen viele auf Embedded spezialisierte Unternehmen das Wasserfallmodell mit der Begründung simultan Hardware und Software zu entwickeln. In der heutigen Welt mit Hardware-Simulationen und VHDL-Sprachen wird auch die Hardware-Entwicklung rasch beschleunigt. Wegen der schnellen Hardware-Entwicklung können agile Methoden auch in der Embedded-Software-Branche angewendet werden.

Das Wasserfallmodell versus agile Methoden

Wir können drei allgemeine Unterschiede zwischen dem Wasserfallmodell und den agilen Methoden festlegen und zwar im Bereich der Kundeneinbindung, der Zusammenarbeit des Entwicklungsteams und der Kundenzufriedenheit.

Beim Wasserfallmodell ist die Einbeziehung von Kunden während der Entwicklung üblicherweise nicht erforderlich. Sie werden nur ab der Betatest-Phase einbezogen, während sie bei den agilen Methoden schon von Anfang an beteiligt sind – bei regelmäßigen Sprint-Review-Treffen/Demo-Sitzungen, bei denen über den Fortschritt berichtet wird und gleichzeitig der Projektfortschritt gezeigt wird.

Das Wasserfallmodell erfordert weniger Zusammenarbeit im Entwicklungsteam; die Interaktion ist meist sehr formell und erfolgt über Dokumentation und Memos. Wenn das Projekt agil bearbeitet wird, arbeiten die Mitglieder informell und oft miteinander. Tägliche Besprechungen sind die Regel, Code-Reviews sind obligatorisch, Diskussionen und Brainstorming finden je nach Bedarf statt. Es gibt eine enge Zusammenarbeit zwischen den Entwicklungsteams.

Die Embedded-Software-Entwicklung hat einige Besonderheiten – unter anderem ihre Abhängigkeit von der Hardware –, aber letztlich ist auch sie ein Segment der Software-Entwicklung. Daher können agile Methoden durchaus in der Embedded-Software-Branche angewendet werden.
Die Embedded-Software-Entwicklung hat einige Besonderheiten – unter anderem ihre Abhängigkeit von der Hardware –, aber letztlich ist auch sie ein Segment der Software-Entwicklung. Daher können agile Methoden durchaus in der Embedded-Software-Branche angewendet werden.
(Bild: Erik Žunec/Comtrade)

Die geschilderten Unterschiede spiegeln sich ebenfalls in der Zufriedenheit der Kunden wider. Beim Wasserfallmodell ist erfahrungsgemäß die Kundenzufriedenheit zuerst sehr hoch und beginnt am Ende des Projekts abzuklingen, während bei agilen Methoden die konstante Kundenzufriedenheit durch häufige Bereitstellung von funktionsfähigen Produkten und durch schnelle Anpassungen an geänderte Anforderungen erzielt wird.

Das Wasserfallmodell und die agilen Methoden unterscheiden sich auch durch die verschiedenen Projektphasen.

  • Planung: Beim Wasserfallmodell sind die Projekte durch einen fixen Zeitraum, ein fixes Budget und durch fixe Eigenschaften definiert, beim agilen Modell kann nur eine Sachen fix sein – entweder der Zeitraum, das Budget oder die Eigenschaften. Gibt es beispielsweise ein Abgabedatum, dann muss der Projektumfang sehr flexibel sein. Während des Projekts sind Umplanungen die Regel.
  • Anfängliche Projektdokumentation: Das Wasserfallmodell erfordert eine umfangreiche Dokumentation, die mit viel Aufwand verbunden ist und normalerweise im weiteren Verlauf geändert werden muss, während beim agilen Modell das Entwicklungsteam mit minimaler Dokumentation anfängt – gerade genug, um das Projekt zu starten. Lediglich die hohen Anforderungen werden zu Beginn festgelegt.
  • Anforderungen: Beim Wasserfallmodell sind alle Anforderungen im Voraus definiert und können später nur mit großem Aufwand geändert werden, während beim agilen Modell die Eigenschaften des Produkts im Backlog definiert und während der Sprints entwickelt werden. Anforderungen werden je nach Bedarf hinzugefügt oder verändert. Kunden müssen sich an der Sprint-Planung aktiv beteiligen und die Prioritäten regelmäßig im Backlog updaten.
  • Änderungen und Änderungsanforderungen: Im Vergleich zum agilen Modell erfordert das Wasserfallmodell hohen Verwaltungs- und Verhandlungsaufwand. Beim agilen Model werden Änderungen erwartet und können bei jedem neuen Sprint problemlos eingeführt werden.
  • Entwicklung und Integration von HW / SW / FW: Die Entwicklung beim Wasserfallmodell besteht aus einer langen monolithischen Phase, bei der Änderungen nicht erwartet werden. Danach folgt eine Integrationsphase. Beim agilen Modell findet die Entwicklung und Integration gleichzeitig statt mit notwendiger Unterstützung von automatischen Überprüfungen. Die Entwicklung und Integration werden in funktionalen Vertikalen ausgeführt, von Sprint zu Sprint.
  • Überprüfung: Die Überprüfung findet beim Wasserfallmodell in einer eigenständigen Phase, normalerweise nach der Entwicklung statt, während beim agilen Modell eine kontinuierliche Integration und kontinuierliche Regressionstests ausgeführt werden, die durch automatisierte Builds und ein automatisches Prüfsystem unterstützt werden. Es ist sehr empfehlenswert, dass speziell für den Zweck des automatischen Prüfens eine maßgefertigte HW entwickelt wird.
  • Qualitätszusicherung/Programmfehlerquote: Üblicherweise ist beim Wasserfallmodell während der Testphase die Programmfehlerquote sehr hoch. Wegen der Komplexität des Codes, der noch nie getestet wurde, beansprucht die Behebung von Programmfehler sehr viel Zeit. Beim agilen Modell werden die meisten Programmfehler durch die Regressionstests entdeckt und bereits während der Entwicklungsphase behoben. Somit wird schon vor der letzten Testphase eine hohe Produktqualität garantiert.

Agilität erhöht die Kundenzufriedenheit

Bei richtiger Anwendung erhöhen agile Methoden die Kundenzufriedenheit. Der Aufwand, die richtigen Entscheidungen, zu treffen ist höher, und mehr Gedanken und Energie fließen in den Wunsch ein, dem Kunden das zu geben, was er will. Kurz - die Bereitschaft auf Änderungen zu reagieren, wird erhöht und führt in der Folge zu größerer Zufriedenheit. Zuerst könnte es sich ein wenig unbequem anfühlen, da es keinen ausführlichen Hauptplan mit detaillierter Aufgliederung der Aufgaben und entsprechenden Schätzungen gibt.

Jetzt Newsletter abonnieren

Verpassen Sie nicht unsere besten Inhalte

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung.

Aufklappen für Details zu Ihrer Einwilligung

Doch man sollte wissen, dass genaue Schätzungen für komplexe Projekte oft sehr unzuverlässig sind, weil sie auf vielen, möglicherweise auch falschen, Vermutungen basieren. Genau diese auf falschen Vermutungen basierenden Aktivitäten können sehr verheerend sein. Deshalb begrüßt und schätzt man Methoden, die die Komplexität erkennen und sich durch iteratives Denken mit ihr befassen. Damit sinkt auch die Wahrscheinlichkeit, dass Änderungen langfristig in die falsche Richtung gehen.

Die Bereitschaft, auf Änderungen zu reagieren, die Flexibilität und Innovation sichern nicht nur das Überleben, sondern helfen Unternehmen, besser zu werden und verschaffen ihnen einen entscheidenden Wettbewerbsvorteil.

* Marko Javornik ist Director of International Services beim Systemhaus Comtrade mit Sitz in Ljubljana/Slowenien.

(ID:46495098)