Agile Softwareentwicklung mit Java

Prinzipien, Methoden und Werkzeuge

(Unser Seniorberater Nils Wloka für OPITZ CONSULTING)

Internationaler Wettbewerb und Marktkonsolidierung in Zeiten fortgeschrittener Globalisierung fordern flexible Produktions-verfahren und die Fähigkeit zur schnellen Markterschließung.
So ist agile Softwareentwicklung in aller Munde.

Wie aber lassen sich die Vorteile iterativen, kundennahen Vorgehens in einer Java-Enterprise-Landschaft realisieren?

Ist zwischen buchdicken Spezifikationen und mächtigen Middleware-Plattformen Platz für die Prinzipien agiler Softwareentwicklung? Und: Ist Agilität in solch einem Ökosystem überhaupt sinnvoll?

Der folgende Artikel gibt Antworten auf diese Fragen und versteht sich gleichzeitig als Wegweiser durch ein komplexes,
kontrovers diskutiertes Thema.

Vielleicht fragen Sie sich, warum viele der externen Verweise in diesem Artikel auf englischsprachige Seiten zeigen. Wir waren bemüht, für weiterführende Informationen deutschsprachige Quellen anzugeben.
Es ist jedoch der Tatsache geschuldet, dass die "Muttersprache" der IT-Branche nach wie vor Englisch ist, dass Umfang und Qualität verfügbarer Ressourcen uns häufig dazu bewegten, dieser Sprache den Vorzug zu geben.

Was ist Agilität?

Kaum ein Begriff wird heute im Zusammenhang mit Softwareentwicklung so strapaziert wie Agilität. Um im Überangebot "agiler" Produkte und Verfahren nicht die Orientierung zu verlieren, ist es sinnvoll, sich einmal die Anfänge vor Augen zu führen.

So fing alles an ...
Im Februar 2001 trafen sich im Rahmen eines Skiausflugs eine Handvoll Entwickler und Berater zu einer Diskussion über die Grundlagen der Softwareentwicklung. Unerwartetes Ergebnis des dreitägigen Ausflugs war das Dokument, das noch heute als Agile Manifesto bekannt ist.

Die Autoren, zu denen unter anderem Größen wie Martin Fowler, Kent Beck, Ward Cunningham, Alistair Cockburn und Jim Highsmith zählen, verfassten keinen Leitfaden und keinen Prozess, sondern eine Sammlung von Prinzipien mit dem Ziel, Softwareentwicklung für Kunden wie für Entwickler zu einer erfreulichen Erfahrung zu machen.

Sieben Jahre und mehr als fünftausend Unterzeichner später ist agile Softwareentwicklung keine Randerscheinung mehr. Gleichzeitig gibt es in der IT kaum ein Thema, das die Gemüter auf dieselbe Weise erhitzen kann. Aber schauen wir einmal hinter alle Diskussionen und auf den Text, der immer noch den Kern agiler Vorgehensmodelle bestimmt.

**Manifesto for Agile Software Development**
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.
Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler	James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick	Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas
© 2001, the above authors this declaration may be freely copied in any form, but only in its entirety through this notice.

Die grundsätzliche Attraktivität dieser Aussagen lässt sich schon an der Anzahl der Prozesse erkennen, die sich auf das Manifest berufen. Ob Extreme Programming, Scrum, Feature Driven Development oder Open Unified Process, sie alle sind bemüht, die Grundprinzipien – Flexibilität, Transparenz und Kooperation – ins Zentrum aller Tätigkeiten zu stellen. Eben diese Grundprinzipien zu erläutern und im Kontext der Durchführung Java-Enterprise-basierter Projekte zu präzisieren soll Ziel dieses Artikels sein.

>> zurück nach oben

Prinzipien und Verfahren im Überblick

Da die Menge agiler Prozesse heute vermutlich nur noch von der Menge der Java-Web-Frameworks übertroffen wird, beschränken wir uns zunächst auf die prominentesten Verfahren. Nehmen wir einmal die allgegenwärtige, von jedem Kunden erwartete und von jedem Anbieter versprochene Flexibilität.
Flexibilität (vom lateinischen flectere für biegen oder beugen) ist laut Wiktionary unter anderem die Fähigkeit, "sich auf geänderte Anforderungen und Gegebenheiten einer Umwelt einstellen zu können". Das ist noch etwas allgemein, lässt aber schon erste Rückschlüsse auf Anforderungen zu, denen ein flexibles Verfahren standzuhalten hat. "Biegen" klingt, zumindest im Vergleich zu "brechen" nach Anpassung, auch die eigentliche Definition impliziert Evolution.

