Vorteile und Gefahren Agiler Methodik

Wie es zu Agile kam, und was man darunter zu verstehen hat, beschreibt sehr schön Martin Fowler (einer der Leute, die jene Bewegung — über ihr Manifesto — ins Leben gerufen hatten). Seine Artikel dazu sollte man deswegen zuerst lesen.

Wie App-Entwickler die Methodik heute einsetzen (in kleinen Projekten, zu denen sie wirklich passt), scheint mir gut beschrieben auf Seite » How we build Apps using Agile Development «.

Meine Meinung zu Agiler Methodik (und dem heute so viel diskutierten SCRUM in seiner ursprünglichen Form) ist die, welche ganz offensichtlich auch der weltweit bekannte Methodiker Tom Gilb und sein Sohn Kai vertreten. Letzterer schreibt in [2006]:

• Agile Software Methods are a great relief and a big step in the right direction compared to traditional development methods. [However:]
• Agile Methods biggest weakness is in it's complete lack of systematic control towards satisfying Product Quality and Stakeholder Value Requirements.
• Agile methods are typically used for smaller, less-critical projects only (!).
  
  

Tatsache ist, dass Agile Methodik häufig missverstanden wird als eine Methodik, die ohne definierte Pro­zesse auskommt. Solch haarsträubenden Unsinn etwa liest man auf der Seite agile-process.org, wo gesagt wird: The most important thing to know about Agile methods or processes is that there is no such thing. There are only Agile teams. The processes we describe as Agile are environments for a team to learn how to be Agile. [Der Fehler dieser Definition, besteht darin, Agile Methodik gleichzusetzen mit Extreme Programming – was grundfalsch und verhängnisvoll ist.]

Wie also sollte man Agile Methoden wirklich praktizieren "to make them winners not just hacking with a nice name" [1]?

Meine Antwort hierauf ist ein Vergleich von Extreme Programming (dem Vater und dem Kern des agilen Ansatzes) mit einem Vorgehensmodell, das ich SST — Specify, Subcontract, Test — nenne und das alles berücksichtigt, was man – die Projekttechnik des Software Engineerings betreffend – in den Jahren 1970 bis 2000 gelernt und für wertvoll erachtet hat.

Dieser Vergleich – bitte kurz mal reinsehen – zeigt anhand nebeneinander gestellter Charakteristika beider Vorgehensmodelle, wie verdammenswerte Eigenschaften von Extreme Programming (die roten) in SST ersetzt sind durch grüne (durch jene nämlich, die man definitiv anstreben sollte, um auch in großen Projekten nicht Schiff­bruch zu erleiden oder dort Software zu erzeugen, deren Total Cost of Ownership explodieren würde, sobald die ursprünglichen Entwickler nicht mehr verfügbar sind).

SST lässt sich klassisch (als nur ein Wasserfall), aber auch agil und daher spiralförmig anwenden. Es ist durchaus kombinierbar mit Feature Driven Development (FDD).

Die Tatsache, dass das klassische Wasserfallmodell

• im Laufe der Zeit immer komplexer und bürokratischer wurde (etwa als V-Modell im Behördenbereich)
• und damit einhergehend auch nicht mehr flexibel genug interpretiert wurde,
  
  

hat letztlich zu einer Art Revolution geführt, die — ausgehend von Extreme Programming (XP) — in den letzten 10 bis 15 Jahren zu dem geführt hat, was man heute als Agile Methodik bezeichnet und — sofern man hier einen Vorgehensstandard anstrebt — vor allem durch SCRUM gut unterstützt sieht.

Ein folgenschwerer Irrtum vieler Anhänger des klassischen Wasserfallmodells war ferner, dass sie der Meinung waren, ein vom Kunden schon abgenommenes Teilergebnis eines Entwicklungsprojekts — das Pflichtenheft etwa — dürfe nach solcher Abnahme keinerlei Änderung mehr erfahren. Projektmanager, die so dachten, haben einfach nicht erkannt, dass zu diesem Zeitpunkt lediglich die Wartungsphase für dieses Teilprodukt beginnt (und die erst enden darf, wenn das Projekt selbst sein Ziel erreicht hat). Zudem war die Furcht vieler zu groß, bei Anerkennung der Tatsache, dass auch Anforderungen sich fortentwickeln, den für das Projekt vereinbarten Festpreis nicht mehr halten zu können.

