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:
- Agile is not Agile: Wisse über was Du sprichst
- SCRUM verglichen mit klassischem Projektmanagement
- KANBAN (einfacher und vielleicht geeigneter als SCRUM)
- Niemals Extreme Programming
- Die Eckpfeiler professioneller Agiler Methodik
- Agile Methodik darf man nur über ihren Zweck definieren
- Best Practice Agile
- Bad Practices for Agile
- Wer Artikel schreibt, wie z.B. Agile Testing vs. Traditional Testing hat nicht verstanden, um was es eigentlich geht.
- Erfahrungen sowie
kritische Stimmen und Diskussion
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
- zunächst, in Enwicklungsphase 1, Anforderungen definiert werden,
- die — nachdem der Auftraggeber sie als zutreffend und komplett akzeptiert hat — über längere Zeit als nicht mehr abänderbare Definition dessen gelten, was (in Entwicklungsphase 2) zu implementieren ist.
Mehr und mehr hat man dann, eigentlich nur versehentlich, eben diesen in vieler Hinsicht zu wenig durchdachten 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 Implementierung 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
- will kein Auftraggeber hören und
- wollen, aus der Furcht heraus, so ein Projekt dann gar nicht erst zu bekommen, auch die Auftragnehmer (zunächst jedenfalls) lieber nicht diskutieren.
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 Wasserfallmodell 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.
stw5245AMA — Agile . Methodik . Anforderungen — News?
Mehr + B G E + S H A + More