Iterative Entwicklung
Dieses Verständnis ist grundlegend für nahezu alle agilen Prozesse: Evolution (Entwicklung) findet in der Abfolge (Iteration) von Generationen (Veröffentlichungen oder englisch Releases) statt. Die Abkehr von monolithischen Großprojekten zugunsten regelmäßiger, kleiner Releases hat erstaunliche Auswirkungen.
Aus Sicht der Entwickler lösen sich gigantische Spezifikationen in konkrete, innerhalb einer Iteration zu implementierende Teilfunktionalitäten auf ("Working software ...").
Aus Sicht der Produktverantwortlichen bietet sich mit jedem neuen Release die Gelegenheit, die ursprüngliche Spezifikation neu zu bewerten und gegebenenfalls anzupassen, man könnte auch sagen, zu "biegen" ("Responding to change...").
Kunden und Anwender bekommen die Möglichkeit, frühzeitig mit Features zu experimentieren und sich in den Entwicklungsprozess einzubringen ("Individuals and interactions...").

Iterationen sind der Herzschlag agiler Projekte. Nun ist der Herzschlag zwar notwendige, aber noch nicht hinreichende Bedingung für die Gesundheit eines agilen Projekts. Iterationen wollen geplant, mit Entwicklungstätigkeit gefüllt und ausgewertet werden. Zwar unterscheiden agile sich Methoden in ihrer Ausprägung, dennoch ähneln sich die Bausteine, aus denen sich ihre Iterationen zusammensetzen.

Bausteine agiler Prozesse
In Planungsphasen werden Teilfunktionalitäten (beispielsweise in Form von User Stories, Features oder Use Cases) für die folgende Entwicklungsperiode ausgewählt und priorisiert. Diese werden durch Analyse und Modellierung (vielleicht in UML Modellen, auf CRC Cards oder mit anderen Werkzeugen) wiederum in Teilaufgaben zerlegt.

Zielvorgaben werden sowohl auf der Ebene der Teilfunktionalitäten (mittels Akzeptanztests, Test Cases oder auch manueller Testskripte) als auch auf der Ebene der eigentlichen Softwareartefakte (im Rahmen testgetriebener oder verhaltensgetriebener Entwicklung) konkretisiert, um anschließend vom Team unter Durchführung geeigneter Plausibilitätskontrollen in so unterschiedlichen Ausprägungen wie Pair Programming und Inspektion implementiert zu werden.

Evolutionäre Altlasten werden durch von mehrschichtigen Regressionstests (unter anderem Unit Tests und Integrationstests) abgesicherte Umgestaltungen, Refactoring genannt, beseitigt. Ein Projektmanager, ScrumMaster oder Coach überwacht den Projektfortschritt mit Hilfsmittel wie Burn-Down Diagrammen und Indikatoren wie Projektgeschwindigkeit.

In ihrer Gesamtheit ergänzen sich diese Bausteine. Ohne sich dabei in Verfahrensanweisungen und Prozessschritten zu verlieren, tragen sie die Prinzipien, aus denen sich Agilität letztendlich zusammensetzt. Projekte werden für Kunden und Verantwortliche durch nachvollziehbare Zielvorgaben transparenter, die Erzeugung tatsächlicher Geschäftswerte rückt in den Vordergrund. Der Projektverlauf ist bestimmt durch enge Kooperation zwischen Dienstleister, Sponsor und Fachanwender. Plausibilitätskontrollen, automatisierte Testverfahren und inkrementelles Design erhöhen die Codequalität und senken Defektraten.

>> zurück nach oben

Die richtigen Werkzeuge

Aber all diese Verfahren ergeben nur Sinn, wenn sie sich in der verwendeten Technik widerspiegeln. Nun ist Agilität sicher nicht der erste Begriff, den man gewöhnlich mit Java-Enterprise-Umgebungen assoziieren würde. Dennoch profitiert die Java-Plattform davon, dass viele Vordenker agiler Ansätze sie als ihre berufliche Heimat betrachten. So ist im Laufe der Jahre eine große Auswahl von Hilfsmitteln entstanden, die uns heute in Java-Enterprise-Projekten zur Verfügung steht. Beginnen wir unsere Reise durch diese Werkzeuglandschaft da, wo auch ein Projekt seinen Ursprung hat. Die präzise Definition von Anforderungen ist nicht nur für iterative Vorgehensmodelle wichtig, nimmt hier jedoch einen besonderen Stellenwert ein, da in viel kleineren Intervallen funktionsfähige Software entstehen und an diesen Anforderungen gemessen werden soll.

