© Ekaphon maneechot/Shutterstock.com
Wann lohnt sich agile Softwareentwicklung, und wie geht es besser?

Agilität - Wie dynamisch sind Sie?


Agile Softwareentwicklung hat einen beispiellosen Siegeszug hinter sich. Scrum hat Wasserfall als den Standardprozess abgelöst. Mittlerweile setzt aber Ernüchterung ein – und es wird auch zunehmend Kritik laut. Dieser Artikel zeigt auf, wo Agilität angebracht ist und welche Auswirkungen agile Softwareentwicklung auf das Geschäft hat – und wie sich auch das Geschäft ändern muss.

Ein mittlerweile typisches Beispiel für einen agilen Prozess ist Scrum [1] (Abb. 1):

  • Im Product Backlog wird alles aufgenommen, was für das zu entwickelnde Produkt relevant ist. Dazu zählen Features oder auch nicht funktionale Anforderungen.

  • Aus dem Product Backlog werden die Elemente in das Sprint Backlog übernommen, die im nächsten Sprint bearbeitet werden sollen.

  • Ein solcher Sprint dauert typischerweise zwei bis vier Wochen. In dieser Zeit wird das Sprint Backlog bearbeitet.

  • Während des Sprints werden in täglichen Scrum-Meetings die aktuellen Aufgaben und Herausforderungen besprochen.

Am Ende des Sprints wird ein auslieferbares Produktinkrement geliefert. Die Software könnte also installiert werden und ist ablauffähig. Oft wird sie dem Kunden aber lediglich in einem Review vorgestellt.

wolff_agilitaet_1.tif_fmt1.jpgAbb. 1: Scrum als agiler Prozess

Warum ist diese Vorgehensweise nun sinnvoll? Ein Grund ist Feedback. Die Software kann bereits genutzt werden, und so kann das Feedback aus der Nutzungserfahrung direkt in die weitere Entwicklung einfließen. Wenn beispielsweise neue Software für ein E-Commerce-System implementiert werden soll, kann zunächst eine verbesserte Produktsuche, eine Unterstützung für Expressbestellungen und schließlich eine Funktion zum Empfehlen von Produkten geplant werden. Nehmen wir an, dass in einem Sprint die Produktsuche implementiert wird und diese Suche im Shop einen großen Erfolg hat. Dann kann zunächst eine weitere Verbesserung der Suche umgesetzt werden, statt die beiden anderen Features zu implementieren. Ebenso können völlig neue Ideen eingeplant werden, denn oft entstehen Ideen erst, wenn der Kunde das Feature in Produktion sieht – gleiches gilt beispielsweise für Features, die Mitwettbewerber an den Markt gebracht haben. Anforderungen sind eben nie stabil. Daher sind schnelles Feedback und die Möglichkeit, den Plan zu ändern, sehr wichtig.

Ein weiterer Vorteil von agilen Ansätzen ist, dass der Fortschritt des Projekts sehr gut nachvollziehbar ist. Während eines Sprints kann die Abschätzung, wie viel Arbeit noch getan werden muss, mit der tatsächlich verfügbaren Zeit abgeglichen werden. Außerdem wird am Ende jedes Sprints Software ausgeliefert. Dadurch ist jederzeit klar erkennbar, welche Funktionalitäten tatsächlich schon implementiert sind und in Produktion gehen können. Es ist ausgeschlossen, dass es zu Überraschungen kommt, bei denen am Ende der Projektlaufzeit viel zu wenig tatsächlich implementiert worden ist. Auf diese Weise kann das Risiko minimiert werden. Zudem kann die Software bereits frühzeitig ausgeliefert werden. Dadurch ergibt sich nicht nur ein Marktvorteil, sondern die Software kann auch früher ihre Funktion erfüllen und so Wert generieren – sie beginnt früher, sich zu rentieren.

Prinzipien der Agilität

Agilität basiert auf einigen wenigen Prinzipien, die die agile Community im agilen Manifest zusammengefasst hat [2]. Sie geben konkrete Verhaltensweisen an – beispielsweise die Priorisierung von Individuen und Interaktionen über Prozesse und Werkzeuge. Noch weiter lässt sich Agilität auf einige grundlegenden Werte kondensieren, die aus dem Manifest auch abgeleitet werden können und das Fundament der Agilität darstellen:

  • Feedback: Kunden müssen zur Steuerung des Prozesses implementierte Features bewerten und auf dieser Basis neue Features priorisieren und planen. Um diese Art der Steuerung zu ermöglichen, werden die Aufgaben in Iterationen aufgeteilt.

  • Transparenz: Der aktuelle Stand der Implementierung und der dafür bisher investierte Aufwand sind für alle jederzeit erkennbar. Der Projektfortschritt ist also unmittelbar nachvollziehbar.

  • Vertrauen: Transparenz schafft Vertrauen, weil es eben weniger Geheimnisse und daher weniger Misstrauen gibt. Gleichzeitig kann Transparenz nur dann funktionieren, wenn sich alle Beteiligten vertrauen und nicht beispielsweise aufgrund von Problemen in einem Projekt das Projekt einfach beendet wird.

Damit hat Agilität Einfluss auf die Firmenkultur und kann nur in bestimmten Firmenkulturen funktionieren. Wenn bei einem Problem in einem Projekt sofort personelle Konsequenzen gezogen werden oder das Team nicht unterstützt wird, sondern nur einfach mehr arbeiten muss, kann es sein, dass die Transparenz eines agilen Prozesses überhaupt nicht im Interesse des Teams liegt und so dessen Vorteile nie zum Tragen kommen.

Und der Wasserfall?

Agile Prozesse werden oft als Gegenentwurf vom Wasserfallmodell abgegrenzt. Leider ist aber genau dieser Prozess missverstanden worden. Es lohnt sich, einen Blick auf das ursprüngliche Paper zu werfen, in dem das Wasserfallmodell zum ersten Mal erläutert worden ist – damals noch nicht unter diesem Namen [3]. Dieses Paper hat einige Überraschungen zu bieten:

Am Anfang werden tatsächlich verschiedene Phasen – wie beispielsweise das Erheben der Anforderungen, die Analyse, das Design und die Implementierung – als aufeinanderfolgende Phasen beschrieben. Das ist genau der Ansatz, der üblicherweise unter dem Begriff „Wasserfall“ verstanden wird.

Allerdings ist in dieser Publikation schon die Rede davon, dass es notwendig sein kann, einen bereits abgeschlossenen Schritt noch einmal zu tun. Das kann beispielsweise sinnvoll sein, wenn bei der Implementierung ein Problem auftaucht und daher das Design überarbeitet werden muss. Weiter wird ausgeführt, dass es durchaus notwendig sein kann, mehrere Phasen zurückzugehen – also von Design zurück zum Erheben der Anforderungen.

Schließlich wird sogar empfohlen, die Schritte ab dem Design bis hin zur Nutzung mindestens zweimal zu durchlaufen. Dabei geht es nur um die Umsetzung – im Gegensatz zu agilen Methoden werden also keine neuen Anforderungen in der zweiten Iteration implementiert. Außerdem wird der Prozess nur zweimal durchlaufen – nicht beliebig oft wie in modernen agilen Vorgehensmodellen.

Um es noch einmal klar zu sagen: Das, was heute Wasserfall genannt wird, hat mit dem, was in diesem Beitrag beschrieben wird, nicht viel gemeinsam. Einige Punkte sind sicher diskutabel – aber schon dieses mittlerweile 44 Jahre alte Paper, das den Grundstein für den Wasserfa...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang