Agile Softwareentwicklung: Prinzipien und Methoden

Agile Softwareentwicklung (von lateinisch „agilis“, flink, beweglich) will Risiken und Fehlentwicklungen klein halten. Dazu versucht das Team, die Entwurfsphase auf ein Mindestmaß zu reduzieren und so früh wie möglich zu ausführbarer Software zu kommen. Diese Software wird in regelmäßigen, kurzen Abständen mit dem Kunden abgestimmt.

Die Arbeit läuft in Iterationen. In Extreme Programming (XP) dauern Iterationen üblicherweise zwischen einer und vier Wochen. In Scrum heißt der Abschnitt Sprint und dauert ein bis vier Wochen. Am Ende steht ein lauffähiger Zwischenstand. Man nennt das iterativ und inkrementell: Das Produkt wächst Stück für Stück.

Nach einer Iteration schauen sich zum Beispiel der Kunde oder andere Interessierte den aktuellen Stand an und geben Rückmeldungen. Dabei ist es denkbar, dass der Kunde neue Prioritäten setzt oder weitere Ideen einbringt. Außerdem reflektiert das Team in regelmäßigen Abständen, wie es effektiver werden kann, und passt sein Verhalten entsprechend an.

Im Februar 2001 wurden vier Leitsätze im Agilen Manifest formuliert. Funktionierende Software ist wichtiger als umfassende Dokumentationen. Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge. Die Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen. Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans. Die Verfasser finden die jeweils andere Seite auch wichtig, schätzen die genannten Werte aber höher ein.

So überträgst du das auf ein Softwareprojekt: Du teilst es in kurze Abschnitte, lieferst am Ende jedes Abschnitts etwas Lauffähiges und holst Rückmeldung ein. Das Beispiel unten ist ausgedacht.

Das Wasserfallmodell ist ein lineares (nicht iteratives) Vorgehensmodell mit aufeinanderfolgenden Projektphasen. Die Ergebnisse einer Stufe „fallen“ in die nächste und sind dort verbindliche Vorgaben. Der Benutzer ist in der Anfangsphase beteiligt. Weitere Änderungen stellen danach Neuaufträge dar. Erweiterungen des einfachen Modells (Wasserfallmodell mit Rücksprung) erlauben ein schrittweises Aufwärtslaufen der Kaskade.

Vorteile des Wasserfallmodells sind die klare Abgrenzung der Phasen, einfache Möglichkeiten der Planung und Kontrolle und eine klare Abschätzung von Kosten und Umfang bei stabilen Anforderungen. Es wird allgemein dort vorteilhaft angewendet, wo sich Anforderungen, Leistungen und Abläufe in der Planungsphase relativ präzise beschreiben lassen.

Nachteile: Es ist unflexibel gegenüber Änderungen. Das frühe Festschreiben der Anforderungen ist oft problematisch, da es eventuell zu teuren Änderungen führt. Das System wird sehr spät eingeführt. Weil das vollständige System auf einmal eingeführt wird, werden Fehler unter Umständen erst spät erkannt. Da größere Softwareprojekte meist eine sehr lange Laufzeit haben, kann die neue Software schon bei der Einführung inhaltlich veraltet sein.

Agile Methoden eignen sich besonders gut, um auf geänderte Anforderungen zu reagieren, da die Entwicklungszyklen in der Regel kurz angelegt sind. Die Anforderungen werden häufig nur knapp beschrieben und erst kurz vor Beginn von Umsetzung und Test ausformuliert. Dafür sind klare inhaltliche Vorgaben (Pflichtenheft) schwierig, da die Anforderungen per Definition erst zur Projektlaufzeit entwickelt werden. Bei XP kann die Fertigstellung eines gewünschten Funktionsumfangs zu einem gesetzten Termin nicht ohne weiteres garantiert werden.

Auch plangetriebene Vorgehensmodelle regeln, wie Änderungen berücksichtigt werden. Der Aufwand und die geforderte Dokumentation sind dabei aber vergleichsweise höher. Agile Methoden sind kein Allheilmittel: Hinderungsgründe wie Interessens- oder Zielkonflikte können für agile genauso wie für traditionelle Verfahren gelten. Für einen begründeten Vergleich nimmst du deshalb Kriterien wie in der Tabelle.

Scrum arbeitet in Sprints von ein bis vier Wochen. Die Anforderungen stehen in einer geordneten Liste, dem Product Backlog. Am Ende eines Sprints steht ein fertiges Teilprodukt, das Produktinkrement. Scrum schreibt drei Rollen vor: den Product Owner (verantwortlich für Eigenschaften und wirtschaftlichen Erfolg des Produkts), den Scrum Master (kümmert sich darum, dass Scrum gelingt, und um Hindernisse) und das Entwicklungs-Team. Zu Beginn jedes Arbeitstages gibt es ein Daily Scrum von höchstens 15 Minuten. Scrum ist für Teams von drei bis neun Entwicklern konzipiert. Nach Henrik Kniberg können während eines laufenden Sprints keine neuen Anforderungen an das Team gegeben werden.

Kanban stammt aus der Produktionssteuerung. Auf einem Kanban-Board stehen die Arbeitsschritte als Spalten. Jede Anforderung steht auf einer Karte oder Haftnotiz, einem Ticket, und wandert mit der Zeit von links nach rechts. Das WiP-Limit begrenzt, wie viele Tickets gleichzeitig in einer Aktivität bearbeitet werden. So wird sichtbar, wo sich Tickets stauen. Nach Henrik Kniberg sind in Kanban Iterationen optional, es gibt keine Rollen, und neue Anforderungen können zu jedem Zeitpunkt an das Team gegeben werden, falls Kapazitäten frei sind.

XP stellt das Lösen der Programmieraufgabe in den Vordergrund und misst einem formalisierten Vorgehen geringere Bedeutung zu. Zu den Praktiken gehören die Paarprogrammierung (ein Programmierer codiert als Driver, der andere denkt mit als Partner, die Rollen werden regelmäßig getauscht), die testgetriebene Entwicklung (erst die Tests, dann die Funktion) und die kontinuierliche Integration. Der Kunde muss während der gesamten Entwicklungszeit mit dem Team zusammenarbeiten und auf eine formale Festlegung der Projektinhalte verzichten. Die Teamgröße wird gemeinhin auf höchstens zehn Mitglieder gesetzt. In verteilten Umgebungen gilt XP als schwerer einsetzbar.

Bei der Auswahl hilft dir ein Merkmal der Lage. In Bereichen mit hohen Unsicherheiten sind ungestörtes Arbeiten und Iterationen fester Länge wie in Scrum kaum möglich. Dort kann Kanban die bessere Wahl sein. Für Bereiche mit starker Arbeitsteilung und Spezialisierung ist Kanban häufig attraktiver als Methoden, die Generalisten fordern (Teams, in denen jeder vieles kann). Klassisch ausgerichteten Unternehmen fällt Scrum oft schwer, weil dafür recht weitreichende Veränderungen nötig sind. Kanban lässt Änderungen evolutionär einführen. Scrum und Kanban schließen sich nicht komplett aus.