Testautomatisierung
Eine überaus präzise Form der Spezifikation stellen automatisierte Akzeptanztests dar. Sie beschreiben funktionale Anforderungen in mehr oder weniger natürlicher Sprache, werden aber zusätzlich mittels spezieller Techniken automatisiert ausführbar gemacht.

Das bekannteste Werkzeug dieser Art in Java-Projekten ist FitNesse. Es besteht aus einem Wiki-Server, auf dessen Seiten mit Hilfe einer speziellen Syntax die geforderte Geschäftslogik in Form von Szenarien beschrieben werden kann.
Anhand dieser Szenarien wird die zu testende Java-Software auf ihre Funktionsfähigkeit überprüft; die Ergebnisse wiederum können direkt in den Wikiseiten visualisiert werden, so dass sowohl für Entwickler als auch für Kunden und Fachanwender ersichtlich wird, welche Bestandteile der Software bereits implementiert sind. Grundlage für FitNesse ist das von Ward Cunningham entwickelte Framework for Integrated Test, kurz Fit genannt, das in der Lage ist, HTML-Tabellen als Testszenarien zu interpretieren und damit spezielle Klassen, Fixtures genannt, zu steuern.

Einen ähnlichen Ansatz verfolgt das neuere Concordion-Framework. Zwar sind auch hier die Testszenarien in HTML-Seiten beschrieben, allerdings entfällt die Beschränkung auf Tabellenstrukturen, so dass Spezifikationen vollständig in natürlicher Sprache ausgedrückt werden können. Als Ausführungsumgebung verwendet Concordion das in der Java-Welt weit verbreitete JUnit-Framework, so dass umfangreiche Integrationsmöglichkeiten bestehen.

Da Testautomatisierung für iterative Entwicklungsprozesse aufgrund häufiger Refactorings eine hohe Bedeutung hat, ist es nicht verwunderlich, dass hier eine große Zahl von Werkzeugen verfügbar ist. Für Java ist das älteste und prominenteste unter ihnen JUnit. Es wurde ursprünglich von Kent Beck und Erich Gamma zur Durchführung sogenannter Unit- oder Komponententests entwickelt, ist aber durch eine große Zahl von Erweiterungen heute für viele Testszenarien einsetzbar.

Betrachten wir einmal die üblichen Black-Box-Testverfahren, also die Klassen von Softwaretests, die ohne Kenntnis der Implementierung arbeiten, von "Innen" nach "Außen":

Auf unterster Ebene testen Unittests die Funktion der unzertrennlichen Einheiten der Software – in objektorientierten Sprachen wie Java sind dies die öffentlichen Methoden einer Klasse – in Isolation, also ohne dabei die Funktion verbundener Einheiten einzubeziehen. Dieser durch spezielle Programmiertechniken (sogenanntes Mocking) erzielte Aspekt erlaubt es, nach Refaktorisierungen auftretende Programmfehler schnell und präzise zu lokalisieren und macht Unittests zu einem wichtigen Eckpfeiler von Regressionstests.

Allerdings zeigen sich bereits hier zwei wichtige Einschränkungen:
Die erste, absolute, liegt in der Natur der Sache: Automatisierte Softwaretests können niemals beweisen, dass eine Software funktioniert, sondern identifizieren, korrekte Testfälle vorausgesetzt, lediglich Fehler. Somit lassen sie sich als eine Art Wette verstehen, die gewonnen wird, wenn während der Lebensdauer eines Systems in dem getesteten Artefakt eine Fehlfunktion auftritt.
Die zweite Einschränkung liegt darin, dass das System unter Test technisch so beschaffen sein muss, dass Komponenten isoliert von ihrer Umgebung ausgeführt werden können. Gerade diese Eigenschaft jedoch war in der Vergangenheit in Java-Enterprise-Systemen häufig nicht gewährleistet, erforderten doch viele der Frameworks mächtige Laufzeitumgebungen.

