Agile Softwareentwicklung

Das agile Vorgehen in der Softwareentwicklung ist eine Alternative zu den traditionellen Softwareentwicklungsprozessen [wie z. B. Rational Unified Process (RUP) oder dem V-Modell], die zunehmend als schwergewichtig, dokumentenlastig und bürokratisch angesehen werden. Agile Prozesse verfolgen einen anderen Ansatz. Aber was bedeutet eigentlich „agil"? Und was ist die Zielsetzung dabei? Welche Werte, Prinzipien und Methoden charakterisieren einen solchen Entwicklungsprozess? Welche Ansprüche hat ein agiles Prozedere an die Projektbeteiligten? Und mit welchen Problemen kämpfen agile Projekte? Dieser Artikel gewährt Einblicke in das Prinzip der agilen Softwareentwicklung.

Zielsetzung

Ziel der agilen Softwareentwicklung ist es, den Softwareentwicklungsprozess zu optimieren. Grundsätzlich soll dies durch die Verschlankung des gesamten Prozesses erfolgen. Dafür rückt die agile Softwareentwicklung die Projektziele, den Kunden, sowie die Werte, Prinzipien und Methoden für die Zielerreichung in den Mittelpunkt. Wichtigstes Ziel im gesamten Prozess ist eine funktionierende Software für den Kunden und die erfolgreiche Integration wechselnder Anforderungen an diese Software.

Diesem Ziel ist alles andere untergeordnet, wie z. B. eine möglichst detaillierte Planung, vollständige Spezifikationen, umfassende Dokumentationen oder eine ausgereifte, technisch einwandfreie Architektur. Ein agiler Prozess ist sehr kommunikationsintensiv, soll leicht umzusetzen und flexibel anzupassen sein, er soll leichtgewichtig und dynamisch ablaufen.

Probleme traditioneller Softwareentwicklung

Wie kommt es zu dieser „neuen“ Form der Softwareentwicklung? Nur weil ein Vorgehen bürokratisch ist, muss es nicht unbedingt schlecht sein. Ein entscheidender Kritikpunkt an den traditionellen Softwareentwicklungsverfahren ist die fehlende Flexibilität. Die Praxis zeigt oft genug, dass die Anforderungen einem ständigen Wandel unterworfen sind. An dieser Stelle sind klassische Phasenmodelle sehr träge.

Nach Abschluss der Analyse-, spätestens der Designphase können z. B. beim Wasserfallmodell keine Anforderungsänderungen mehr eingebracht werden. Die Lösung lautet dann Change-Request-Verfahren, deren Beginn am ursprünglichen Projektende liegt. Mit der Version 1.0 bekommt der Kunde eigentlich nicht, was er will, sondern das, was im Vertrag steht. Daher gilt als Leitsatz für agile Methoden: „Je mehr du nach Plan arbeitest, um so mehr bekommst du das, was du geplant hast, aber nicht unbedingt das, was du brauchst“.

Agiles Manifest

Im Februar 2001 hat die Agile Alliance ihre Vorstellungen von agiler Softwareentwicklung als so genanntes „Agiles Manifest“ formuliert. Die Grundprinzipien des agilen Manifests zeigt Abbildung 1. Hinter den Leitsätzen verbergen sich zahlreiche agile Werte. Auf den Werten als Fundament basieren wiederum Handlungsgrundsätze, die als agile Prinzipien bezeichnet werden. Agile Methoden sind konkrete Verfahrensweisen während der Softwareentwicklung, die sich auf die festgelegten Werte und Prinzipien stützen. Die Grenzen zwischen Werten, Prinzipien und Methoden sind fließend und nicht immer genau abgrenzbar.

Abb. 1: Grundprinzipien des Agilen Manifests. Natürlich sind auch die Aspekte auf der rechten Seite wichtig, grundsätzlich genießen aber die auf der linken Seite aufgeführten Vorrang.

Funktionierende Software

