Mit agiler Entwicklung gegen Softwarefehler

30.09.2004
Von Chris Rupp

Eine weitere Erkenntnis aus der Diskussion um agile Vorgehensweisen ist, dass eine gute Ausbildung und viel Erfahrung zumindest bei einigen Projektmitarbeitern in der Praxis unabdingbar bleibt. Dies betrifft sowohl die Arbeitsmethoden als auch die soziale Kompetenz. Eingespielte Teams sind in diesem Zusammenhang unschlagbar. Weiter ist zu beobachten, dass Anfänger deutlich schneller lernen, wenn sie in erfahrene, agil arbeitende Teams integriert werden, weil sie die komplexen Zusammenhänge unmittelbarer erleben.

Wenn ein Projektteam sich und seine Verfahren nicht ständig in Frage stellt, übersieht es leicht Veränderungschancen. Besonders ausgeprägt ist dieses Motiv im agilen Vorgehensmodell "Scrum" von Mike Beedle. Allerdings gilt auch hier: Manchmal bleibt am besten alles beim Alten. Dann ist es aber wichtig, dies bewusst zu beschließen.

Das Management muss zudem dem Projektteam bis zu einem gewissen Grad vertrauen und ihm die Freiheit lassen, selbst seine Vorgehensweise zu wählen. Zumindest muss das Team die verwendeten Methoden frei auswählen können und von der Pflicht entbunden sein, sich an eine starre, beispielsweise vom Qualitätssicherungs- oder Methodenbereich definierte Vorgehensweise zu halten. Wichtige psychologische Aspekte sollten in diesem Zusammenhang aber nicht vergessen werden: "Agil sein" heißt anpassen, entscheiden, Verantwortung übernehmen. Wo bisher eine definierte Vorgehensweise einzuhalten war, liegt nun die Entscheidung oder Mitentscheidung im Team, und diese Verantwortung löst nicht immer nur Begeisterung aus, sondern häufig auch Ängste.

In vielen Unternehmen lagern heute noch tausende Zeilen noch nicht produktiven Codes. Damit bleiben zehntausende von Entwicklerstunden ungenutzt und die angestrebte Kostenminimierung oder Effizienzsteigerung durch neue Software tritt nicht ein. "Das Kapital, das man in eine Systementwicklung stecke, ist so lange "tot", bis es zum genutzten Release kommt," hat einmal XP-Begründer Kent Beck geschrieben.

Die Erfahrung mit agilen Verfahren hat hingegen gezeigt, dass der Mut und auch die Akzeptanz unter den Projektbeteiligten wachsen, wenn kleinere Release geplant und erreicht werden. Nützliche Inkremente lassen sich heute oft schon in zwei bis vier Monaten oder weniger entwickeln. Dauert dies länger als ein halbes Jahr liegt ein Problem vor. Was haben also die Jahre der Agilität gebracht? Den Projekten vor allem mehr Flexibilität und deutlich bessere Chancen, in unseren turbulenten Zeiten erfolgreich zu sein. Den Kunden stehen nun schneller und häufiger Systemversionen zur Verfügung, die sie unmittelbar nutzen können, und die nicht mehr von ihren Änderungen eingeholt werden.