Panel-Diskussion zum Agility-Day

Als Abschluss des JAX-Agility-Day findet eine Panel-Diskussion statt. Im Panel sitzen im wesentlichen die Vortragenden des Agility-Day.

Die erste Frage betrifft die Frage, wie ein Product-Backlog aussieht. Das ist natürlich je Projekt sehr unterschiedlich. Eine Variante ist, mit einem Prosa-Text der Anforderung in FIT/Fitnesse zu beginnen und daraus schrittweise Akzeptanztests zu machen. Die FIT-Tests und die Features im Issue-Tracker werden wechselseitig über URLs verlinkt.

Danach geht es um Stressfaktoren und die Frage, ob agiles Vorgehen mehr Stress schafft als klassisches Vorgehen. Jens Coldeway vertritt die These, dass agile Methoden erstmal mehr Transparenz bringen. Das kann im Einzelfall zu Stress führen. Dann müsste man aber gucken, wie man besser mit der Transparenz umgehen kann.

Dann kommt eine Frage nach Entwurf. Dem Frager erscheint der Entwurf nur entlang von Features wird als sehr gefährlich. Was ist dann mit der Infrastruktur? Die Antwort von Henning Wolf lautet, dass man eben anders mit Entwurf umgehen muss. "Inkrementeller Entwurf" und "testgetriebene Entwicklung" sind die Schlüsselwörter. Jens Coldeway sagt, er habe gut entkoppelte Systeme nur dort gesehen, wo man testgetrieben vorgegangen ist. Sich am Anfang sehr viele Gedanken über Architektur und Entwurf zu machen, führt zu Overdesign und damit unnötig hohen Kosten.

Aus dem Publikum wird nachgehekt: Was ist mit sehr großen Projekten (mehrere 100 Entwickler), die am Rande des Machbaren stattfinden? Antwort aus dem Panel: Prototypen, Spikes, Machbarkeitsstudien können natürlich auch in agilen Projekten stattfinden. Wichtig sei aber, dass man die Spikes möglichst an Business Features koppelt. Jutta Eckstein beginnt häufig mit einem Release 0, dass maximal 3 Monate dauert. In diesem Release 0 werden Architektur und Technologien anhand von Prototypen evaluiert. Nach Release 0 wird auf jeden Fall mit Produktiv-Releases weitergemacht, auch wenn die Entwickler eine Verlängerung des Release 0 wünschen.

Jetzt wird gefragt, ob der Overhead für Standup-Meetings, Release- und Iterationsplanung und Release-/Iterationsreviews nicht zu hoch sei. Das Panel meint, dass dieser Planungsaufwand eher unter dem Planungsaufwand im Wasserfall liegt. Bei den agilen Methoden wird der Aufwand nur explizit.

Passen denn agile Methoden zu CMMI etc., wird gefragt. Jens Coldeway sagt, die offizielle Stellungnahme von Watts Humphrey sei, dass XP auf CMM-Level-3 steht. Jutta meint provokant, dass mit Retrospektiven die agilen Methoden sogar auf Level 5 stehe :-) Insgesamt hält sich die Begeisterzung der Panel-Teilnehmer für CMMI etc. sehr in Grenzen. Jens Coldeway möchte sich eher am Geschäftswert orientieren als definierten Prozessen hart zu folgen.

Es wird gefragt, wie Teams untereinander "Verträge" schließen können, was die Schnittstellen und Protokollen zwischen ihren Systemteilen angeht. Jens Coldeway hat gute Erfahrungen gemacht mit ausführbaren Spezifikationen (Unittests mit Mocks).

Dann wird gefragt, wie man Teams synchronisiert. Wenn ein Team besonders schnell ist, sind die früher fertig als die anderen Teams. Daher planen agile Projekte immer grob eine zweite Iteration in die Zukunft. Wenn das Team sehr schnell ist, kann es mit den Folgefeatures weitermachen. Diese Doppelplanung verhindert auch, dass die Entwickler übrig gebliebene Zeit für rein technische Geschichten verwenden.

Was macht man, wenn der Kunde sich nicht so stark engagieren will oder kann, wie gefordert - der Kunde kann z.B. nur 2 Tage pro Monat ins Projekt investieren? Dann muss man die Kundenrolle substituieren, z.B. indem der Softwarelieferant einen "virtuellen" Kunden bei sich definiert. Das ist suboptimal, kann aber funktionieren. Man muss sich aber auch die Frage stellen, ob der Kunde seiner Aufgabe überhaupt sinnvoll nachkommen kann und ob man das Projekt nicht lieber ablehnen sollte.