Eine solche Vogel-Strauss-Politik führt aber stets nur zu unzufriedenen Kunden.

Die richtige Lösung wäre, dem Kunden entgegenzukommen,
die eigenen Interessen aber über geeignetes Change Management zu wahren.

Wohlverstandene Agile Methodik steht also keinesfalls im Widerspruch zum Wasserfallmodell. Die gewünschte — und auch tatsächlich notwendige — Agilität besteht einfach darin, zuzulassen, dass die Anforderungen an zu erstellende Software sich auch nach einer ersten Abnahme des Pflichtenhefts weiter fortentwicklen können.

Anforderungen und wichtige Schnittstellen deswegen nicht mehr gut zu dokumentieren, wäre dennoch ein großer Fehler (den viele Anhänger agiler Methoden aber leider machen – sie berufen sich da aufs Agile Manifesto, das ja u.A. sagt: Working Software over Comprehensive Documentation). Agiles Vorgehen sollte man deswegen nicht übers Manifesto definiert sehen sondern über die allseits anerkannten 10 Grund­sätze agilen Vorgehens (Principles of Agility 2011).

SCRUM (in moderner Form) schließlich ist noch etwas mehr als nur Agile Methodik. In SCRUM finden sich auch Ansätze, vorhandene Budgets durch geeignete Priorisierung von Teilaufgaben wirkungsvoller zu nutzen: Ansätze also, das Projektgeschehen besser zu steuern.

Auch bei SCRUM aber gilt: Wo man das Vorgehen allzu sehr bürokratisiert — und schon die Forderung nach einem täglichen SCRUM Meeting scheint mir eine solche Übertreibung —, wird die Kreativität der Mitarbeiter erwürgt werden (ganz so wie das die für Behörden geschaffenen, allzu detaillierten Wasser­fallmodelle der letzten Jahrzehnte des 20. Jahrhunderts in den USA, Großbritannien und Deutschland bewirkt hatten oder wie das heute auf europäischer Ebene die weltfremden Regel tun, denen sich jeder zu unterwerfen hat, der EU-Ausschreibungen erstellt oder beantwortet).

Dem SCRUM ebenso wie den klassischen Wasserfallmodellen auf jeden Fall vorzuziehen ist in meinen Augen Evo (Evolutionary Project Management). Seine Vorzüge sind:

• Evo bewahrt alle positiven Eigenschaften klassischer Modelle, weist aber deutlich darauf hin, dass der Weg des Wasserfalls mehrfach iteriert gegangen werden muss — bezogen auf das Projekt als Ganzes ebenso wie einzeln auf bestimmte Teilprodukte.
• Evo verhindert, dass Entwickler das Kundeninteresse — den sog. Stakeholder Value — hintanstellen.
• Evo berücksichtigt zudem den wichtigen Aspekt, dass Qualität nur dort fortentwickelt werden kann, wo sie messbar wird (und solche Messung dann auch tatsächlich stattfindet):
  
  

Source: Tom & Kai Gilb



Evo harmoniert gut mit dem einfachen, aber sehr hilfreichen Grundmodell der Prozessreife (welches ich als weit praktikabler einstufe als 5-stufige CMM).

Leider scheint Evo nur geeignet, wo Entwicklungsprojekte nach Aufwand abgerechnet werden. Der gegenwärtige Trend, Entwicklungsaufträge nur zum Festpreis vergeben zu wollen, macht ernsthaften Einsatz von Evo schwierig. Es bleibt abzuwarten, wie man dieses Problem irgendwann mal löst ...

Lese auch:

