Wie ein agiles Projekt abläuft

Agile Entwicklung ist heute einer der Standards im Softwarebereich. Zunehmend wird sie auch auf Entwicklungen aller Art angewendet – auch im Mediengeschäft. Daher ist es gut, zu wissen, wie ein agiles Projekt im Detail abläuft.

Der Softwareentwickler Robert C. Martin („Uncle Bob“) erklärt im Channel Produktion & Prozesse von buchreport.de die wesentlichen Merkmale agiler Projekte.

Wie managt man ein Softwareprojekt? Im Laufe der Jahre hat es eine Vielzahl von Ansätzen gegeben – und die meisten waren ziemlich mangelhaft. Unter Managern, die an Götter glauben, die für das Schicksal von Softwareprojekten verantwortlich zeichnen, sind Gottvertrauen und Gebete weit verbreitet. Ungläubige greifen eher auf motivierende Verfahren zurück, wie die Durchsetzung von Abgabefristen mithilfe von Peitschen, Ketten, siedendem Öl und Bildern von bergsteigenden Menschen und über dem Meer fliegenden Möwen.

Diese Ansätze führen fast immer zu dem charakteristischen Symptom fehlerhaften Softwaremanagements: Entwicklerteams, die trotz zu vieler Überstunden ständig Abgabefristen versäumen. Solche Teams erstellen Produkte von offensichtlich geringer Qualität, die den Anforderungen des Kunden nicht annähernd gerecht werden.

Das Eiserne Kreuz

Der Grund für das Scheitern dieser Verfahren ist, dass die Manager, die sie einsetzen, die physikalischen Grundlagen von Softwareprojekten nicht verstanden haben. Allen Projekten ist ein unanfechtbarer Kompromiss auferlegt, der als das Eiserne Kreuz (engl. Iron Cross) des Projektmanagements bezeichnet wird.

Gut, schnell, preiswert, erledigt: Wählen Sie drei dieser Attribute aus – das vierte ist nicht verfügbar. Ein Projekt kann gut, schnell und preiswert sein, wird dann aber nicht erledigt. Ein Projekt kann auch erledigt, preiswert und schnell sein, dann ist es jedoch nicht gut.

Einem guten Projektmanager ist klar, dass diese vier Attribute verschiedene Beiträge leisten. Ein guter Projektmanager leitet ein Projekt so, dass es den Anforderungen entsprechend gut, schnell, preiswert und erledigt ist. Ein guter Projektmanager passt die Beiträge, die diese Attribute leisten, demgemäß an, anstatt zu verlangen, dass alle 100% betragen. Diese Art des Managements wird mit agiler Softwareentwicklung angestrebt.

An dieser Stelle möchte ich mich vergewissern, dass Ihnen klar ist, dass agile Softwareentwicklung Rahmenbedingungen schafft, die Entwicklern und Managern dabei helfen, diese Art eines pragmatischen Projektmanagements durchzuführen.

Ein solches Projektmanagement ergibt sich allerdings nicht automatisch und es gibt keine Garantie, dass Manager angemessene Entscheidungen treffen. Tatsächlich ist es möglich, vollständig auf agile Softwareentwicklung zu setzen und ein Projekt durch Missmanagement dennoch zum Scheitern zu bringen.

Diagramme an der Wand

Wie fördert agile Softwareentwicklung diese Art des Managements? Sie stellt Daten bereit. Ein agiles Entwicklerteam erstellt nur genau die Daten, die Manager benötigen, um die richtigen Entscheidungen zu treffen.

Agile Softwareentwicklung ist vor allem ein Feedback-getriebener Ansatz. Jede Woche, jeden Tag, jede Stunde und manchmal sogar jede Minute sieht man sich die Ergebnisse der vorangegangenen Woche, des vorhergehenden Tags und der letzten Stunden und Minuten an und nimmt entsprechende Anpassungen vor.

Das gilt für einzelne Programmierer, aber auch für das Management des gesamten Teams. Ohne Daten kann man ein Projekt nicht managen.

Vergewissern Sie sich, dass den Managern bekannt ist, wie schnell das Team vorankommt und wie viel es noch zu erledigen hat. Und präsentieren Sie diese Informationen für alle zugänglich und auf offensichtliche Weise –wie zum Beispiel mit Diagrammen an der Wand.

Warum aber sind diese Daten so wichtig? Ist es möglich, ein Projekt ohne diese Daten effektiv zu managen? Wir haben es 30 Jahre lang versucht. Und so ging es aus.

Ein besseres Verfahren