Heute verfügen wir über die geeigneten Werkzeuge, uns aus dieser "Gefangenschaft" zu befreien; bevor wir diese allerdings im Detail betrachten, werfen wir noch einen Blick auf die verbleibenden Klassen von Black-Box-Tests.
Bekanntlich ist das Ganze mehr als die Summe seiner Teile, daher sollten die Komponenten einer Software nicht nur für sich allein, sondern auch im Zusammenspiel und bezüglich ihrer Konfiguration getestet werden. Hierzu dienen sogenannte Integrationstests. Sie überprüfen Annahmen bezüglich des Verhaltens von Teilbereichen des Gesamtsystems. Die konkrete Implementierung ist abhängig von der Ausprägung des Gesamtsystems. Als Beispiel für ein JUnit-basiertes Framework kann aber der Spring TestContext dienen, der Konfiguration und Integrationen von Komponenten mittels des Spring Frameworks durchführt.

Laufzeit
Das Spring Framework ist in vielen Aspekten als Werzeug exemplarisch für agile Softwareentwicklung im Java-Enterprise-Umfeld. Einer seiner großen Vorteile ist die Ermöglichung eben jener oben beschriebenen Testbarkeit von Komponenten.

Es erreicht diese Eigenschaft durch zwei primäre Programmiermodelle. Das Entwurfsmuster der Dependency Injection löst die Kopplung auf Implementierungsebene auf und erlaubt damit überhaupt erst die für Komponententests notwendigen Programmiertechniken.

Darüber hinaus wurde bei der Entwicklung dieses Werkzeuges der eigentliche Java-Enterprise-Gedanke konsequent weitergedacht: Spring als "Laufzeitumgebung" innerhalb eines Java-Enterprise-Systems ermöglicht es, nahezu beliebige Dienste in Softwarekomponenten zu verwenden, ohne diese dabei von der verwendeten Technik abhängig zu machen. Die Verwendung dieses als aspektorientierte Programmierung bekannten Paradigmas erlaubt das Spring Framework in besonders einfacher Form und ohne die Notwendigkeit zusätzlicher Programmiersprachen wie AspectJ.

In Kombination können so komponentenbasierte Anwendungssysteme entwickelt werden, die einerseits von der Mächtigkeit der Java-Enterprise-Plattform profitieren, deren Programmiermodell sich andererseits aber hervorragend in einen agilen Softwareentwicklungsprozess einfügen. Ihre Testbarkeit ist das Fundament für eine Vorgehensweise, die letztlich die essentielle Eigenschaft agiler Projekte begründet.

Flexibilität durch iteratives Design
Spricht man von iterativer Entwicklung, so impliziert dies nicht nur die sequentielle, in Abschnitte eingeteilte Entwicklung spezifizierter Funktionen, sondern auch eine schrittweise Verbesserung bestehender Codebestandteile; denn keines der bisher beschriebenen Verfahren kann seine Vorzüge entfalten, wenn das erzeugte System in sich starr und unveränderlich ist.
Objektorientierte Programmiersprachen wie Java sind in ihren Grundzügen für Erweiterbarkeit und Modifizierbarkeit entworfen. Sie implementieren zu diesem Zweck Paradigmen wie Vererbung, Abstraktion, Kapselung und Polymorphie.

Um die durch diese Eigenschaften mögliche Flexibilität aber tatsächlich zu realisieren, ist die Einhaltung bestimmter Prinzipien notwendig.
Vom allgegenwärtigen DRY (für "Don't Repeat Yourself") über das unscheinbare Single Responsibility Principle bis zu Bertrand Meyers klassischem Open-Closed-Prinzip stellt Objektorientierung hohe Ansprüche an Architekten und Entwickler. Man könnte annehmen, einiges spräche für die Behauptung, die Berücksichtigung all dieser Prinzipien sei unter realistischen Projektbedingungen wenn nicht vollständig unmöglich so doch ineffizient und daher nicht wünschenswert.

