Danny Quick macht sich so seine Gedanken über agiles Anforderungsmanagement und gräbt einen Vortrag von Detlef Buder und Alexander Fischbach aus.

Helge Baier macht im Rahmen seiner Masterarbeit eine Online-Umfrage zum Thema:

Die Rolle von Anforderungen als vertragliche Grundlage von Individualsoftware-Projekten

Die Umfrage läuft noch bis Ende Oktober.

Planungspoker ist ein „Spiel“, das mir erstmalig in der Auseinandersetzung mit agiler Softwareentwicklung über den Weg gelaufen ist. Um zu möglichst unvoreingeommenen Aufwandsschätzungen zu gelangen wird ein Spiel unter Experten initiiert. Jeder muss spontan mittels Pokerkarten den mir einem Funktionsbaustein/einer Use story verbundenen Aufwand schätzen. Alle Experten legen ihre Schätzung gleichzeitig auf den Tisch, damit sie sich nicht gegenseitig beeinflussen können.

Wie Aufwandsschätzungen mit und ohne Planungspoker ablaufen können beschreibt der agile Software-Blog

Der agile software-Blog hat einige Aussagen von Steve Ballmer zum Thema agile Softwareentwicklung/Agilität bei Microsoft ausgegraben:

„…. [What we] are working hardest on now is agility. What does it mean to be agile in the marketplace? Agility means that you are able to turn things around, that you can invent new things and yet you can still do things that require scale, discipline and execution.“

Er verweist insbesondere auf die Herausforderung des Changemanagement einen Konzern wie Microsoft agiler werden zu lassen.

Kevin Rutherford philosophiert in seinem Blog silk and spinach darüber, wie sich Programmierer auf „ihre“ Tester verlassen und ihnen die gesamte Qualitätssicherung überlassen, wenn sie um die Qualität des Testteams wissen. Dies kann dazu führen, dass – überspitzt gesagt – ein gutes Testteam dazu führt, dass die Qualität des Quellcodes nachlässt.

Hört sich zunächst abstrus an, aber kennen wir nicht alle Fälle von Nachlässigkeiten, wenn z.B. die Entwickler vergessen die Berechtigungen mitzutesten, weil sie mit ihren eigenen Berechtigungen eh alles können oder dass sie mal schnell den einen oder anderen Transport übersehen. Je mehr man sich auf andere verlassen kann, umso mehr schleichen sich auch solche Nachlässigkeiten ein. Liegt wohl in der menschlichen Natur. Ein schlechtes Testteam oder gar der Verzicht auf Tests stellen keine wirkliche Alternative dar.

Bei der Diskussion der Vorgehensmodelle (wie dem Wasserfallmodell) hat sich bereits gezeigt, dass viele Grenzziehungen verschwimmen. Im agile software blog findet sich ein Beitrag der die verschwimmenden Grenzen zwischen den Rollen (Programmierer, Tester, Projektmanager und Usability Experte) vor dem Hintergrund agiler Softwareentwicklung thematisiert.

Das Wasserfallmodell geht von einer strikten sequentiellen Abfolge der Phasen Konzeption, Realisierung, Test, Implementierung aus.

Ganz im Gegensatz hierzu postulieren die Anhänger agiler SW-Entwicklung eine möglichst häufige iterative Abfolge dieser Phasen.

Mit Genuss findet sich bei Anhängern agiler Methododik daher auch Häme über das Wasserfall-Modell. Mit Zitaten belegte, grottenschlechte (Miss-)Erfolgsbilanzen konventionellen Wasserfall-Modell folgenden Vorgehens hat der agile software blog ausgegraben:

Some quotes on waterfall

Ohne die vernichtenden Ergebnisse anzweifeln zu wollen und ohne die Erfolge agiler Methoden herunterzuspielen: Zu prüfen bleibt im Einzelfall die Durchsetzbarkeit agiler Methodik. Diese basiert zu einem großen Teil auf Vertrauen und einem kooperativem Miteinander, dem Vertragsbeziehungen häufig entgegenlaufen. Auf der anderen Seite: Kann ein Projekt ohne Vertrauen und kooperatives Miteinander überhaupt erfolgreich sein?

Linus Torvald, der Vater von Linux bringt es auf den Punkt: die meisten Spezifikationen und Anforderungsbeschreibungen sind das Papier nicht wert, auf dem sie stehen:

„A ’spec‘ is close to useless. I have never seen a spec that was both big enough to be useful and accurate.“

(aus: Linux – Linus on Specifications)

Agile Softwareentwicklung „tickt“ anders als gewohnt: Statt brav sequentiell im Wasserfallmodell Anforderungsanalyse, Konzeption, Umsetzung, Test und Produktivsetzung abzuarbeiten, wird mit vielen kleinen iterativen Zyklen gearbeitet.
Aber mal ehrlich: das Wasserfallmodell haben wir doch schon lange nicht mehr so genau genommen. Die Überlappung von Phasen, mitunter auch ein zyklisches Springen zwischen den Phasen gehören längst dem Projektalltag an.
Insofern ist es nur konsequent dieser Realität auch methodisch gerecht zu werden, z.B. mit SCRUM, einem Methodenset der agilen Softwareentwicklung, bzw. einem Projektmanagementframework für agile Projekte.
Diese Darstellung agiler Softwareentwicklung ist zugegebenermaßen reichlich verkürzt. Um der Sache halbwegs gerecht zu werden hier wenigstens noch der Link zur zugrundeliegenden Philosophie: dem Manifesto for Agile Software Development.

„Als Rettungsversuch für ein in Not geratenes Projekt sollten Sie keinesfalls skalieren oder verteilen. Ist der Fertistellungstermin der Software unrealistisch, sind die Anforderungen nicht verstanden oder Architektur. und Technologieauswahl nicht tragfähig, so verschlimmert das Hinzufügen von neuen Mitarbeitern oder von weiteren Standorten die Situtation. Dies besag Brooks Law: ‚Adding manpower to a late software project makes it later'(…). Bedenken Sie: Neue Mitarbeiter können erst nach einer Einarbeitungsphase produktiv mitarbeiten. Ist ein Projekt in Schwierigkeiten geraten, so sollten Sie eine Ursachenforschung betreiben und dann die richtigen Maßnahmen ergreifen.“

aus Roman Pichler, Scrum – Agiles Projektmanagement erfolgreich einsetzen. Heidelberg 2008, S. 128 (Amazon Affiliate Link)