Das Problem beim Wasserfallmodell ist, dass es so sinnvoll erscheint. Zuerst analysieren wir eine Aufgabe, dann entwickeln wir eine Lösung und anschließend implementieren wir das Design.

Einfach. Direkt. Auf der Hand liegend. Und falsch.

Der agile Ansatz unterscheidet sich völlig davon, erscheint aber ebenso sinnvoll. Tatsächlich denke ich, dass Sie beim Weiterlesen feststellen werden, dass er sogar mehr Sinn ergibt.

Am Anfang eines agilen Projekts steht eine Analyse, die allerdings nie zu Ende geht. Das Diagramm unten zeigt das gesamte Projekt. Die rechte Seite stellt das Enddatum dar, den 1. November. Wie Sie wissen, ist das Datum das Erste, was man weiß. Wir unterteilen den Zeitraum in gleich große Abschnitte, die als Iterationen oder Sprints bezeichnet werden.

Die Dauer einer Iteration beträgt typischerweise ein oder zwei Wochen. Ich bevorzuge eine Woche, weil in zwei Wochen zu viel schiefgehen kann. Andere ziehen zwei Wochen vor, weil sie befürchten, dass man in einer Woche nicht genug Arbeit erledigen kann.

Iteration Null

Die erste Iteration, die mitunter auch als Iteration Null bezeichnet wird, dient dazu, eine kurze Liste der Features zu generieren, die Stories heißen. Fürs Erste können Sie sich darunter Features vorstellen, die entwickelt werden müssen. Die Iteration Null wird auch dazu genutzt, die Entwicklungsumgebung einzurichten, den Aufwand für die Stories abzuschätzen und den anfänglichen Zeitplan aufzustellen. Dieser Plan beinhaltet einfach nur eine provisorische Zuordnung der Stories zu den ersten paar Iterationen. Zudem wird die Iteration Null von Entwicklern und Architekten verwendet, um ein vorläufiges Design des Systems anhand der provisorischen Liste der Stories hervorzubringen.

Der Vorgang, Stories zu schreiben, ihren Aufwand abzuschätzen und sie zu planen und zu designen, hat kein Ende. Deshalb enthält das Diagramm einen horizontalen Balken namens „Erkundung”, der sich über das gesamte Projekt erstreckt.

Bei jeder Iteration des Projekts, von Anfang bis Ende, finden Analyse, Design und Implementierung statt. Bei einem agilen Projekt erfolgen Analyse und Design permanent.

Manche folgern daraus, dass agile Softwareentwicklung lediglich aus einer Reihe von Mini-Wasserfallmodellen besteht. Das ist jedoch nicht der Fall. Iterationen sind nicht in drei Abschnitte unterteilt. Analysen finden nicht nur ausschließlich am Anfang einer Iteration statt und Implementierungen nicht nur am Ende. Die Aktivitäten Analyse, Architektur, Design und Implementierung finden während einer Iteration vielmehr kontinuierlich statt.

Machen Sie sich keine Sorgen, wenn Sie das verwirrt. Merken Sie sich jedoch, dass Iterationen bei agilen Softwareprojekten nicht die kleinste Stufe sind. Es gibt noch viele weitere Ebenen, in denen Analyse, Design und Implementierung erfolgen.

Agile Softwareentwicklung liefert Daten

Am Anfang von Iteration Eins findet eine Abschätzung statt, wie viele Stories erledigt werden. Das Team arbeitet dann für die Dauer einer Iteration an der Vervollständigung dieser Stories. Was innerhalb einer Iteration geschieht, erörtern wir später. Aber was meinen Sie, wie groß die Wahrscheinlichkeit ist, dass ein Team tatsächlich alle Stories wie geplant erledigen wird?

Natürlich ziemlich genau null, denn Softwareentwicklung ist ein Vorgang, der sich nicht verlässlich einschätzen lässt. Wir Programmierer wissen schlicht und einfach nicht, wie lange Dinge dauern werden. Das liegt nicht daran, dass wir inkompetent oder faul sind, sondern daran, dass es keine einfache Möglichkeit gibt, in Erfahrung zu bringen, wie kompliziert eine Aufgabe ist, bevor man sie in Angriff nimmt und erledigt. Aber noch ist nicht alles verloren, wie Sie noch sehen werden.

Der Channel Produktion & Prozesse

Weitere Lösungen, Impulse und Erfahrungsberichte für die Verlagsproduktion lesen Sie im Channel Produktion & Prozesse von buchreport und Channel-Partner Publisher Consultants.
Hier mehr…

