Praktisches & Grundsätzliches zur Informatik

Agile Methodik, Agiles Software Engineering vs Agiles Projektmanagement

Wesentliches zu Agiler Methodik

Mehr als 239.000 Seiten zum Stichwort agileManifesto, mehr als 920.000 zu agileMethods kennt Google.

Davon ist kaum mehr wissenswert als sich hinter den folgenden Links findet:
 


Hinweis: Obgleich man Agiles Software-Engineering über sein Ziel definieren sollte — die Garantie sofortiger Reaktion auf sich ändernde Anforderungen oder neue Erkenntnisse —, definiert sich Agile heute in den Köpfen vieler vor allem über recht vage Vorgehensmodelle (wie etwa SCRUM oder Agile Manifesto).

Das ist schade, da so der gute Kern des Gedankens schwer zu trennen ist von dem, was man hin und wieder sogar als Unsinn einzuordnen geneigt ist. Das beginnt schon mit einem definitionsbedingten katastrophalen Geburtsfehler:

Historie und derzeitige Sackgasse:


Agile Methodik entstand (etwa 1995) als Reaktion auf die Erkenntnis, dass es nicht mehr zielführend ist, Software so zu entwickeln, dass

Um ihre Idee bekannter zu machen, haben die Erfinder und Befürworter von Extreme Programming 2001 das Agile Manifesto publiziert. In Formulierung des Manifestos machten sie aber den Fehler, zur Lösung des Problems einen Weg zu skizzieren, der vielen Lesern willkommene Ausrede dafür war, fast alles zu vergessen, was bis dahin propagierte Vorgehensmodelle an notwendiger Spezifikation gefordert hatten (detaillierte, stets aktuelle Dokumentation von Anforderungen sowie von Schnittstellen und ihrer Leistung an erster Stelle).

Mehr und mehr hat man dann, eigentlich nur versehentlich, eben diesen in vieler Hinsicht zu wenig durch­dachten Weg als die eigentliche Definition Agiler Methodik gesehen und dabei völlig ignoriert, dass man so nur bis Ende der Implementierungsphase denkt — Anforderungen wartungstechnischer Art für die erst dann beginnende wichtigste Phase im Lebenszyklus der Software werden so gar nicht berücksichtigt (!).

Von zu wenig nachdrücklichen Warnungen Einzelner einmal abgesehen hat erst Gartner (10 Jahre später) auf diesen folgenreichen, wirklich schweren Fehler deutlich genug hingewiesen. Daher ist wichtig:





Leider macht man bis heute in der Diskussion um Agile noch einen zweiten gravierenden Fehler:

Wer nämlich fordert (was sinnvoll ist), dass die Anforderungsdefinition niemals eingefroren sein darf und somit neue Anforderungen und Erkenntnisse möglichst umgehend die im Gange befindliche Implemen­tierung des Produkts zu beeinflussen haben, der müsste mit deutlich machen, dass diese neue Regel es praktisch unmöglich macht, Entwicklungsprojekte zum Festpreis abzuwickeln. Diese unangenehme Wahrheit aber

Dass solche Vogel-Strauß-Politik nicht lange gut gehen kann, wird allzu sehr verdrängt. Frage also:


Ist es nicht wirklich höchste Zeit,
wieder professioneller zu argumentieren und zu arbeiten?


Best Practice Agile wäre guter Einstiegspunkt hierfür: Es muss erreicht werden, dass die Bereitschaft der Auftragnehmer, jederzeit Änderung der Anforderungen zu akzeptieren, mit als Leistung zählt, die ein Honorar wert ist. Es explizit in Rechnung stellen zu können, muss selbstverständlich werden (ist es aber nach derzeitigem EU-Ausschreibungsrecht noch lange nicht — ein wirklich großes Problem).

Ganz klar sollte sein: Agilität und Wasserfallmodell ergänzen sich optimal, wenn man das Wasserfall­modell so versteht und anwendet, dass das Ende jeder Phase erst bei Projektende als erreicht gilt, man also jederzeit bereit ist, neu erkannte Anforderungen oder Erkenntnisse sofort für die weitere Arbeit mit zu berücksichtigen.

Damit solches Vorgehen den Auftragnehmer auch dann nicht benachteiligt, wenn er bei Projektbeginn einen Festpreis akzeptiert hat, sollte jedes Vorgehensmodell heute auch geeignete Regeln für Change Management enthalten.



stw5245AMAAgile . Methodik . AnforderungenNews?

Mehr + B G E + S H A + More