In den letzten 15 Jahren hat die agile Vorgehensweise bei der Durchführung von Softwareprojekten in vielen Firmen Einzug gehalten.

Anfänglich war Extreme Programming (XP) die Methode der Wahl. Heute ist XP kein grosses Thema mehr. Dann hat sich vor allem Scrum den Weg zur breiten Masse gebahnt. Es gehört(e) zum guten Ton, „Scrum zu machen“.

Die agilen Techniken, die beim Bau von Software angewendet werden, halte ich für sehr wertvoll. Dies sind insbesondere:

• iteratives und inkrementelles Vorgehen
• enge Zusammenarbeit mit dem Kunden
• Iterationsbacklog
• Iterationsplanung
• tägliche Statusbesprechung
• enges Zusammenarbeiten der Entwickler untereinander
• automatisiertes Testen
• kontinuierliche, automatisierte Integration
• Weglassen von unnötigen Dokumenten, die keiner je benutzt oder die nie aktuell sind wenn man sie brauchen würde

Ein gemeinsames Merkmal der agilen Methoden ist es, dass Spezifikationsphasen zu Beginn von Projekten von der reinen Lehre abgelehnt werden. Unter dem Namen „Big Design UpFront“ (BDUF) wird dies abgelehnt und als unnütz empfunden. Das Hauptaugenmerk dieser Methoden liegt darin, so schnell wie möglich „Nutzen“ (value) zum Anwender zu bringen _[1]. Nach der ersten Iteration soll bereits eine teilweise brauchbare Software beim Kunden sein. Leider wird das „Agile Manifesto“ nicht so angewendet, wie es ursprünglich gedacht war, sondern im Sinne des „Dark Manifesto for Agile Software Development“ _[2].

Vor dem agilen Zeitalter galt es als sehr grosses Risiko, ein Projekt ohne eine Spezifikationsphase zu starten. Viele Fehlschläge von Softwareprojekten konnten auf fehlende oder mangelhafte Spezifikationen zurückgeführt werden _[3]. Umgekehrt konnten Projekterfolge in Zusammenhang mit einer seriösen Anforderungsabklärung gebracht werden _[4].

Persönliche Erfahrungen mit Anforderungsspezifikationen

Aus meiner eigenen Erfahrung kann ich diese Erkenntnisse aus dem vor-agilen Zeitalter nur bestätigen. Am Anfang meiner Laufbahn als Softwareentwickler (seit 1989) war ich an Projekten beteiligt, in denen einfach drauf los programmiert wurde. Wir Entwickler programmierten einfach das, von dem wir glaubten, es sei gut. Dabei hatten wir aber nicht in erster Linie die Benutzer im Sinn. Es wurde das gemacht, was einfach ging, und was spannend war. Ich habe auch nicht den Eindruck, dass ich mich da durch besondere Naivität von der Masse abhob.

Diese Situation war rasch unbefriedigend, da ich natürlich meine „Wunderwerke“ auch bei den Kunden installieren und einführen musste. Es war nicht befriedigend, die Frustration der Kunden zu erleben. Die nötigen Nacharbeiten führten dann auch oft dazu, dass Projekte finanziell nicht erfolgreich waren.

Um herauszufinden, was wir entwickeln sollten, waren unsere Ansprechpartner die Aussendienstmitarbeiter, die das Projekt verkauft hatten. Leider war es oft so, dass den Kunden vieles sehr vage versprochen wurde, ohne jemals Rücksprache mit den Technikern zu halten.

Ich wollte unbedingt herausfinden, was zu tun sei, damit sich diese Situation verbessert. Der erste wertvolle Schritt in diese Richtung war die Einsicht, dass man mit den Anwendern reden muss, bevor man mit der Umsetzung eines Projektes beginnen kann.

Was hier ziemlich banal klingt, war zumindest in dem Umfeld, in dem ich mich bewegte, nicht selbstverständlich. Später hat sich aber mein Eindruck gefestigt, dass dieses Problem sehr weit verbreitet war und ist.

Es geht darum, die Anliegen der Stakeholder wirklich zu verstehen

Nach der Gründung der Creasoft AG haben wir im Laufe der Jahre eine Vorgehensweise entwickelt, die es ermöglicht, zu Beginn eines Projektes zuverlässig herauszufinden und festzulegen, was im Zuge des Projektes eigentlich zu tun ist. Dazu gehört auch, dies so zu dokumentieren, dass es möglich ist, zwischen Entwicklern, Anwendern und Kunden eine Einigung und eine gemeinsame Vision des zukünftigen Systems zu entwickeln.