Am Ende einer Iteration wird ein Teil der Stories, deren Abschluss geplant war, erledigt sein. Das liefert uns einen ersten Hinweis darauf, wie viel in einer Iteration zu schaffen ist. Hierbei handelt es sich um echte Daten. Wenn wir annehmen, dass alle Iterationen ähnlich verlaufen, können wir diese Daten nutzen, um den ursprünglichen Zeitplan anzupassen, und ein neues Enddatum für das Projekt berechnen.

Die Neuberechnung wird wahrscheinlich ziemlich enttäuschend sein, denn das neue Enddatum wird nahezu mit Sicherheit deutlich hinter dem ursprünglichen liegen. Allerdings beruht die Neuberechnung auf echten Daten, man sollte das Ergebnis also nicht auf die leichte Schulter nehmen. Man muss es aber auch noch nicht allzu ernst nehmen, denn es beruht ja auf nur einem einzigen Datenpunkt; der Fehlerbalken des prognostizierten Datums ist sehr breit.

Wir sollten zwei oder drei weitere Iterationen durchführen, um die Breite des Fehlerbalkens zu verringern. Dann erhalten wir zusätzliche Informationen darüber, wie viele Stories in einer Iteration fertiggestellt werden können. Die Anzahl variiert von Iteration zu Iteration, aber für die Velocity ergibt sich ein relativ stabiler Durchschnittswert. Nach vier oder fünf Iterationen haben wir eine deutlich bessere Vorstellung davon, wann dieses Projekt abgeschlossen sein wird.

Mit jeder Iteration wird der Fehlerbalken kleiner, bis schließlich keine Hoffnung mehr besteht, dass der ursprünglich vorgesehene Termin eingehalten werden kann.

Hoffnung vs. Management

Diese Hoffnung aufzugeben, ist eines der entscheidenden Ziele agiler Softwareentwicklung. Wir praktizieren sie, um die Hoffnung zu zerschlagen, bevor sie einem Projekt den Todesstoß versetzen kann.

Hoffnung ist der Todfeind eines Projekts. Die Hoffnung ist schuld daran, dass ein Softwareteam versucht, Manager hinsichtlich der tatsächlichen Fortschritte in die Irre zu führen. Wenn ein Manager ein Team fragt, wie es läuft, trägt die Hoffnung die Verantwortung dafür, dass die Antwort „Ziemlich gut!” lautet. Doch beim Management eines Softwareprojekts ist die Hoffnung ein schlechter Ratgeber.

Agile Softwareentwicklung ist eine Möglichkeit, die Hoffnung frühzeitig und kontinuierlich durch ein gerüttelt Maß schonungslosen Realismus zu ersetzen.

Manche denken, dass es bei agiler Softwareentwicklung darum geht, schnell voranzukommen. Das stimmt jedoch nicht; es ging dabei nie darum, schnell Fortschritte zu machen. Es geht vielmehr darum, so früh wie möglich zu erkennen, wie sehr wir uns verrannt haben. Wir wollen das so früh wie möglich wissen, damit wir die Situation managen können. Denn das ist es, was Manager tun. Sie managen Softwareprojekte, indem sie Daten sammeln und anhand dieser Daten die besten Entscheidungen treffen. Und agile Softwareentwicklung liefert Daten – viele Daten. Manager nutzen diese Daten, um das Projekt so zu leiten, dass das bestmögliche Ergebnis erzielt wird.

Das bestmögliche Ergebnis ist oft gar nicht das ursprünglich angestrebte. Es könnte für die Auftraggeber des Projekts sogar eine große Enttäuschung sein. Aber das bestmögliche Ergebnis ist per definitionem nun einmal das Beste, was sie bekommen können.

Das Eiserne Kreuz managen

Kommen wir zurück zum Eisernen Kreuz des Projektmanagements: gut, schnell, preiswert, erledigt. Anhand der vom Projekt gelieferten Daten können Manager feststellen, wie gut, wie schnell und wie preiswert ein Projekt sein sollte und inwieweit es als erledigt betrachtet werden kann. Die Manager erreichen das, indem sie Änderungen am Umfang des Projekts, am Zeitplan, bei der Anzahl der Mitarbeiter und bei der Qualität vornehmen.

Mit freundlicher Genehmigung des mitp Verlages.

Robert C. Martin (2020): Clean Agile.

192 Seiten.

• Buch: 24,99 Euro
• E-Book: 21,99 Euro
• Buch+E-Book: 29,99 Euro