Tatsächlich wird in einigen agilen Vorgehensmodellen akzeptiert oder sogar verlangt, die einfachste Lösung für ein Problem zu implementieren – allerdings mit einem großen Vorbehalt: So entstandener Code ist nicht für die Ewigkeit geschaffen sondern unterliegt einem ständigen Anpassungsprozess, dessen Ziel schließlich die größtmögliche Konformität mit objektorientierten Paradigmen ist. Dieser Anpassungsprozess, bekannt unter dem Begriff Refactoring, hat keinerlei Auswirkungen auf die Funktionalität eines Systems. Er dient ausschließlich der "Codehygiene", der Beseitigung sogenannter "Code Smells", der evolutionären und iterativen Verbesserung des Designs, und verhindert so die Art von Softwaresystemen, die in der Praxis immer mehr oder weniger schmeichelhaft "historisch gewachsen" genannt werden.
Dieses unkontrollierte, von Ward Cunningham und Martin Fowler als "technische Schuld" bezeichnete Wachstum, ist verantwortlich für die immensen, die der Entwicklung weit übersteigenden Wartungskosten großer Softwaresysteme.

Die aktuelle Entwicklung zeigt, dass mit wachsender Einsicht in diese Zusammenhänge auch die sogenannten "leichtgewichtigen" Werkzeuge, die evolutionäre Vorgehensmodelle durch Gewährleistung von Testbarkeit und Entkopplung erst ermöglichen, rapide an Bedeutung gewinnen.

Entwicklungsumgebung
Abrunden wollen wir die technische Seite agiler Java-Entwicklung mit einem kurzen Überblick über die Werkzeuge, die Entwicklern und Architekten zur Verfügung stehen. Unser Augenmerk liegt dabei nicht auf den eigentlichen Entwicklungswerkzeugen – die Auswahl der richtigen IDE ist, bedingt durch sehr ähnlichen Funktionsumfang der einzelnen Produkte, ohnehin mittlerweile eher eine Frage des Geschmacks geworden – sondern auf der unterstützenden Infrastruktur.

Hier seien insbesondere die sogenannten Continuous Build Systeme erwähnt, die durch das automatische Übersetzen entwickelter Komponenten und das kontinuierliche Ausführen aller Tests Defekte frühzeitig erkennen und so helfen, aufwändige Integrationsmaßnahmen gegen Ende einer Iteration zu vermeiden. Die Auswahl freier und kommerzieller Systeme ist groß genug, um für praktisch jede Anforderung ein geeignetes Produkt auswählen zu können. Der Fokus sollte hier auf einer guten Integration mit bestehenden Entwicklungstools und -prozessen liegen.

Werkzeuge zur Erhebung sogenannter Metriken können helfen, gefährdete Bereiche eines Systems frühzeitig zu erkennen und entsprechende Gegenmaßnahmen zu ergreifen. Die Interpretation solcher durch Codeanalyseverfahren ermittelten Kennzahlen bleibt aber nach wie vor Handarbeit.

Es sei aber auch deutlich darauf hingewiesen, dass, wie schon im Manifest mit "... over processes and tools" erwähnt, noch kein Team allein durch ein Werkzeug agil geworden ist. Kriterien für die Auswahl von Hilfsmitteln sollten hier vor allem "Barrierefreiheit" im Sinne intuitiver Bedienbarkeit, Anpassbarkeit und konkreter Nutzen sein.
Wie schon Scott Ambler in seinen Erläuterungen zu "einbeziehender Modellierung" festhält, ist in vielen Fällen ein Blatt Papier geeigneter als ein komplexes Softwareprodukt ...

>> zurück nach oben

Risikomanagement durch Agilität

Zwar haben wir jetzt einen Überblick über Ideen, Methoden und Werkzeuge agiler Softwareentwicklung erhalten, es stellt sich aber die Frage, was Agilität jenseits technischer Sichtweisen attraktiv macht, was also den immer wieder beschworenen "Stakeholder" dazu veranlassen könnte, Agilität nicht nur zu akzeptieren, sondern einzufordern.

Bei allen Vorteilen, die agile Softwareentwicklung unter idealen Voraussetzungen bietet, lässt sich diese Frage nicht pauschal beantworten. Zwar sprechen Studien dafür, dass agile Prozesse für Entwicklungsteams angenehmere Voraussetzungen schaffen als traditionelle Verfahren und das daraus resultierende Mehr an Motivation die Qualität der produzierten Software positiv beeinflusst.

Ein greifbarer Nutzen für den Kunden lässt sich aber nur über die Effizienz seiner Investition, also als "return on investment" ausdrücken. Herstellungs- und Betriebskosten reduzieren damit die Investitionseffizienz, frühzeitige und umfangreiche "Umsätze" erhöhen sie. Der Begriff Umsatz ist hier sicher gerade im Bereich der häufig intern eingesetzten und damit hauptsächlich über operative Vorteile wirkenden Enterprise-Software nicht immer in harten Zahlen auszudrücken. Dennoch muss im Folgenden betrachtet werden, ob und wie Agilität in der Lage ist, Kosten zu senken und eine messbare Form von Nutzen schneller oder in größerem Umfang zu realisieren.