Betrachten wir einen Grundsatz aus dem Agilen Manifest exemplarisch etwas genauer: Warum ist die Forderung nach funktionierender Software das wichtigste Ziel bei der agilen Softwareentwicklung? Während die aufgewendete Zeit als negatives Maß für die Produktivität und der Umfang von Modellen, Dokumentationen und Plänen als Maß für die Schwerfälligkeit angesehen werden, wird der Projektfortschritt am Umfang funktionierender Software gemessen. Ferner kann nur funktionierende Software regelmäßig an den Kunden übergeben werden, um zeitnahes Feedback zu bekommen. Da der Kunde fester Bestandteil des Teams ist, wird an dieser Stelle bewusst von Übergeben und nicht von Ausliefern gesprochen. Der Kunde ist fest in den Entwicklungsprozess integriert, liefert schnelle Entscheidungen und klärt fachliche Probleme. Ein „befragbarer“ Kunde ersetzt Teile der Spezifikation.

Iterationen

Die Entwicklung funktionierender Software erfolgt in mehreren Zyklen, den so genannten Iterationen. Die gesamte Konstruktionsphase ist in kurze, aufeinander folgende Iterationen aufgeteilt. Die klassischen Phasen in der Softwareentwicklung wie Modellierung (Analyse und Entwurf) und Entwicklung (Implementierung und Testen) sind Bestandteil eines jeden Zyklusses. Abbildung 2 zeigt den Inhalt einer Iteration mit den entsprechenden Tätigkeiten. Der gesamte Entwicklungsprozess besteht aus mehreren Iterationen.

Abb. 2: Iteration mit den einzelnen Aktivitäten in der Entwicklungsphase. Die Iterationen dauern typischerweise 1 - 3 Monate.

Auf diese Weise wird die Software iterativ und inkrementell entwickelt. Iterativ bedeutet in diesem Zusammenhang die Zerlegung der Entwicklung in mehrere, gleichartige Schritte. Jede Iteration erzeugt ein funktionsfähiges Teilergebnis. Inkrementell bedeutet, dass die Gesamtfunktionalität des Systems mit jeder Iteration wächst. Der Effekt ist logisch: Software wird schnell an den Kunden ausgeliefert, funktionierende Software wird damit erzwungen.

Werte und Prinzipien

Am Ende jeder Iteration existiert fertige und testbare Software. Für jedes Release existieren Abnahme- und Akzeptanztests, die fester Bestandteil jeder Iteration sind (siehe Abbildung 2). Aufgabe des Kunden nach Abschluss einer Iteration ist es, den aktuellen Stand zu begutachten und eine Rückmeldung an Projektleitung und Entwicklung zu geben. Feedback ist ein zentraler Wert in der agilen Welt. Fehlentwicklungen, z. B. falsche oder unzureichende Umsetzung von Workflows, Mängel an der Benutzeroberfläche, mangelnde Stabilität oder Performance, aber auch zusätzliche, neue Anforderungen können zeitnah erkannt und in nachfolgenden Iterationen korrigiert bzw. umgesetzt werden.

In vielen Projekten sind zu Beginn, und selbst in der Implementierungsphase, Anforderungen unklar. Der Kunde weiß noch nicht genau, was er will, hat widersprüchliche oder unvollständige Anforderungen oder diese sind nicht allen Projektbeteiligten bekannt. Bei soviel Ungewissheit empfiehlt sich eine möglichst einfache Implementierung. Ein funktionierendes Mini-Design, das wächst und über Refactoring angepasst und verbessert wird, ist einem aufwändigen Architekturentwurf vorzuziehen.

Auf diesem agilen Wert der Einfachheit basieren die beiden einprägsamen Prinzipien KISS (Keep It Stupid And Simple) und YAGNI (You Aren’t Gonna Need It). Nur aktuelle Probleme werden möglichst einfach gelöst und nur aktuelle Anforderungen werden umgesetzt. Beide Handlungsgrundsätze helfen dabei zu vermeiden, heute viel zu investieren, um später eventuell doch nichts davon zu nutzen.

Methoden

Agile Methoden dienen dazu, agile Werte und Prinzipien praktisch umzusetzen. Daher haben viele Methoden eher technischen Charakter. Die folgenden Praktiken stammen weitgehend aus dem Bereich „Extreme Programming“ (XP).

So genannte Nightly Build‘s sorgen dafür, dass die Entwickler täglich auf fehlerhaften Quellcode hingewiesen werden. Zudem können so in kurzen Abständen automatisch auslieferbare Versionen gebaut werden.

