Bis heute dauern viele Projekte in der Softwareentwicklung länger als erwartet, kosten mehr als geschätzt und produzieren am Ende auch noch mangelhafte Systeme. Anwender versuchen dem entgegenzuwirken, indem sie immer detailliertere Methoden entwickeln und auf professionellere Tools setzen. So waren beispielsweise einige Einführungen gemäß den Vorgaben des Capability Maturity Model (CMM) recht erfolgreich. Bei anderen Projekten erwies sich jedoch das herkömmliche, wenn auch immer weiter verfeinerte Vorgehen als ineffizient. Stattdessen hat eine Ausrichtung an agilen Grundprinzipien, die diesen Prozess in Frage stellen und die Kommunikation, das Team, das gegenseitige Vertrauen etc. ins Zentrum rücken, in der Praxis mittlerweile oft mehr gebracht.
Besonders viel Aufmerksamkeit erregte in diesem Zusammenhang das Extreme Programming (XP). Dieser von Kent Beck formulierte Ansatz wird noch heute von vielen mit agil gleich gesetzt. Tatsächlich ist XP aber nur ein besonders leichtgewichtiger Prozess, dass heißt einer, der besonders wenig Ballast in Form von Dokumenten oder ausgefeilten Prozessen mit sich trägt. XP löst natürlich nicht alle Probleme. Es verfolgt diesen Anspruch aber auch nicht. Viele Berichte in der Presse und Fachtagungen suggerieren jedoch, XP sei die einzige praxisrelevante agile Vorgehensweise. Tatsächlich werden aber nur wenige Projekte nach dem XP-Lehrbuch umgesetzt. So gab beispielsweise im März 2003 nur die Hälfte der in der Yahoo-XP-Usergroup organisierten Interessenten an, tatsächlich XP-konforme Projekte zu machen oder sich daran zu beteiligen. In der Praxis kommen daher wohl leichte und den schwergewichtigen Vorgehensweisen gleichermaßen zum Einsatz.
Nichts geht ohne Anforderungen
Wichtigster Baustein aller Prozessmodelle, ob nun schwer- oder leichtgewichtig, ist die Anforderungsanalyse. Ohne Kenntnis darüber, was der Kunde will, ohne konkrete, schlüssige und priorisierte Anforderungen, läuft jegliche Anstrengung ins Leere. Projekte mutierten dann zeitlich, finanziell oder qualitativ zum desaströsen Unterfangen. Die Wünsche der Kunden sind indes meist nicht stabil. So wird in einigen Projekten häufig Neuland betreten, so dass sich 30 bis 50 Prozent der Anforderungen erst während der Entwicklung ergeben. Auslöser für die Veränderungen sind wechselnde Umgebungsbedingungen oder neue Erfahrungen, die in das Projekt einfließen sollen. Wer also die Anforderungen ab einem bestimmten Zeitpunkt als fix betrachtet, verdrängt diese Tatsache und beseitigt das Problem nicht.
Agile Lösungsansätze hierfür gibt es inzwischen viele. Ihnen ist gemein, dass sie den Kunden mit seinen Bedürfnissen in den Mittelpunkt stellen und eine gemeinsame Sprache für das Gesamtteam fordern, statt Wissen rein über Spezifikationen weiter zu geben. Diese Prinzipien machen dieses Vorgehen erfolgreich und führen zu besseren Spezifikationen und Produkten. So bezeichnete in einer Umfrage in der Yahoo-XP-Usergroup rund die Hälfte der Projektmitarbeiter den persönlichen Austausch mit dem Kunden für eine wichtige Errungenschaft. Allerdings unterscheiden sich die agilen Ansätze erheblich, wenn es darum geht, die Anforderungen zu erfassen.
So werden bei XP beispielsweise nur kurze Szenarien festgehalten (User Stories) und genauere Anforderungen in Form von Testfällen dokumentiert, während andere Ansätze objektorientierte Modelle oder umfassendere natürlich sprachliche Dokumentationen fordern. Seit 2003 werden in der Praxis zudem Ideen erprobt, Anforderungen von vornherein so zu dokumentieren, dass sie sich auch als Benutzerhandbuch oder als Abnahmekriterien anderweitig verwenden lassen. Erste Ergebnisse sind bisher viel versprechend. Wie sich Systeme verhalten, bei denen in langen Jahren der Wartung sehr wenig in Prosa oder nur in Modellen dokumentiert wurde, ist derzeit leider noch nicht untersucht.
Agil heißt, sich der passenden Methode aus einem riesigen Angebot zu bedienen. Orientierungshilfe bietet das Manifest der agilen Softwareentwicklung (www.agilemanifesto.org). In Projekten in Industrie und Handel haben sich zudem weitere Erfahrungen herauskristallisiert, die den Kurs in einem agilen Projekt bestimmen helfen können, auch wenn sie sich teilweise überschneiden oder widersprechen. So bewahrt ein aktives Risiko-Management Projekte davor, unnötige Schritte zu unternehmen. Insbesondere die Draufgänger unter den Projektleitern folgen hingegen dem Motto "Immer dem größten Nutzen nach". Sie bevorzugen es, den Nutzen und Profit zu steigern, statt Risiken zu minimieren. Eine weitere Erfahrung zeigt, dass Standardsituationen oft Standardlösungen haben und dass es ratsam ist, den Instinkten von Schlüsselpersonen zu trauen. Herrscht hingegen Unklarheit über das richtige agile Vorgehen oder ist der Anwender noch ungeübt, sollte man anhand eines definierten Vorgehensmodells arbeiten.
Eine weitere Erkenntnis aus der Diskussion um agile Vorgehensweisen ist, dass eine gute Ausbildung und viel Erfahrung zumindest bei einigen Projektmitarbeitern in der Praxis unabdingbar bleibt. Dies betrifft sowohl die Arbeitsmethoden als auch die soziale Kompetenz. Eingespielte Teams sind in diesem Zusammenhang unschlagbar. Weiter ist zu beobachten, dass Anfänger deutlich schneller lernen, wenn sie in erfahrene, agil arbeitende Teams integriert werden, weil sie die komplexen Zusammenhänge unmittelbarer erleben.
Wenn ein Projektteam sich und seine Verfahren nicht ständig in Frage stellt, übersieht es leicht Veränderungschancen. Besonders ausgeprägt ist dieses Motiv im agilen Vorgehensmodell "Scrum" von Mike Beedle. Allerdings gilt auch hier: Manchmal bleibt am besten alles beim Alten. Dann ist es aber wichtig, dies bewusst zu beschließen.
Eine Frage des Vertrauens
Das Management muss zudem dem Projektteam bis zu einem gewissen Grad vertrauen und ihm die Freiheit lassen, selbst seine Vorgehensweise zu wählen. Zumindest muss das Team die verwendeten Methoden frei auswählen können und von der Pflicht entbunden sein, sich an eine starre, beispielsweise vom Qualitätssicherungs- oder Methodenbereich definierte Vorgehensweise zu halten. Wichtige psychologische Aspekte sollten in diesem Zusammenhang aber nicht vergessen werden: "Agil sein" heißt anpassen, entscheiden, Verantwortung übernehmen. Wo bisher eine definierte Vorgehensweise einzuhalten war, liegt nun die Entscheidung oder Mitentscheidung im Team, und diese Verantwortung löst nicht immer nur Begeisterung aus, sondern häufig auch Ängste.
In vielen Unternehmen lagern heute noch tausende Zeilen noch nicht produktiven Codes. Damit bleiben zehntausende von Entwicklerstunden ungenutzt und die angestrebte Kostenminimierung oder Effizienzsteigerung durch neue Software tritt nicht ein. "Das Kapital, das man in eine Systementwicklung stecke, ist so lange "tot", bis es zum genutzten Release kommt," hat einmal XP-Begründer Kent Beck geschrieben.
In kleinen Schritten zum Ziel
Die Erfahrung mit agilen Verfahren hat hingegen gezeigt, dass der Mut und auch die Akzeptanz unter den Projektbeteiligten wachsen, wenn kleinere Releases geplant und erreicht werden. Nützliche Inkremente lassen sich heute oft schon in zwei bis vier Monaten oder weniger entwickeln. Dauert dies länger als ein halbes Jahr liegt ein Problem vor. Was haben also die Jahre der Agilität gebracht? Den Projekten vor allem mehr Flexibilität und deutlich bessere Chancen, in unseren turbulenten Zeiten erfolgreich zu sein. Den Kunden stehen nun schneller und häufiger Systemversionen zur Verfügung, die sie unmittelbar nutzen können, und die nicht mehr von ihren Änderungen eingeholt werden. (as)
*Chris Rupp ist Geschäftsführerin des Nürnberger Beratungshauses Sophist Group und Buchautorin,
Rolf Götz arbeitet bei Sophist als Consultant.
Die häufigsten Irrtümer
1. Agilität = Extreme Programming (XP). Nein, XP ist nur ein agiles Verfahren, und zwar ein besonders leichtgewichtiges. Etwas Extremes eben.
2. Agilität = Anarchie. Keinesfalls, denn agile Vorgehen sind rigider als viele andere Vorgehensmodelle, zum Beispiel durch die Pflicht zur Retrospektive.
3. Agilität = nicht dokumentieren müssen. Das stimmt nur bedingt, denn in agilen Projekten wird dokumentiert, was ausgeliefert wird, für das es einen Sponsor gibt oder was das Team für sinnvoll hält.
4. Agilität = Dogma. Es gibt in einigen agilen Vorgehen, etwa für XP, sehr klar formulierte Regeln. Agilität bedeutet aber, diese im Grundverständnis des Agilen Manifests an die Gegebenheiten anzupassen.
5. Agilität = der Tod der Anforderungsanalyse. Nein, denn gerade die agilen Vorgehensmodelle bemühen sich um ein fundiertes Verständnis der Kundenforderungen. Sie führen allerdings meist nicht zu Tonnen von papiernen Spezifikationen.
Was nicht zur Agilität passt
- Matrix-Organisation mit vielen Wechseln, weil sich in diesen keine guten Teams bilden können
- Bemühungen vor allem in größeren Firmen, Prozesse zu konsolidieren und sei es nur die Einführung eines Tools, das alle nutzen müssen
- Projektaudits von Auditoren, die aufs Formale achten oder die Effizienz von Teams nicht bewerten können
- Blinder Glaube an Propheten, zum Beispiel wenn diese von aktuellen Hype-Themen predigen (Agilität oder auch Risikomanagement), denn blinder Glaube ist das Gegenteil dessen, was Agilität ausmacht. Dieser Fehler wurde bei den Schwergewichten bereits einmal begangen.
- Teammitglieder, die Verantwortung ablehnen und sich lieber auf vorgeschriebene Vorgehensweisen einer zentralen Stabs- oder Qualitätssicherungsabteilung verlassen. Hier fehlt der Mut, Entscheidungen zu treffen und diese verantwortlich zu tragen sowie Fehler einzugestehen.