Investitionsrechnung
Betrachten wir zunächst die Investitionsseite.
Im Vergleich zu extrem dokumentationslastigen Verfahren lässt sich hier in Bezug auf die Herstellungskosten eventuell ein Vorteil agiler Methoden erkennen, allerdings muss festgehalten werden, dass umfangreiche Testautomatisierung, Reviewtechniken wie Pair Programming und durch iterative Entwicklung bedingtes Refactoring zwangsläufig Aufwand erzeugen, der nicht primär der Realisierung von Geschäftswert dient.

Nicht zuletzt dieser Tatsache ist geschuldet, dass die Effizienz solcher Verfahren von Stakeholdern immer wieder kritisch hinterfragt wird.
Untersuchungen beziffern beispielsweise die Mehrkosten für Codeproduktion im Pair-Programming-Verfahren je nach Sichtweise auf 15 bis 50%. Auch Refactoring, also die Modifikation bereits funktionsfähigen Codes, erscheint unter dem Gesichtspunkt der Kostenreduzierung nicht wirklich zielführend. Die in agilen Methoden allgegenwärtigen automatisierten Tests beweisen niemals Korrektheit sondern im besten Fall Fehlfunktion.

Zusammenfassend könnte man also annehmen, das agile Verfahren sich aus Sicht des Investors, wenn überhaupt, nur rechtfertigen ließen, falls sie auf quasi magischem Wege in der Lage wären, Produkte herzustellen, die überproportional hohe Erlöse versprechen. Diese Schlussfolgerung vernachlässigt jedoch zwei ökonomisch bedeutsame Eigenschaften iterativer Verfahren, die erst bei näherer Betrachtung sichtbar werden.

Iterative Softwareentwicklung basiert auf der Unterteilung eines Gesamtprojekts in kleinere, in sich schlüssige Abschnitte, innerhalb derer ein Nutzen geschaffen wird. Der Kunde erhält die Möglichkeit, die Ausgestaltung dieses Nutzens, also die Auswahl der zu implementierenden Funktionen von Iteration zu Iteration neu zu bestimmen und so an die aktuelle Situation anzupassen. Der erbrachten Nutzen wird nach jeder Iteration zur Verfügung gestellt. Auf diese Weise können schon während der laufenden Produktion Teile der geplanten "Umsätze" realisiert werden.
Betrachtet man die häufig geringe Nutzungsdauer interner Softwareprodukte, kann allein die durch frühere Realisierung von Werten erzielte Verkürzung der Amortisationszeit den zusätzlichen Aufwand rechtfertigen.

Die zweite Eigenschaft ist spekulativer Natur, sollte hier aber nicht unerwähnt bleiben. Iteratives Vorgehen kann als die Schaffung von Realoptionen interpretiert werden. So bietet es neben der offensichtlich mehrstufigen Investition durch den Fokus auf funktionsfähigen Komponenten und flexiblen Iterationsplänen unter anderem Abbruch- und Wandlungsoptionen.
Diese Betrachtungsweise machen sich H. Erdogmus und J. Favaro zueigen, um eine erweiterte Kapitalwertmethode für die Beurteilung von Investitionen in agile Softwareprojekte zu konstruieren. Sie zeigen, dass der mit zunehmender Volatilität des Projektumfelds steigende Wert dieser impliziten Optionen in der Investitionsrechnung – analog zum Wert von Finanzoptionen – berücksichtigt werden sollte.

Aber selbst wenn wir uns entscheiden, diese Aspekte agiler Verfahren zu vernachlässigen, greift eine Argumentation, die sich ausschließlich auf die Betrachtung von Herstellungskosten stützt, zu kurz. Die weit verbreitete Ansicht, die Gesamtkosten einer Software wären mit ihren Produktionskosten gleichzusetzen, wird in der Realität nicht bestätigt.