• Process Models for Software Development
• Why Software Development Methodologies Suck
• How people do Agile Software Development in 2011
• The true Definition of Agile
• Was ist Agile wirklich?
• Best Practice Agility: Agilität, wie wir sie wirklich benötigen
  
  
  Wie selbst neuere Fachartikel in der COMPUTERWOCHE immer wieder zeigen, ist vielen, die sich für Kenner des Trends hin zu Agile halten, immer noch nicht klar, dass Agile nicht als Methodensammlung missverstanden werden darf, sondern stattdessen eine neue Geistes­haltung zu sein hat, die uns klar macht, in welchem Ausmaß wir heute flexibler zu sein haben als früher:
  
  Projektmanager müssen akzeptieren, dass zu Beginn eines Projekts definierte An­forderungen
  
  
  • sich während des Projekts ändern,
  • dass dies schon lange kein Ausnahmefall mehr ist (da immer seltener vorher genug Zeit war, sie ausreichend tief zu durch­den­ken),
  • und dass nur erfolgreich sein kann, wer bereit ist, entsprechend flexibel zu agieren:
  
  Die zu Projektende erwartete Lösung muss die dann geltenden Anforderungen erfüllen — auch wenn das in großen Teilen ganz andere sein sollten als die, von denen man noch zu Beginn des Pro­jekts ausging.
  
  Viele behaupten, das klassische Wasserfallmodell sei überholt. Dem aber ist nicht so: Es kann sehr gut weiter angewandt werden — allerdings nur unter der Nebenbedingung, dass wirklich jede seiner Phasen erst zu Projektende als abgeschlossen gelten darf. Wer glaubt, dass jetzt weni­ger dokumentiert werden müsse als früher, der irrt sich gewaltig. Wichtiges Prinzip muss wei­terhin sein: Implementiert wird nur, was als Anforderung schriftlich fixiert, vom Auftrag­geber explizit gefordert und dann von Systemarchitekten ausreichend detailliert als Lösung spezifiziert wurde. Entsprechende Dokumente müssen selbst noch bei Projektende voll aktuell sein. Eben das hat man früher nicht so gesehen — was ein großer Fehler war, denn wo man sich auf Dokumentation nicht mehr verlassen kann, verliert jede Anwendung schnell an Wart­barkeit.
  
  Anders als früher, dürfen wir den Auftraggeber heute nicht mehr daran hindern, Anforderun­gen an die beauftragte Lösung noch vor Projektende zu überdenken mit dem Ziel, sie neuen Erkenntnissen und neu entstandenenen Randbedingungen anzupassen. Zentrales Ziel jeden Projekts und aller daran Beteiligten muss sein, bestmöglich zu verstehen, was die beauftragte Lösung bei Inbetriebnahme wird leisten müssen. Wo solches Verständnis nicht ganz gezielt mit angestrebt wird und dann zu Projektende fehlt — oder noch zu dünn ist —, kann das Vorhaben für den Auftraggeber nur zum Desaster werden. Dies gilt umso mehr, je komplexere Vorhaben man in Angriff nimmt (und sie werden ständig komplexer).
  
  Dem Auftragnehmer durch neue Anforderungen entstehender Mehraufwand muss durch ihn im Zuge von Change Management transparent gemacht und vom Auftraggeber akzeptiert werden.
  
  Der Trend hin zum Festpreis ist dafür gedacht diese Situation zu vereinfachen, birgt aber die Gefahr in sich, unvermeidbare Risiken allzu ungerecht auf die Vertragspartner zu verteilen. Wo das der Fall ist, kann es zu Situationen kommen, in denen alleine deswegen schon Qualität auf der Strecke bleibt und dann vor allem auch dem, der sich zunächst als Gewinner fühlte, eine Projektkatastrophe ins Haus steht.
  
  Und so ist nun letztlich selbst noch der Beauftragungsprozess erst abgeschlossen, wenn auch das Projekt selbst abgeschlossen ist.
  
  
• What it can mean NOT to be agile
• Avoid XP – be Agile with SST
• How to fail with Agile
• What Happened to Software Engineering?
• Manche sagen (2015): » Agile? This shit is toxic! « (meinen damit aber nicht Agilität — die nämlich ist wirklich notwendig).
  
  

Software development process
Activities and steps
Requirements · Specification Architecture · Design Implementation · Testing Deployment · Maintenance
Methodologies
Agile · Iterative RAD · RUP · Spiral Waterfall · XP · Lean Scrum · V-Model · TDD
Supporting disciplines
Configuration management Documentation Quality assurance (SQA) Project management User experience design and Best Practice Agility

stw4281AMSCRUM — Agile . Methodik . SCRUM — News?

Mehr + B G E + S H A + More

Wo man den Unterschied zwischen Agile und wünschenswerter agiler Projektdurchführung noch nicht begriffen hat

Perfect Agile

Software Development Philosophies

Brooks' Law

The Cone of Uncertainty

Kritik am zu naiv definierter SCRM-basierter Methodik

Agile Is Not the Answer to All Your Failed Software Development Projects

Agilität und wasserfallartiges Vorgehen: Beides ist notwendig.

Product Owner (= Requirements Manager)
 

15.08.2024
© 2024 Impressum, top