Agile Softwareentwicklung ist ein evolutionärer, hochgradig kollaborativer und qualitätsorientierter Ansatz bei dem die Fähigkeit, zu jedem Zeitpunkt funktionstüchtige Software ausliefern zu können, im Mittelpunkt steht. Viele unterschiedliche Variationen agiler Prozesse haben sich im Laufe der letzen Dekade herausgebildet. Die wichtigsten sind Scrum, eXtreme Programming (XP), Open Unified Process (OpenUP) und Agile Data. All diese Formen sind anwendbar auf unterschiedlichste Softwareprodukte und nicht beschränkt auf eine Disziplin, beispielsweise Web oder Desktop Applications. Das gleiche trifft auf die Unternehmen und Organisationen zu, die sich für einen oder mehrere der Prozesse entschieden haben. Agile Softwareentwicklung ist ein allgemeingültiger Ansatz für alle Softwareprojekte und Organisationen.

Agile Entwicklungsmethoden haben die Industrie im Sturm erobert. Das liegt hauptsächlich daran, das es einfach funktioniert: höhere Erfolgsraten, bessere Qualität, gesteigerte Kundenzufriedenheit, besseres ROI (Return On Investment) und schnellere Markteinführung (Time To Market).

In diesem Artikel beginnen wir mit einer allgemeinen Betrachtung des Agilen Prozessmodells um die unterschiedlichen Ansätze in den richtigen Kontext setzen zu können. Anschießend betrachten wir das vorgestellte dreistufige Modell genauer und erfahren wie die drei aufeinander aufsetzen. Zum Abschluß wenden wir das Modell beispielhaft auf die Entwicklung einer Software an und enden mit einigen Hinweisen für eine erfolgreiche Einführung agiler Softwareentwicklung.

Das agile Prozessmodell

Im Zusammenhang mit Softwareprojekten und damit verbundenen Prozessen wird immer wieder von Maturity gesprochen. Daß es sich dabei um einen inzwischen überladenen Begriff handelt ist nicht Verdienst der exzellenten Arbeit des Software Engineering Istitute (SEI) der Carnegie Mellon University, die das Capability Maturity Model Integrated (CMMI) entwickelt hat und eine Abwandlung speziell für die Durchführung von Softwareprojekten CMMI-DEV hervorbrachte. Vielmehr wurde der Begriff Maturity auf die Prozessoptimierung angewandt, während das hier vorgestellte Agile Process Maturity Model (APMM) vielmehr bemüht ist, einen Rahmen für die agile Softwarenentwicklung zu stellen, so daß die unterschiedlichen Methoden in den richtigen Kontext gesetzt werden können. Wir könnten auch sagen: das APMM ist das schlanke Geschwister vom CMMI.

Wie angedeutet ist APMM ein dreistufiges Modell dessen Ebenen aufeinander aufsetzen:

Die drei Stufen sind folgendermaßen zu verstehen:

Level 3: Scaling Agility

Stufe 3 konzentriert sich auf einen wichtigen Skalierungsfaktor in agilen Prozessen, beispielsweise Teamgröße oder der Grad der geographischen Verteilung des Teams. Es muß sich dabei aber nicht immer um eine quantitative Größe handeln, denn auch der Einfluß von Regulatorien oder der Grad der Einhaltung von Standards sind skalierend Faktoren in agilen Entwicklungsprozessen.

Level 2: Disciplined Agility

In Stufe 2 schauen wir über den Tellerrand hinaus und decken den gesamten Software Delivery Life Cyle (SDLC) ab. Beispiele sind Dynamic System Development Method (DSDM) und OpenUP (Open Unified Process).

Level 1: Agile Software Development

Stufe 1 betrachtet nur einen kleinen Teil des gesamten Entwicklungsprozesses, da nur die agilen Aspekte des Manifestos von Bedeutung sind. Beispiele sind Scrum oder XP.

Das Modell mag zum jetzigen Zeitpunkt noch nicht besonders einleuchtend sein. In den folgenden Abschnitten beleuchten wir jede Stufe genauer und gehen immer wieder auf die Bedeutung im APMM ein.

Stufe 1: Agile Software Development

Die agilen Methoden auf Stufe 1 decken nicht den gesamten SDLC ab, sondern orientieren sich an den Werten des Agile Manifesto und vestehen sich als eine ganzheitliche Sammlung von empfohlenen Vorgehensweisen. Beispiele für die Implementierung der Stufe 1 sind die bekannten Vertreter:

Scrum

Projekt- und Anforderungsmanagement sind die Stützpfeiler von Scrum. Mittels Iterationen (Scrum spricht von Sprints) werden Zyklen zur Produktreifung definiert. Gepaart mit diversen Praktiken wie täglichen Stand-Up Meetings, Verwendung von Product Backlogs und klaren Rollen wie beispielsweise ScrumMaster und Product Owner entsteht ein Planungsgerüst, welches ganz nach Definition durch das Manifesto auf die Erstellung lauffähiger Software ausgerichtet ist. Abbildung 2 zeigt den Scrum Life Cycle.

Extreme Programming (XP)

XP ist eine Sammlung von Praktiken für die Softwareentwicklung, mit Fokus auf Programmiertechniken. Beispielsweise sind Pair Programming (zwei Entwickler an einem Modul gleichzeitig), Test-First Design (erst der Unit Test, dann die Implementierung) und Continuous Integration einige der propagierten Techniken für die Softwareentwicklung mit XP. Darüber hinaus bekennt sich auch XP zu Dingen wie Collective Ownership um die Bedeutung selbstorganisierender Teams herauszustellen.

Agile Data

Datenlastige Anwendungen erfordern oftmals andere Herangehensweisen als beispielsweise Steuerungssysteme. Für solche Fälle eignet sich Agile Data sehr gut, da hier nicht nur die Organisation und Entwicklungstechniken betrachtet werden, sondern auch die Modellierung, Datenbanktest und Database Refactoring.

Stufe 2: Disciplined Agility

Auf Ebene zwei wird der agile Prozess von Stufe 1 erweitert und berücksichtigt den gesamten SDLC. Der wesentliche Unterschied zu Stufe 1 ist die Berücksichtigung einzelner Aspekte des Prozesses (nicht der Techniken oder Technologien), beispielsweise Testing oder Process Improvement. Ganz typisch handelt es sich bei Discplined Agility auch um einen evolutionären, iterativen Entwicklungsansatz zur Produktion hochqualitativer Software, der sich durch den Einsatz von Risiko- und Value-Driven Management { Value-driven Managment bedeutet in diesem Zusammenhang, die aktuellen Marktentwicklungen während des gesamten SDLC immer wieder zu bewerten um sicherzustellen, daß ein gewinnbringendes Produkt entsteht, welches auf dem Markt bestehen kann. } auszeichnet.

Disciplined Agility vertraut auf qualifizierte und selbstorganisierende Teams, die von einer frühzeitigen und starken Einbindung der Auftraggeber profitieren. Auf diese Weise kann das Team die Anforderungen des Auftraggebers besser verstehen und auf Veränderungen schneller reagieren. Auf der anderen Seite ist der Entwicklungsprozess transparent und kann jederzeit vom Auftraggeber durch aktive Mitwirkung, beispielsweise in Form häufigen Feedbacks, korrigiert werden.

Beispiele für agile Prozesse der Stufe 2 sind:

Open Unified Process (OpenUP)

OpenUP erweitert und kombiniert bekannte Praktiken aus Scrum, XP, AD und RUP für die Anwendung auf verteilte, virtuelle Teams. Dabei werden Methoden wie Whole Team, Stand-Up Meetings, Risikomanagement, TDD, aktive Einbindung der Auftraggeber und Continuous Integration angewandt. OpenUP ist ein Open Source Framework, das Teil des Eclipse Process Framework ist.

Rational Unified Process (RUP)

RUP ist ein umfassendes Rahmenwerk für Prozesse in der Softwareentwicklung, das unterschiedlich ausgeprägt werden kann, je nachdem wie die es die aktuelle Situation erfordert. Eignet sich für sehr agile wie auch traditionelle Ansätze gleichermaßen. Es deckt die Praktiken Risk Management, Whole Team, TDD, Business Process Sketching und Continuous Integration ab.

Dynamic System Development Method (DSDM)

DSDM eignet sich besonders für Applikationen mit komplexen Benutzeroberflächen. Es ist ein agiler Ansatz, der von Rapid Application Development abgeleitet wurde und sehr stark auf Rapid Prototyping, Testing, Machbarkeitsstudien und Reversible Changes setzt.

Feature-Driven Development (FDD)