Betrachtet man die Total Cost of Ownership, lässt sich feststellen, dass selbst nach konservativen Schätzungen die Herstellungskosten bestenfalls ein gutes Drittel der Gesamtkosten ausmachen, der Anteil konkreter Programmierarbeiten nicht selten sogar unter zehn Prozent liegt. Wartungskosten in Form korrektiver und adaptiver Tätigkeiten dominieren die Gesamtrechnung. Wie wir aber den vorherigen Ausführungen entnehmen konnten, liegen gerade in der Berücksichtigung dieser Problematik die großen Stärken agiler Vorgehensmodelle. Der Einsatz von Review-Verfahren wie Pair Programming senkt Defektraten, führt zu besserem Design und sorgt für eine homogene Wissensverteilung.

Umfassende Testautomatisierung und kontinuierliche Integration stellen kurze Feedbackzeiten und frühzeitige Identifikation und Isolation von Programmierfehlern sicher und reduzieren so die Korrekturkosten erheblich. Iteratives Design und regelmäßiges Refactoring hält die Software formbar, Adaptions- und Modifikationskosten sinken.
Der im Manifest formulierte Fokus auf "Responding to change ..." wirkt sich also weit über die eigentliche Entwicklung hinaus in allen Lebensphasen eines Softwaresystems aus.

Produktivität
Bleibt noch die zuvor in Aussicht gestellte magische Produktivitätssteigerung. Betrachten wir die Definition von Produktivität, so scheint es zulässig, sie im Kontext dieses Artikels als erzeugter Wert pro eingebrachtem Aufwand zu betrachten. Wie bereits festgehalten, ist die Reduzierung des Aufwands nicht zwangsläufig eine der Stärken agiler Verfahren.

Es bleibt zum Zwecke der Produktivitätssteigerung also nur noch die Erhöhung des produzierten Geschäftswerts. "Working software ..." deutet schon an, dass man in agilen Kreisen die Erzeugung von Geschäftswert ernst nimmt. Seine Maximierung wird letztlich durch ein verblüffend einfaches Prinzip erreicht: Agile Verfahren sind auf Veränderungen ausgelegt. Regelmäßig stattfindende Planungsrunden ermöglichen dem Kunden, das für ihn entwickelte System während des gesamten Projektzeitraums mitzugestalten.
Der eingebrachte Aufwand erzeugt nicht nach monate- oder jahrelanger Entwicklungszeit ein auf einer dann vermutlich schon überholten Spezifikation basierendes Produkt. Die Produktivitätssteigerung liegt in der Beschränkung auf den echten Kundennutzen und die Berücksichtigung sich verändernder Rahmenbedingungen.

Die Magie liegt also nicht darin, mehr zu produzieren. Agile Projekte zeichnen sich in aller Regel dadurch aus, dass sie das Richtige produzieren.

>> zurück nach oben

Aufbruch in eine agile Welt

Es scheint also vieles darauf hinzudeuten, dass agile Softwareentwicklung auch im Bereich der Java-Enterprise-Entwicklung eine Überlegung wert sein könnte. Leider lassen sich Prozesse nicht einfach wie die neuste Java-Version installieren. Tatsächlich sind weder Auswahl, noch Ein- und Durchführung trivial. Zugegebenermaßen ist die erste Assoziation, die Namen wie "Extreme Programming" auslösen sicher nicht "Disziplin", dennoch erfordern alle agilen Verfahren im Alltag ein hohes Maß an Sorgfalt, Engagement und Motivation.

Was man beachten sollte, wenn man darüber nachdenkt, agile Prozesse zu etablieren, möchten wir im Folgenden kurz zusammenfassen.

Rahmenbedingungen
Es gibt sicher Umgebungen, in denen Agilität zumindest aus Investitionssicht keinen Mehrwert schafft.
Grundsätzlich gilt, dass agile Prozesse in dem Maße sinnvoll sind, in dem die Anforderungen an die zu entwickelnden Softwaresysteme veränderlich sind, in dem Maße also, in dem Flexibilität erforderlich ist. Wissen Sie bereits heute alles, was es über die von ihnen benötigte Software jemals zu wissen geben wird, können Sie also eine ewig gültige Spezifikation schreiben, so ist ein Prozess, der auf Veränderung als Chance begreift und sich entsprechend aufstellt mit großer Wahrscheinlichkeit nicht angebracht.

