Weiterentwickelbare Software entwickeln mit Scrum

Dieser Artikel stammt aus unserem Blog, der nicht mehr betreut wird. Für Neuigkeiten zu oose und interessante Inhalte zu unseren Themen, folgt uns gerne auf LinkedIn.

In der ix 8/2010 wurde ein Artikel von mir zum Thema "Agiles Requirements-Engineering" unter dem Titel "Aufgespalten" veröffentlicht. Hierzu habe ich von einem Leser noch eine Frage bekommen und beantwortet - und die Essenz dieser Korrespondenz möchte ich hier kurz wiedergeben.

Die Frage war: "Am Ende des Projekts zerfällt das Scrumteam und wird ggf. für spätere Releases neu zusammengestellt. Geht nicht viel Know how verloren, was 'nur' in den Köpfen steckt, wenn es nicht auch festgehalten wird (über das notwendigste hinaus)? Ist es dann nicht sinnvoll, die stetig entwickelten Anforderungen auf ein gewisses Niveau anzuheben, dass eine Nachhaltigkeit sichert? Nur allzuoft steht man doch vor der Situation (insbesondere nach längeren Release-Pausen), nicht mehr zu wissen, was das System eigentlich kann. "

Eine ähnliche Frage hatte ich schon mal in einer Diskussion auf der ReConf in diesem Jahr gehört: "Produzieren wir mit Scrum nicht ein unmittelbar unwartbares und nicht mehr erweiterbares System (also ein Legacy-System), weil nur sehr wenig Anforderungswissen explizit (also außerhalb der Köpfe) gesichert wird?"

Ich persönlich glaube, dass dieser Punkt in Scrum nicht vollständig befriedigend beantwortet ist. Generell gibt es aber die folgenden Erwiderungen auf diesen Einwand:

1. Testautomatisierung und -abdeckung

   Wenn alle wichtigen Anforderungen durch Tests abgedeckt sind, sind sie damit auch dokumentiert. Das ist natürlich nur eingeschränkt hilfreich, weil automatisierte Tests formal spezifizierte Tests sind. Letztendlich ist der Code auch eine formale Spezifikation und in dem Sinne wäre das Programm also, wenn der Quellcode zu 100% vorliegt auch formal spezifiziert und dokumentiert. Solche formalen Spezifikationen/Dokumentationen helfen nur insoweit, wie sie für die an der Weiterentwicklung Beteiligten das richtige Abstraktionsniveau haben. Quellcode ist weitgehend unbrauchbar, formal spezifizierte Tests sind besser, aber eben auch selten optimal.

2. Explizit (Nach-)Dokumentation

   Wenn die Weiterentwickelbarkeit eine explizite Anforderung ist, die der Auftraggeber bezahlen möchte, ihm es also etwas wert ist, dann bekommt das Scrumteam eine explizite Aufgaben, die notwendige Dokumentation zu erstellen. Interessant ist dabei jedoch, dass wir jetzt unterscheiden müssen, zwischen den Anforderungen, die wir VOR der Realisierung erheben und beschreiben, um überhaupt programmieren zu können und denen die NACHHER beschrieben werden. Der Zweck und der Zeitpunkt ist also jeweils an anderer. Der Vorteil der nachfolgenden Anforderungsbeschreibung ist, dass sie auf eine fertige Lösung und Ist-Situation aufsetzt, also viel konkreter, stabiler und weniger spekulativ ist, also auch weniger schnell veraltet. Der beste Zeitpunkt ist wahrscheinlich ein Kompromiss zwischen ausreichender inhaltlicher Stabilität (möglichst spät) und noch gut genug bei den Beteiligten in Erinnerung (also möglichst früh), auf jeden Fall aber NACH der Realisierung.

Bernd Oestereich