FDD zeichnet sich durch den Einsatz von Modellierungstechniken und kurzen Iterationen aus. Zu den typischen FDD-Praktiken gehören Class Ownership (PDF), Domain Object Modeling, Development by Feature, Feature Teams und regelmäßige Übersetzungen der Software (Regular Builds). Eine ausgezeichnete Kurzbeschreibung von FDD findest Du unter The Coad Letter: Issue 70.

Eine akstrahierte Darstellung eines vollständigen SDLC wird in Abbildung 3 dargestellt. Als Beispiel erweitern wir Scrum um wichtige Aspekte des SDLC, denn zum ersten wird eine explizite Projektgründungsphase (Project Inception) allen anderen Aktivitäten vorangestellt, in der wir erste Modelle konstruieren, das Team bilden und die finanzielle wie auch institutionelle Unterstützung des Auftraggebers sichern. Zum zweiten integrieren wir unabhängige Tests, um sicherzustellen, daß Fehler nicht durchs Raster fallen, was insbesondere auf nicht-funktionale Merkmale und Integrationstest zutreffen kann. Die nächste Erweiterung von Scrum betrifft das Product Backlog, das nicht nur priorisierte Aufgabenelemente berücksichtigt, sondern auch Tätigkeiten wie die Teilnahme an Trainings (auch zu fachfremden Disziplinen), Feedback zu Arbeiten anderer Teams und die Bewertung von Fehlern sowie deren Einordnung in das Backlog. Das letzte Merkmal des beschriebenen agilen SDLC ist die ausdrückliche Einführung einer Übergangs- und Produktionsphase (Release to Manufacturing).

Stufe 3: Berücksichtigung von spezifischen Faktoren

Zu Beginn der agilen Bewegung wurden die Praktiken zunächst auf kleinere überschaubare Projekte angewandt und relativ pragmatisch angegangen. Heutzutage wenden Organisationen agile Methoden auf ein weitaus größeres Wirkungsspektrum an. Agilität der Stufe 3 berücksichtigt die Komplexität der Projekts in Bezug auf bestimmte Faktoren, die wie Skalierungen angewandt werden können. Folgende Tabelle faßt einige Faktoren zusammen, die Auswirkung auf die Komplexität eines Projekts haben.

einfach	Faktor	komplex
weniger als 10 Teammitglieder	Teamgröße	hunderte von Teammitgliedern
räumliche Nähe	geographische Verteilung	global verteilt
geringes Risiko	Compliance	kritisch / wird auditiert
offen	Organisation und Kultur	fest verwurzelt
In-House	Verteilung der Organisation	Third-Party
informell	Governance	formell
einfach, eine Plattform	Anwendungskomplexität	komplex, mehrere Plattformen
Projektfokus	Unternehmensausrichtung	Fokus auf das Unternehmen

Jedem Faktor ist eine Komplexitätsskala zugeordnet und jedes Team wird eine andere Kombination aufweisen, so daß der Prozess, die Teamstruktur und die Werkzeuge den Rahmenbedingungen angepaßt werden müssen. Agile Prozesse der Stufe 1 im APMM funktionieren am besten wenn alle Faktoren in der Skala auf der linken Seite liegen (eine geringe Komplexität aufweisen.) Prozesse der Stufe 2 zeichnen sich durch einen oder mehrere Faktoren aus, deren Komplexität entweder in der Mitte oder auf der rechten Seite der Skala liegen. Liegen fast alle Faktoren auf der rechten Seite wird der Entwicklungsprozess extrem komplex und bedarf spezieller Werkzeuge zur Koordinierung verteilter Teams, Metriken zur Überwachung der Compliance und Berater, die auf beispielsweise auf Risikomangement und andere geschäftsspezifische Disziplinen spezialisert sind.

Während Stufe 1 und Stufe 2 tatsächlich als eigenständige Prozesse charakterisiert werden können, ist die Stufe 3 als Leitfaden für die Bewertung der Projektkomplexität mittels einer einfachen Skala gedacht. Letzendlich wirken sich die Erkenntnisse aus Stufe 3 auf den Prozess der Stufe 2 dahingehend aus, daß bestimmte Schritte/Abläufe unterschiedlich gewichtet sind und einer eigenen internen Analyse unterzogen werden, um dem identifizierten Komplexitätsgrad in diesem Bereich gerecht zu werden.

Was bedeutet das für die Praxis?