Pair-Programming bezeichnet ein Verfahren, bei dem während der Erstellung des Quelltextes jeweils zwei Programmierer gemeinsam an einem Rechner arbeiten. Ein Programmierer schreibt den Code, während der andere über die Problemstellungen nachdenkt, den geschriebenen Code kontrolliert, sowie alle Probleme, die ihm dabei auffallen, sofort anspricht. Diese Art der Programmierung fördert das Prinzip der gemeinsamen Verantwortung (collective code ownership).

Testmethoden und -verfahren nehmen eine ganz wichtige Rolle im Bereich der agilen Softwareentwicklung ein. Testen bedeutet nicht nur, dass es überhaupt automatisierte Tests gibt, sondern dass ein Test sogar vor der eigentlichen Implementierung dessen, was es zu testen gilt, geschrieben wird. Ein solcher Test ist damit gleichzeitig auch Spezifikation. Aufgabe des Entwicklers ist es nur noch, Code zu implementieren, so dass der Test durchläuft und z. B. bei Einsatz von JUnit aus roten Balken grüne werden.

Die agile Szene bezeichnet diese Methode als testgetriebene Entwicklung (Test-Driven-Development). Bei den Methoden darf zumindest der Hinweis auf regelmäßige Strukturverbesserungen (Refactoring) und gemeinsame Reflektion (Code-Reviews) von Quellcode nicht fehlen.

Erfolgsfaktor Mensch im agilen Team

Viele Probleme in Entwicklungsprojekten sind nicht technischer, sondern vielmehr menschlich-sozialer Natur. Gepaart mit der Eigenschaft agiler Prozesse, dass eine detaillierte, starre Planung eher zweitrangig ist, erfordert agil zu sein hohe Ansprüche an die Projektbeteiligten hinsichtlich ihrer Fach- und Sozialkompetenz. Neben der fachlichen Qualifikation gewinnen die so genannten Soft-Skills herausragende Bedeutung:

• Aktivität:
  Initiative ergreifen, kein Minimalist sein, handeln statt abwarten, Verantwortung für die Projektziele übernehmen.
  
  
• Disziplin:
  Ausgeprägte Selbstdisziplin, vereinbarte Grundregeln einhalten (z. B. Programmierrichtlinien, Tests und Code-Reviews durchführen, etc.).
  
  
• Gemeinnützigkeit:
  Statt Egoismus zum Wohl des Teams beitragen, nicht nur den eigenen Code in Schuss halten, keine „Star-allüren“ an den Tag legen.
  
  
• Kommunikation:
  Offen, klar und sachlich seine Meinung vertreten, Fehler konstruktiv ansprechen, Informationen breit streuen und Know-how austauschen.
  
  
• Dynamik:
  Veränderungen und Verbesserungen mittragen und fördern. Bereit sein, den komfortablen Status quo aufzugeben, alte Gewohnheiten abzulegen und neue Wege auszuprobieren.
  
  
• Selbstkritik:
  Eigene Fehler nicht unter den Tisch kehren und die Hilfe anderer Teammitglieder in Anspruch nehmen. Voraussetzung dafür ist eine vertrauens- und respektvolle Atmosphäre im Team.
  
  
• Courage:
  Vertraue darauf, Probleme die morgen auftreten, auch morgen lösen zu können. Zwinge dich nicht, sie bereits heute lösen zu müssen.

Vorbehalte und Trugschlüsse

Agil zu sein bedeutet nicht,

... undiszipliniert zu sein. Statt Unordnung und Anarchie vertrauen agile Teams auf die Eigenverantwortung und einen hohen Grad an Selbstdisziplin jedes Einzelnen. Das Team reguliert sich weitgehend selbst.

... auf Planung zu verzichten und nur kurzfristig die nächste Iteration zu sehen. Wichtig ist vielmehr, Planung im richtigen Maß und zum richtigen Zeitpunkt zu betreiben. Planung ist keine Aktivität am Anfang eines Projekts, sondern ein Dauerzustand. Die Auseinandersetzung mit den Projektzielen und deren Erreichbarkeit ist eine kontinuierliche und tägliche Aufgabe. Pläne werden immer wieder der Realität angepasst, um das bestmögliche Ergebnis für den Kunden zu erzielen.