Der Wert dieser Spezifikationsphase liegt darin, dass man sich als Entwickler oder Projektleiter mit der Fachdomäne des Kunden befasst. So erwirbt man das nötige Wissen, um sich in die Lage des Anwenders zu versetzen und um die vielen kleinen Entscheidungen, die während eines Projektes anfallen, im richtigen Sinne treffen zu können.

Das heisst, der eigentliche Wert einer Anforderungsdefinition liegt nicht im Stapel bedruckten Papiers, den man in Händen hält, sondern im Prozess, der dazu geführt hat, und der eine riesige Menge Wissen entstehen lässt. Auch seitens der Kunden wird im Zuge der Erstellung einer Anforderungsdefinition vieles klar, das unter Umständen zuvor nie zu Ende gedacht wurde. Die Kunden wissen auch nicht einfach so, was Sie wirklich brauchen. Sie überlegen sich am Anfang nur, was sie wollen, und das ist nicht dasselbe.

Mit der oben beschriebenen Einstellung zu Anforderungen sind wir hier bei Creasoft AG in den letzten 20 Jahren sehr gut gefahren. Dabei habe ich gelernt, dass es sehr anstrengend ist, sich mit einem zukünftigen Softwaresystem rein geistig auseinanderzusetzen. Eine grosse Hilfe dabei sind enger Kontakt zum Kunden, Modelle der Kundendomäne und natürlich GUI Prototypen.

Es ist überraschend wie weit man dabei mit relativ überschaubarem Aufwand kommt, wenn man sich darüber im Klaren ist, dass ein System nicht in jedem Fall bis zum letzten Detail auf diese Weise definiert werden muss. Wie weit ins Detail zu gehen ist, kann auch über eine Abwägung zwischen Aufwand zur Detaillierung und Risiken einer eher oberflächlichen Betrachtung geschehen.

Die Umsetzung des Projekts kann dann nach dem Erstellen einer Anforderungsspezifikation mit einer der Aufgabenstellung angepassten Architektur begonnen werden. Es ist auch möglich, einen Zeit- und Kostenplan zur Realisierung zu erstellen.

Agil = Alles anders, alles besser?

Ein eingefleischter Agilist geht davon aus, dass sich Anforderungen des Kunden schneller ändern, als diese erfasst werden können. Deshalb bringt das Erstellen einer Anforderungsdefinition keinen Nutzen für den Kunden. Dies deckt sich überhaupt nicht mit meiner Erfahrung. Ich habe den Verdacht, dass das vor allem damit zu tun hat, dass, wie bereits erwähnt, das Erfassen von Anforderungen sehr anstrengend ist. Man ist als Softwareentwickler gezwungen, sich mit etwas zu beschäftigen, von dem man erst mal keine Ahnung hat: mit der Fachdomäne des Kunden. Viel angenehmer ist es, sich mit etwas zu beschäftigen, von dem man viel Ahnung hat: mit dem Erstellen von Code. Die unangenehmen Tätigkeiten werden einfach auf den „Onsite Customer“ oder den „Product Owner“ ausgelagert. Ich glaube auch, dass sich die Anforderungen nicht unbedingt ändern. Es ist eher so, dass man sie zu Beginn eines Projekts einfach nicht genügend gut kennt.

So ist es auch keine Überraschung, dass die Protagonisten der agilen Vorgehensweise vor allem Softwareentwickler sind _[1].

Die agile Softwareentwicklung sieht sich auch in der Verwandtschaft zum „Lean Management“. Aus der Sicht des „Lean Software Development“ kann man sich nun berechtigterweise die Frage stellen: Ist hier Verschwendung (waste) erkennbar _[5], wenn eine Anforderungsdefinition erstellt wird, die, wie oben erwähnt, eigentlich gar nicht das wertvolle Resultat der Arbeit ist. Hier muss meiner Meinung nach ein Blick auf die Projektrisiken geworfen werden.

Bei der Rechtfertigung der agilen Vorgehensweise werden nur die Risiken betrachtet, die aus dem klassischen plangetriebenen Vorgehen stammen. Was in der reinen „Agilen Lehre“ vernachlässigt wird, sind die Risiken, die durch das agile Vorgehen entstehen. Dies ist vor allem das Fehlen eines dokumentierten Gesamtbildes auf das Projekt:

• Beginn mit einer unangemessenen Architektur, die später mit grossem Aufwand korrigiert werden muss.
• Vernachlässigen der nichtfunktionalen Anforderungen
• Start der Entwicklung in eine falsche Richtung (da der Blick für das Ganze fehlt)  _{(vgl. [6])}
• Keine Möglichkeit die Gesamtgrösse eines Projekts zu Beginn abzuschätzen.
• Verlust von Wissen, das während eines Projekts entstanden ist, wenn Mitarbeiter das Projekt verlassen. (Ich glaube, es ist eine Illusion, dass Wissen über ein komplexes System im ganzen Team gleich verteilt sein kann).
• Grosse Aufwände, wenn neue Mitarbeiter ins Projekt kommen.
• Probleme mit der Langzeitwartbarkeit durch fehlende Dokumentation.
• Diskussionen beim Projektabschluss, da keine Abnahmekriterien festgelegt sind.
• Der Umfang der Iteration ist zu gross: Ein System muss entwickelt und installiert werden nur um Feedback vom Kunden zu bekommen.

Gibt es das Beste aus beiden Welten?

Es ist an der Zeit, eine Synthese der wertvollen Erfahrungen aus den klassischen, plangetriebenen Entwicklungsmethoden und den wertvollen Praktiken der agilen Entwicklung zu finden, und dabei die Schwächen der jeweiligen Vorgangsweisen zu vermeiden. Diese Idee ist nicht neu _[7] [8].

Softwareentwicklung ist nicht nur das Erzeugen von Programmcode. Die Reduzierung von Unsicherheit zu Beginn und während eines Projekts erzeugt ebenfalls „value“ für den Kunden.

Wenn zu Beginn eines Projektes Anforderungen erhoben werden, um sich einen Überblick über das Aufgabenfeld zu verschaffen, ist auch dies ein Bestandteil der Softwareentwicklung. Dabei ist es natürlich sinnvoll, iterativ und inkrementell vorzugehen, und engen Kontakt zum Kunden zu pflegen, sowie die Arbeitsergebnisse regelmässig mit den Projekt-Stakeholdern zu besprechen. Auf diese Weise werden die nützlichen Praktiken der agilen Vorgehensweise auch auf die Anforderungserhebung angewendet.

Ich kann mir nicht vorstellen, dass es ein Nachteil ist, möglichst früh möglichst viel über die Anforderungen an ein Projekt zu wissen, und mit dem Kunden eine gemeinsame Vision zu schaffen. Dass alle Projektbeteiligten während des Projekts noch viel Neues dazulernen, weiss jeder, der schon Projekte durchgeführt hat.

Es ist auch möglich, mit der Implementierung der Software zu starten, sobald man genügend Einsicht in eine Aufgabenstellung hat, um eine der Aufgabe und den nichtfunktionalen Anforderungen angemessene Architektur zu entwickeln. Diese Parallelität von Anforderungserhebung, Implementierung, Test, Integration und Betrieb ist das, was meines Erachtens in Zukunft von Softwareentwicklern gefordert wird _{(vgl. [9])}.

Referenzen

[1] K. Beck und M. Beedle, „The Agile Maifesto“, 2001. [Online]. Available: www.agilemanifesto.org. [Zugriff am 27 Januar 2014].

[2] A. Janes und G. Succi, „Dark Manifesto for Agile Software Development“, 2012. [Online]. Available: http://darkagilemanifesto.org/ [Zugriff am 29 Jan. 2014].

[3] T. Arnuphaptrairong, „Top Ten Lists of Project Risks: Evidence from the Literature Survey“, 16 März 2011. [Online]. Available: http://www.iaeng.org/publication/IMECS2011/IMECS2011_pp732-737.pdf [Zugriff am 10 Juni 2013].

[4] The Standish Group, „CHAOS Report“, 1995. [Online]. Available: http://www.csus.edu/indiv/v/velianitis/161/ChaosReport.pdf[Zugriff am 27 1 2014].

[5] M. Poppendieck und T. Poppendieck, „Eliminate Waste“, in Lean Software Development: An agile Toolkit, Addison-Wesley, 2003, pp. 1-13.

[6] A. Cockburn, „Why I still use use cases“, 1 September 2008. [Online]. Available: http://alistair.cockburn.us/Why+I+still+use+use+cases [Zugriff am 28 Januar 2014].

[7] B. Boehm, Balancing Agility and Discipline: A Guide for the Perplexed, Addison-Wesley, 2003.

[8] L. Cao und B. Ramesh, „Agile Requirements Engineering Practices: An Empirical Study“, IEEE Software, pp. 1-8, Jan/Feb 2008.

[9] M. Gualtieri, „Agile Software Is A Cop-Out; Here’s What’s Next“, 10 Dez 2012. [Online]. Available: http://blogs.forrester.com/mike_gualtieri/11-10-12-agile_software_is_a_cop_out_heres_whats_next [Zugriff am 28 Jan 2014].

Zurück zum Blog