In der Praxis wird in fast allen agilen Methoden aus Stufe 1 eine Projektinitiierung durchgeführt, allerdings nicht immer explizit mit der klaren Zielsetzung, die Finanzierung des Projekts zu sichern und ausführlich Zeit für eine Definition der initialen Anforderungen und der gewünschten Vorgehensweise einzuplanen (Länge der Iterationen, Zusammenstellung des/der Teams, Wahl des Prozessmodells, etc.). Es ist nicht unüblich zwischen ein bis zwei Wochen dafür anzusetzen.

Im Idealfall nehmen daran Teil:

• die Auftraggeber: Product Manager/Owner, Business Owner und Process Owner
• die Auftragnehmer: Key Account Manager und Business Consultant, Senior Developers, CTO

An der Zusammensetzung sehen wir schon, daß wir nicht nur das Ziel haben, die Anforderungen zu verstehen, sondern auch Risiken zu minimieren, was primär durch die Vertreter der Auftraggeber garantiert wird, die in diesem Beispiel teilweise redundant sind, dadurch aber jeweils eine eigene Sicht auf mögliche Risiken ermöglichen.

Parallel dazu entwerfen CTO und die Senior Developers eine vorläufige, grobe Architekture, identifizieren Subsysteme und Schnittstellen und tragen wichtige Informationen zur Aufteilung der Arbeit auf das oder die Teams zusammen. Je nach Schwerpunkt des Produkts sind die Business Consultant beispielsweise auf Compliance in regulierten Umgebungen spezialisiert oder sind externe Berater zum Thema Baurecht, weil das Endprodukt eine Software für Ausschreibungen in der Baubranche ist.

Der Product Owner (erfahrungsgemäß oftmals Product Manager des Auftraggebers) priorisiert die Anforderungen und versorgt die Teammitglieder mit Details über Geschäftsprozesse. Er/Sie wird dabei von den Business Ownern und/oder Process Ownern unterstützt.

Nachdem die erste Iteration (Inception) vorbei ist, wird in der zweiten der Fokus auf die Entwicklung eines Proof of Concepts gelegt um zu zeigen, daß die gewählte Architektur tatsächlich funktioniert. Am Ende der Iteration wird dem Auftraggeber das Ergebnis präsentiert, wobei sich das Team hier ausschließlich auf die Demonstration der kritischen Systemeigenschaften konzentriert. Beispielsweise könnte eine kritische Anforderung sein, daß eine Anwendung 5.000 Transaktionen pro Minute bei durchschnittlich zehn angemeldeten Benutzern für mindestens 24 Stunden verarbeiten können muß.

Durch die richtige Wahl der Teammitglieder und einer ausführlichen Projektgründungsphase konnte das Gesamtrisiko des Projekts drastisch reduziert werden, weil zum einen die Anforderungen richtig verstanden wurden und demonstriert werden konnte, daß die kritischste Komponente den ersten Test bestanden hat.

Was die Projektkommunikation betrifft, ist es stets empfehlenswerte eine Single Point of Communication Strategie zu verfolgen. In Bezug auf Projektkoordination, Ressourcenplanung usw. kommunizieren zwischen Auftragnehmer und Auftraggeber lediglich Key Account Manager (Auftragnehmer) und Product Manger (Auftraggeber). Fachspezifische Themen koordiniert die Teamleitung mit den Business Consultants auf Auftragnehmerseite und den Business und Process Ownern auf Auftraggeberseite. Idealerweise, aber praktisch leider kaum durchführbar, sind die Business und Process Owner stets verfügbar und nehmen an täglichen Meetings teil. Besonders in komplexen Projekten mit hohem Risiko ist dieser Punkt obligatorisch.

Technische Fragen beantwortet die Senior Developer und der CTO in täglichen Meetings.

Abschließende Gedanken

Viele Organisationen konnten ihre agilen Prozesse erfolgreich skalieren (Stufe 3) und Du kannst es auch. Wenn Du Dir treu bleibst und nicht der Rhetorik der Vertreter aus Stufe 1 erliegst ist das schon ein wichtiger Schritt. Du solltest versuchen, mindestens einen agilen Prozess der Stufe 2 zu etablieren, da der gesamte SDLC berücksichtigt wird und nicht nur ein Teil davon (nur die Konstruktionsphase). Sei darauf vorbereitet, daß Du Dich über kurz oder lang in einer Situation befinden wirst, in der Dein Prozess skalieren muß (Stufe 3) und das viele Teams unterschiedlich skaliert werden müssen. Mit einem realistischen, maßgeschneiderten Ansatz kann der ROI gesteigert, die Qualität erhöht und die Kundenzufriedenheit maximiert werden.