Jenseits dieser seltenen statischen Szenarien gilt es dennoch einige Rahmenbedingungen zu beachten:
Die Kommunikationswege zwischen Kunden und Entwicklungsteam müssen kurz gehalten werden, Extreme Programming kennt sogar das Konzept eines "Onsite Customers", der direkt ins Entwicklungsteam eingebunden wird.
Generell sollten alle Beteiligen mit dem angestrebten Prozess einverstanden sein. Nur so kann das von allen Seiten nötige Engagement im Rahmen der Einführung und Anpassung agiler Vorgehensmodelle garantiert werden.
Neben der Unternehmenskultur werden feste Rahmenbedingungen wie etwas QM-Richtlinien und Zertifizierungen die Auswahl geeigneter Verfahren und Prozessbausteine beeinflussen.

Die Eignung agilen Vorgehens für Festpreisprojekte wurde und wird immer wieder kontrovers diskutiert. Man kann wohl zusammenfassend sagen, dass diese Art von Verträgen nicht die ideale Grundlage ("Customer collaboration over contract negotiation") für agile Projekte darstellen, bei sorgfältiger Vorbereitung aber kein Ausschlusskriterium sein müssen.

Das agile Team
Wichtigster Bestandteil aller agilen Prozesse ist jedoch das Entwicklungsteam selbst.
Anders als konventionelle, stark strukturierte Prozesse erfordern Methoden, die sich am Manifest ausrichten in der Regel eine deutlich aktivere Beteiligung sowohl in Form von eigenverantwortlichem Handeln als auch in Form konkreter Prozessausgestaltung.
Agile Teams organisieren sich in der Regel mithilfe eines Coaches selbst. Sie sind auf effiziente Kommunikation sowohl unter den Teammitgliedern als mit den übrigen Beteiligten angewiesen.

Zwar gibt es kein Patentrezept für die Zusammenstellung agiler Teams, betrachtet man aber alle Faktoren, lässt sich festhalten, dass agile Verfahren einfacher anzuwenden sind, wenn bestimmte Kriterien erfüllt sind:
Kleine, räumlich konzentrierte Teams mit einem hohen Anteil erfahrener Entwickler und einem hohen Maß an gegenseitigem Vertrauen werden in der Regel die wenigsten Schwierigkeiten damit haben, einen agilen Prozess mit Leben zu füllen. Letztlich kommt es aber in jedem Fall darauf an, das Vorgehensmodell passend auszugestalten - die Erfahrung zeigt, dass selbst scheinbar unmögliche Bedingungen Agilität nicht zwangsläufig ausschließen.

Unser Fazit

Wir glauben, dass viele Java-Enterprise-Projekte von agilen Praktiken profitieren können. Der Schlüssel zum Erfolg liegt in der Berücksichtigung der Rahmenbedingungen und der Auswahl und Anpassung geeigneter Verfahren. Agile Softwareentwicklung lässt sich nur in der Praxis erlernen und kann Teams gerade in der Einführungsphase vor erhebliche Herausforderungen stellen.

OPITZ CONSULTING unterstützt Sie bei der Analyse der Wirtschaftlichkeit, der Auswahl und Einführung sowie bei der Optimierung agiler Methoden zur Softwareentwicklung, wobei die Beratungs- und Coachingleistungen zu jeder Phase eines Projektes erbracht werden können. Vor der möglichen Durchführung einer Softwareentwicklung erfolgt zunächst eine Nutzwertanalyse im Vergleich mit konventionellen Ansätzen und eine Bewertung der Vollständigkeit und Eindeutigkeit sowie Machbarkeit der Anforderungen.

Des Weiteren werden die Risiken untersucht und beurteilt und vor allem auch die Auswirkungen auf spätere Ergänzungen, Änderungen oder die Wartbarkeit der Systeme analysiert. Im nächsten Schritt werden geeignete Tools unter Berücksichtigung der vorhandenen IT-Infrastrukturen, der ermittelten Anforderungen und etwaiger Präferenzen des Kunden vorgeschlagen.

Sofern das notwendige Wissen zum Einsatz der Werkzeuge und Methoden beim Kunden noch nicht vorhanden ist, übernimmt OPITZ CONSULTING das Coaching und die Schulung der Softwareentwickler. Auf Wunsch unterstützen erfahrene Projektmanager und -leiter den Entwicklungsprozess und tragen mit der notwendigen Methoden- und Sozialkompetenz dazu bei, dass die Akzeptanz des neuen Entwicklungsparadigmas von Anfang an in hohem Maße gegeben ist.

>> zurück nach oben

Druckansicht

PDF

Weiterempfehlen