Praktisches & Grundsätzliches zur Informatik

Agile Methodik – Vorteile und Gefahren, Agile Methods

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]:

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

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:





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:



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




stw4281AMSCRUMAgile . Methodik . SCRUMNews?

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)