So lösen agile Methoden die Probleme des Wasserfallmodells
Fassen wir zunächst nochmal die Erkenntnisse unserer Problemanalyse zusammen:
- Lastenhefte sind unvollständig und somit erhält der Kunde nicht, was er erwartet.
- Das magische Dreieck der Projektziele ist kein adäquates Mittel zur Beurteilung unseres Projekterfolgs.
- Wir müssen Probleme früher sichtbar machen, um reagieren und den Projektfortschritt korrekt einschätzen zu können.
- Unnötige Dokumentation muss abgeschafft werden.
- Wir müssen unseren Mitarbeitern mehr Entscheidungsbefugnisse einräumen, um unmotivierte Aufgabenempfänger zu selbstständigen Projektteilnehmern zu entwickeln, die mit vollem Einsatz auf unsere Projektziele hinarbeiten.
Inhalt
Parallelisierung von Tätigkeiten
Damit wir konzeptionelle Probleme und Abweichungen zwischen der Erwartungshaltung der Entwickler und Tester frühzeitig erkennen können, müssen wir die Tests früher durchführen. Beim Wasserfallmodell wird zunächst alles fertig implementiert und erst dann kommen die Tester ins Spiel.
Das Problem können wir leicht lösen, in dem wir ein Feature direkt nach der Fertigstellung testen. Man spricht hier auch von entwicklungsbegleitenden Tests. Das wird nicht funktionieren, wenn Entwickler und Tester unabhängig voneinander von unterschiedlichen Teamleitern verplant werden. Stattdessen müssen wir die Tester in das Entwicklungsteam integrieren. Natürlich dürfen sie weiterhin einen anderen Vorgesetzten haben, aber die Leitung des Projekts muss einem Projektleiter obliegen.
Durch die Paralellisierung von Tätigkeiten können wir Fehler früher entdecken und die Stabilisierungsphase verkürzen.
Dieses Vorgehen bringt mehrere Vorteile mit sich:
- Da die Tester früh im Prozess integriert werden, können sie noch Einfluss nehmen: Zu diesem Zeitpunkt besteht noch die Chance, ein Feature zu überarbeiten.
- Häufig kann auf eine aufwändige Dokumentation seitens der Entwickler verzichtet werden, da die Übergabe des Features an den Tester zeitnah und persönlich erfolgt.
- Die frühzeitige Erkennung von Fehlern gibt uns die Chance konzeptionelle Probleme aus der Welt zu schaffen.
- Die zeitnahe Behebung eines Fehlers erspart dem Entwickler die erneute Einarbeitung in Code, dessen Erstellung schon lange zurückliegt.
- Die Projektdauer (nicht jedoch die Kosten) verringert sich, da am Ende keine lange QA-Phase mehr notwendig ist. Eine kurze QA-Phase für abschließende Integrations‑, Last- und Performance-Tests solltest Du allerdings weiterhin vorsehen.
- Vom Tester abgenommene Features sind tatsächlich fertig. Hier können wir guten Gewissens den Vorgang im Projektplan abhaken. Somit erhalten wir einen deutlich akkurateren Blick auf unseren Projektstatus.
Übrigens macht es Sinn auch die technischen Redakteure frühzeitig einzubeziehen und Features direkt nach der Fertigstellung dokumentieren zu lassen. Manch technischer Redakteur sorgte schon dafür, dass ein Feature komplett überarbeitet wurde.
Häufige Zwischen-Releases
Wir erinnern uns: Dadurch, dass Lastenhefte niemals vollständig sind, erhält der Kunde in der Regel nicht, was er erwartet. Erst nach einer langen Entwicklungs- und QA-Phase darf er das fertige Produkt ausprobieren. Dann ist es aber meistens bereits zu spät, um noch Änderungen vorzunehmen. Der Kunde ist unzufrieden.
Ähnlich wie bei den entwicklungsbegleitenden Tests gilt auch hier der einfache Ansatz, Feedback so früh wie möglich einzuholen. Das können wir erreichen in dem wir häufige Zwischen-Releases erstellen.
Dazu unterteilen wir das große Projekt in viele kleine Zyklen gleicher Länge. In meinen Projekten hat sich über die Jahre hinweg eine Zykluslänge von zwei Wochen etabliert. Am Ende jedes Zyklus – also alle zwei Wochen – stellen wir ein Release bereit, das einen Mehrwert für den Kunden bietet.
Durch die häufige Bereitstellung von Zwischen-Releases können wir den Kunden früh in den Prozess einbinden und genau das liefern, was er benötigt.
Mit diesem Release können wir unserem Kunden die neu entwickelten Features zeigen. So erhalten wir unmittelbar Feedback. Wir erfahren, ob der Kunde mit der Umsetzung zufrieden ist und sich alles so verhält, wie er es sich vorgestellt hat. Wichtig dabei ist, dass wir nur Features integrieren, die bereits von der QA abgenommen wurden. Unfertige Features gehören nicht ins Zwischen-Release, da es sich nicht lohnt mit dem Kunden über etwas zu diskutieren, dass wir selbst noch nicht abschließend beurteilt haben.
Von Zeit zu Zeit wird dem Kunden eine Lösung nicht gefallen. Ich leitete mal ein Projekt, wo der Kunde sich jedes dieser Zwischen-Releases mit uns gemeinsam anschaute. Einmal stellten wir ihm ein Feature vor, dass wir exakt gemäß dem Lastenheft implementiert hatten. Allerdings stellte sich heraus, dass die Umsetzung für den Endanwender zu kompliziert war – etwas das aus den Anforderungen nicht zu erkennen war, sondern erst wenn man die Software wirklich »anfasste«. Der Kunde entschied tatsächlich, die bisherige Umsetzung zu verwerfen und auf eine andere Art durch uns neu implementieren zu lassen.
»Und wer hat das bezahlt?« wirst Du jetzt fragen. Ganz einfach: der Kunde. Er hat das Projekt verlängert und mehr bezahlt, hatte dafür aber am Ende eine Lösung, mit der seine Fachanwender umgehen konnten, und war somit sehr zufrieden. Wären wir nach Wasserfallmodell vorgegangen, hätte der Kunde am Ende die unbefriedigende Lösung erhalten. Gemäß dem magischen Dreieck der Projektziele wären wir zwar erfolgreich gewesen, da wir Umfang, Kosten und Zeit eingehalten hätten, aber trotzdem wäre der Kunde mit uns unzufrieden gewesen.
Das Entscheidende bei der frühen Einbeziehung des Kunden ist, dass er die Wahl hat. Er kann entscheiden, ob er das Feature so behalten oder ob er es neu entwickeln lassen will. Selbst in letzterem Fall kann er entscheiden, ob er dadurch die Projektdauer (und somit auch die Kosten) erhöhen oder lieber auf andere Features verzichten und den Termin halten möchte.
Ein weiterer riesiger Vorteil der Unterteilung in kleine Zyklen besteht darin, dass wir kontinuierliche Messpunkte etablieren. Wir nehmen uns für den nächsten Zyklus etwas vor und setzen alles daran, das gesteckte Ziel zu erreichen. Das führt zu einer Entzerrung des üblichen Projektendestresses und verteilt diesen in kleinen Einheiten auf das Gesamtprojekt.
Das eigenverantwortliche Team
Zuletzt kümmern wir uns noch um die Motivation unserer Mitarbeiter. Weg mit den stupiden Aufgabenempfängern, her mit selbstbewussten, aktiven Mitarbeitern.
Haben wir bisher die Aufgaben auf die Mitarbeiter verteilt (Push-Prinzip), so bauen wir das zukünftig einfach um. Wir stellen nur noch einen Pool von Aufgaben bereit, aus dem sich die Mitarbeiter dann selbst bedienen (Pull-Prinzip). Das bringt einige erhebliche Vorteile mit sich:
- Die Mitarbeiter können Ihre Stärken und Vorlieben bei der Auswahl mit einbringen. Das beschleunigt die Abarbeitung und erhöht die Motivation.
- Bei allgemein unbeliebten Aufgaben muss sich das Team selbst einigen, wer diese bearbeiten soll. Das entschärft mögliche Konflikte.
- Und ganz nebenbei verringert sich unser Aufwand für die Planung: Zerbrachen wir uns bisher den Kopf, wer wann eine bestimmte Aufgabe übernimmt, so organisiert das Team das von nun an in Eigenregie. Ich kann Dir versprechen: Das hat mein Leben als Projektleiter deutlich vereinfacht!
Zum eigenverantwortlichen Team gehört aber nicht nur die selbstständige Verteilung der Aufgaben, sondern auch die Abschätzung der Tätigkeiten durch das Team und die selbstständige Planung. Yippie! Noch weniger Arbeit für uns! Das ist aber nicht der Grund für diese Maßnahme. Vielmehr geht es darum, dass sich das Team selbst Ziele steckt, an deren Einhaltung es auch selbst glaubt.
So entscheidet das Team zum Beginn jedes Zyklus, welche Features es bis zum Ende fertigstellen möchte. Du als Projektleiter gibst nur noch die Priorität der Themen vor, aber das Team entscheidet selbstständig, was es realistisch in den nächsten zwei Wochen schaffen kann.
Damit das Team planen kann und sich an seine Planung gebunden fühlt müssen wir sicherstellen, dass die Verfügbarkeit während des nächsten Zyklus geklärt ist und auch so eingehalten wird. Sobald wir plötzlich Personen für Sonderthemen abziehen, fühlt sich das Team seiner Planung nicht mehr verpflichtet.
Fazit
Damit haben wir alle Maßnahmen zur Lösung der Probleme des Wasserfallmodells ermittelt. Fassen wir sie noch einmal zusammen:
- Tätigkeiten parallelisieren,
- häufige Zwischen-Releases und
- Erschaffung eines eigenverantwortlichen Teams.
Fehlt noch eine Möglichkeit unseren Erfolg zu messen, da das magische Dreieck der Projektziele nicht mehr in Frage kommt. In meinen Augen gibt es nur ein entscheidendes Kriterium für unseren Erfolg: die Kundenzufriedenheit. Nur wenn wir es schaffen unsere Kunden jetzt und in Zukunft zu zufriedenen Kunden zu machen werden wir sie auch halten und somit erfolgreich sein können. Die oben genannten Maßnahmen geben uns die Werkzeuge an die Hand, um genau das zu tun.
bei Amazon kaufen und »AgilManagen.de« unterstützen
Natürlich kannst Du jetzt hingehen und diese Maßnahmen selbstständig in der Praxis anwenden. Das ist auch gar nicht schwer, wenn man mal von der notwendigen Überzeugungsarbeit absieht. Allerdings entwickeln wir unsere Software ja auch nicht von Grund auf neu, sondern wir setzen fertige Libraries und Frameworks ein.
Warum sollten wir bei unseren Prozessen anders verfahren? Wenn Du Dir mal die agilen Methoden anschaust, wirst Du feststellen, dass letztlich alle von ihnen – egal ob Scrum, Extreme Programming, Crystal oder andere – die zuvor genannten Lösungen als zentrale Bestandteile enthalten. Daher empfehle ich Dir dringend, eine dieser fertigen Methoden zu nutzen, anstatt Deine eigene zu erfinden.
Schließen wir mit der Frage »Soll ich mein Team auf agile Methoden umstellen?« Die Antwort darauf ist nicht ganz so eindeutig, wie Du sie vielleicht von mir erwartet hättest. Wenn für Dich und Deine Kunden Dein aktueller Prozess funktioniert, dann sehe ich keine Notwendigkeit, daran etwas zu ändern. Des Weiteren setzt der Einsatz von agilen Methoden gewisse Social Skills bei Deinen Mitarbeitern voraus und es muss der Wille bestehen, diese neue Herangehensweise zumindest auszuprobieren. Sind diese Voraussetzungen allerdings erfüllt, empfehle ich Dir auf jeden Fall agile Methoden auszuprobieren.
Schließen möchte ich mit dem agilen Manifest:
Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir folgende Werte zu schätzen gelernt:
Individuen und Interaktionen gehen über Prozesse und Werkzeuge.
Funktionierende Software geht über umfassende Dokumentation.
Zusammenarbeit mit dem Kunden geht über Vertragsverhandlungen.
Reagieren auf Veränderung geht über das Befolgen eines Plans.
Das heißt, obwohl wir die zweitgenannten Werte wichtig finden, schätzen wir die erstgenannten höher ein.
Trackback von deiner Website.