..., dass es keine Dokumentation gibt. Dokumente werden nur erzeugt, wenn sie direkten Nutzen bringen. Statt um des Prozesses Willen oder auf Vorrat sehr viel an Dokumentation zu erzeugen, wird nur das dokumentiert, was gebraucht wird.

... einem festgelegten Prozess zu folgen. Agile Prozesse funktionieren nicht nach einem vorgegebenen, konstanten Schema. Eine der wenigen Konstanten in Softwareprojekten ist die Veränderung. Rahmenbedingungen, Teams, Techniken und insbesondere Anforderungen verändern sich ständig. Der Prozess wird an diese Veränderungen kontinuierlich angepasst. Vorgehensweisen, die sich als unpraktisch oder kontraproduktiv herausstellen, werden fallen gelassen.

Probleme und Fallstricke

Problematisch sind große, agile Projekte. Die Projektgröße (Projektumfang, -dauer, -kosten, -risiken etc.) als solches ist natürlich immer relativ. Entscheidend ist hier oft, wie aufwendig die Kommunikation wird. In Projekten mit zunehmender Personenzahl wird auch die direkte (!) Kommunikation immer schwieriger. Kommunikation muss ab einer bestimmten Größe koordiniert werden und läuft immer häufiger asynchron ab.

Das aktive Mitwirken des Kunden setzt natürlich voraus, dass der Kunde auch kompetent, verfügbar und ansprechbar ist. Es gibt sicherlich einfachere Aufgaben als einen Kunden davon zu überzeugen, Ansprechpartner aus seiner Fachabteilung dauerhaft für ein Entwicklungsprojekt abzustellen. Für die dann ausgewählten Personen bedeutet dies einen gravierenden Einschnitt in ihren Berufsalltag. Sie arbeiten jetzt nicht mehr in ihrem anvertrauten Fachbereich, sondern müssen in einer ihnen fremden Domäne mit Beratern, IT-Experten und Projektleitern zusammenarbeiten.

Gegen agile Projekte wird oft argumentiert, sie seien für Festpreisverträge nicht geeignet. Bei diesem Vertragsmodell müssen vor der Auftragsvergabe die Anforderungen nahezu vollständig spezifiziert sein und während des Projekts möglichst stabil bleiben. Dieses Szenario widerspricht im Kern der Idee agiler Vorgehensweise. Deshalb empfiehlt es sich bei agilen Projekten, jeweils für einzelne Meilensteine einen Festpreis zu vereinbaren.

Die Umsetzung testgetriebener Entwicklung bereitet gerade Programmierern ohne Erfahrung einige Schwierigkeiten. Sie fragen sich, wie man etwas testen soll, das noch nicht vorhanden ist. Eine genauere Ursachenforschung, warum nicht getestet wird (z. B. Zeitmangel, zusätzlicher Aufwand, Funktionalität ist oft wichtiger als Qualität) ist an dieser Stelle zweitrangig. Wichtiger ist es, sich bewusst zu machen, dass bei fehlenden Tests und bei mangelnder Testabdeckung der gesamte agile Prozess gefährdet ist. Die Softwarearchitektur in agilen Projekten ist stets änderbar und wächst kontinuierlich von Iteration zu Iteration. In Folge von Code-Reviews und Refactoring wird der Quellcode praktisch ständig verändert, mit dem Ziel, die strukturelle Qualität zu erhöhen. Diese Änderungen können nur mit automatisierten, wiederholbaren Tests geprüft werden, um die funktionale Qualität zu erhalten.

Fazit

Agile Entwicklung ist auf dem Vormarsch. Einer Studie des amerikanischen Forschungsinstituts Forrester Research zu Folge entwickeln bereits 14 Prozent aller Unternehmen in den USA und in Europa agil, weitere 19 Prozent denken über den Umstieg auf agile Vorgehensweisen nach [1]. Zu den 14 Prozent zählen auch Kunden der ORDIX AG, wodurch wir als Dienstleister über mehrjährige Erfahrungen im Bereich der agilen Softwareentwicklung verfügen.

Ingo Vogt (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen