Die Grundlage agiler Softwareentwicklung
Die agile Softwareentwicklung ist, bis auf die unten aufgeführte Ausnahme, iterativ. Eine Iteration ist eine kurze Zeitspanne von einem Monat bis zu nur einer Woche. Die durchschnittliche Länge einer Iteration bei verschiedenen Teams liegt meiner Erfahrung nach bei einem Monat (der Scrum-Standard) bis einer Woche, was meine Empfehlung für einen XP-Zyklus ist. Ich glaube, der momentane Trend sind zwei Wochen.
Aber ich schweife vom Thema ab. Das wichtigste Element in Agile, die Conditio sine qua non, die notwendige Bedingung, die Voraussetzung, das, was mach auf jeden Fall tun muss, ist:
Das Team muss am Ende jeder Iteration funktionierende, getestete und integrierte Software liefern; in Scrum würde man sagen, sie muss „done-done” sein
Daran führt kein Weg vorbei. Sie können nicht nur in jeder zweiten Iteration etwas liefern. Sie können auch keine fast fertige Software liefern und sie dann in der nächsten Iteration fixen. Versuchen Sie erst gar nicht, sich davor zu drücken. Sie müssen Software liefern.
Eine Ausnahme
Wenn Sie dachten, dass Sie hier eine Möglichkeit finden, davon verschont zu bleiben, haben Sie falsch gedacht. Die einzige Ausnahme dafür, in jeder Iteration fertige Software auszuliefern, ist, sogar noch öfter etwas zu liefern. Einige Top-Teams arbeiten zurzeit in einer Art Kanban-Modus, bei dem sie Features im Wesentlichen kontinuierlich ausliefern, im Regelfall alle paar Tage.
Sorry, da führt kein Weg dran vorbei
Echte, funktionierende, integrierte, getestete, done-done Software – und das in jeder einzelnen Iteration, oder einfach permanent. Auf dem Weg dahin werden Sie lernen müssen, was das alles bedeutet, und dabei sicherlich auf Schwierigkeiten stoßen. Sie werden aber sicher auch bemerken, dass „done” mehr bedeutet als Sie dachten. Natürlich beinhaltet es auch die Gebrauchsanweisung. Natürlich beinhaltet es auch Anwenderschulungen. Natürlich beinhaltet es alles, wovon Sie glaubten, dass es nicht möglich sei.
Nobody’s perfect
Ihr Team ist nicht perfekt und wird all das wahrscheinlich nicht in jeder Iteration schaffen. Was Sie jedoch auf jeden Fall tun sollten, wenn Sie noch Raum zur Verbesserung haben, ist etwas, das in Scrum „Inspect & Adapt” genannt wird. Kent Beck sagte es einmal folgendermaßen: „Finde dein größtes Problem, löse es auf die XP-Weise und wiederhole das Ganze.”
Wenn Sie Hilfe dabei brauchen, holen Sie sich diese Hilfe.
Und jetzt fangen Sie an, diese Software zu liefern!
Dieser Text stammt aus dem Blog von Ron Jeffries und wurde von uns ins Deutsche übersetzt.