Kritik an Agilen Methoden

So wie das klassische Projektmanagement bei genauer Betrachtung schwergewichtig erscheinen mag, so erwecken agile Methoden zuweilen einen untergewichtigen Eindruck. [Mangold, 2004] spricht davon, dass, mangels einer allgemein gültigen Methode für die erfolgreiche Entwicklung von Software, oft einfach unbedacht die übliche Vorgehensweise zur Methode erhoben wird. Es wird davor gewarnt, agile Methoden als Freibrief für „drauflos-programmieren“ im laissez-faire Stil zu betrachten. Wichtig ist dabei, dass Agile Methoden nicht vorgeschoben werden, um unstrukturiertem Vorgehen lediglich ein methodisches Mäntelchen umzuhängen, weil nur Teile der Prinzipien und Regeln des betreffenden agilen Ansatzes herausgepickt wurden. Solches Verhalten kann den Projekterfolg hinsichtlich Qualität, Dauer und Kosten in hohem Maße gefährden, da es im Extremfall dem Nicht-Managen des Projektes gleichkommt. 
 
Es ist hilfreich, sich stets vor Augen zu halten, dass einer der wesentlichen Gründe für die Verbreitung Agiler Methoden der Umstand ist, dass sich Ziele und Anforderungen in Projekten in der Praxis oft, unabsehbar und rasch ändern, [Mangold, 2004] spricht hier von „moving targets“. In Anknüpfung daran bringt der geflügelte Anglizismus „managing change“ treffend zum Ausdruck, was laut Agilem Manifest ein Kernelement Agiler Methoden ist und auch ihr Mehrwert. In einer immer dynamischeren Realität, die nicht zuletzt durch rasanten technologischen Fortschritt und sich ändernde ökonomische Rahmenbedingungen kontinuierlich beschleunigt wird, bieten sie ein flexibles Rahmenwerk für Softwareentwicklung, welches die Balance zu halten versucht zwischen „flexibel genug um jederzeit notwendige Anpassungen vornehmen zu können“ und „strukturiert genug um brauchbare Ergebnisse erzielen zu können“. 
 
Wichtig für den erfolgreichen Einsatz Agiler Methoden ist es, dass ihre Anwendbarkeit beim betreffenden Projekt sichergestellt ist, und dass alle Beteiligten die Grundsätze und Regeln der jeweiligen Methode verstehen und konsequent umsetzen. Das gilt für Kunden, Entwickler und weitere Mitarbeiter (vgl. [Mangold, 2004]). 
Letzte Änderung: 02.11.2010, 01:48 | 281 Worte