Scrum - unvollständig

10.05.2011 Permalink

Seit einigen Jahren drängt sich in Sachen agiler Softwareentwicklung die Methode "Scrum" (Einführung) -- zumindest in meiner Wahrnehmung -- in den Vordergrund. Auf Veranstaltungen und bei Kunden höre ich dagegen sehr selten die Namen eXtreme Programming, Crystal Clear oder Feature Driven Development. Auf der einen Seite ist es mir egal, welchen Namen das Kind trägt. Alle bringen die grundlegenden, sehr wertvollen Eigenschaften mit, die in umfangreichen Softwareprozessen leichter unter die Räder kommen. Darunter sind z.B.:

Es wird echter Fortschritt ("working increments") gemessen.
Feedbackzyklen und Lernen sind eingebaut.
Priorisierung und Änderung der Anforderungen sind eingebaut.

Der Marketingerfolg von Scrum macht mir auf der anderen Seite jedoch etwas Sorge, denn Scrum ist in puncto Handwerkszeug der Softwareentwicklung gewollt still. Offen bleiben daher zunächst Fragen wie:

Wer und wann führt Qualitätssicherung aus?
Wie werden querschnittliche Aktivitäten wie Architektur oder Aufbau von Build- und Releaseprozess, die nur mittelbaren "business value" bringen, eingeplant?
Gibt es eine fachliche Konzeption für die nicht-trivialen "user stories"?
Wie wird Usability Engineering integriert?
Wie erhält man die Änderbarkeit der Software, die essentiell für jeden agilen Prozess ist?

Natürlich findet man Unmengen von Material im Netz und in Büchern, wie man dieses oder jenes mit den Grundelementen von Scrum verknüpft. Doch diese Meinungen sind -- wenig überraschend -- weder vollständig noch widerspruchsfrei.

Scrum Phases erklärt, dass es nicht nur eine Folge von Sprints gibt, sondern auch ein Vorspiel für Planung und Architektur sowie ein Nachspiel für Integrationstests und Rollout-Vorbereitung gibt.
Oder Scrum and Quality Assurance behauptet, dass Feature Tests von der Güte eines klassischen Systemtests Teil jedes Sprints sind, wobei noch keine Stellung zu Regressionstests bezogen wird.
Trotz vieler Hinweise schweigt sich Agile Requirements Best Practices aus, wer zu welchem Zeitpunkt tatsächlich die Details zu einer User Story zusammenträgt, damit sie abschätzbar und implementierbar ist.
Dagegen schlägt Scrum and Documentation. vor, Anwendungsfallbeschreibungen und Testfälle im gleichen Sprint, in dem die Implementierung stattfindet, zu erstellen, wobei die Testdurchführung erst nach Ende des Sprints erfolgt.

Zunächst steht das Team, das Scrum einführen will, also vor der Aufgabe, Scrum den Rahmenbedingungen entsprechend anzufüttern, denn Scrum nach der reinen Lehre taugt nur etwas für Micky Maus Projekte. Das erinnert mich lustigerweise an die schwergewichtigen Prozesse wie RUP oder V-Modell XT, die auch erst durch Customizing, d.h. Formen und Beschneiden der umfangreichen Prozessbeschreibung, brauchbar werden. Beides erfordert sehr praxiserfahrene Mitarbeiter oder Berater (aha!).

Ich würde trotz meiner Kritik an Scrum eher den einfachen, agilen Prozess als Ausgangspunkt wählen und in diesen Software spezifische Aktivitäten einbetten, als einen Prozess wie RUP zurechtzuschneiden. Denn agile Verfahren sichern, dass man schon nach Wochen die Fähigkeit, laufende Software zu bauen, einschätzen kann, während sich Projekte, die aufwändigen Prozessen folgen, Monate mit sich selbst beschäftigen können, ohne den maßgeblichen Prüfstein "potentially shippable product" zu passieren.