Wir SOPHISTen bekommen immer wieder von unseren Kunden die Frage gestellt: „Wie viel Dokumentation benötigen wir in unseren Projekten?“ Eine konkrete Antwort auf diese Frage sieht meist so aus: „So wenig wie möglich aber so viel nötig.“

In einer vierteiligen Blogserie wollen wir die agilen Methoden Scrum, Adaptive Software Development, Lean Software Development und Crystal genauer beleuchten. Dabei soll geklärt werden, welche Vorgaben hinsichtlich der Dokumentation in den einzelnen Methoden gemacht werden.

Beginnen wollen wir unsere Blogserie mit Scrum, da das vermutlich das bekannteste Framework zur agilen Produktentwicklung ist. Die folgenden Inhalte stammen aus dem Scrum Guide [1] bzw. aus dem Scrum Handbook [2].

Scrum ist ein iteratives Framework zur Realisierung von komplexen Aufgabenstellungen. Es unterstützt die Projektbeteiligten bei der Projektplanung und –verwaltung. Mit der Anwendung von Scrum wird der Entwicklungsprozess transparent gestaltet. Das heißt, für alle Projektbeteiligten ist der aktuelle Status des Produktes ersichtlich. Durch regelmäßige Inspektionen werden Probleme im Prozess aufgedeckt und können angepasst werden. Scrum kann auf die meisten Anwendungs- und Produktentwicklungsprojekte angepasst werden.

Was bedeutet iterativ? Iterativ bedeutet, dass der gesamte Entwicklungsprozess in kleine gut überschaubare Teile, die Sprints, zerlegt wird. Anders als bei vielen älteren Softwareentwicklungsframeworks wie dem V- oder Wasserfall-Modell verzichtet Scrum auf eine ausführliche Planungsphase. Innerhalb dieser Phase zu Beginn eines Projektes entstehen sehr umfangreiche Dokumente, die meist keiner der Projektbeteiligten im Nachhinein liest und die schnell veralten. Scrum beschränkt sich auf minimale Verwaltungs- und Planungsarbeiten und legt den Fokus klar auf die Auslieferung des Produktes.

Verschwindet damit die Dokumentation ganz aus dem Entwicklungsprozess? Diese Frage wird in den folgenden Abschnitten beantwortet, indem die einzelnen Rollen und Artefakte erläutert werden.

Eines der zentralen Artefakte in Scrum ist das Product Backlog. Jede Anforderung, die das zu erstellende Produkt erfüllen muss oder soll, wird in dieser geordneten Liste mit Backlog Items aufgeführt. Häufig werden User Stories zur Formulierung der Requirements verwendet. Darin ist aus der Sicht der Anwender beschrieben, was das Produkt können soll. Außerdem werden Kriterien für die Abnahme des Ergebnisses definiert. Erstellt und verwaltet wird das Product Backlog vom Product Owner. Diese Person ist verantwortlich für die von den Developern zu verrichtende Arbeit. Der Product Owner erstellt, priorisiert bzw. ordnet und erläutert die einzelnen Einträge für die Developer näher.

Das Sprint Backlog enthält die Backlog Items, die während der aktuellen Iteration bearbeitet werden sollen. Die Developer entscheiden welche Anforderungen oder Aufgaben aus dem Product Backlog in das aktuelle Increment, also die aktuelle Produktversion, aufgenommen werden sollen. Diese Auswahl geschieht anhand der Ordnung der Aufgaben durch den Product Owner sowie einer Aufwandsschätzung durch die Developer und der Betrachtung der für den aktuellen Sprint zur Verfügung stehenden Zeit. Das Sprint Backlog hilft den Developern bei der Planung und der Aufgabenzuteilung. Es unterliegt einer hohen Änderungsfrequenz und kann daher nur bedingt dauerhaft festgehalten werden.

Tabelle 1 – Die Artefakte in Scrum im Überblick

Die letzte verbleibende Rolle stellt die des Scrum Masters dar. Zu dessen Aufgaben gehört die Unterstützung der Akteure im Entwicklungsprozess bei der korrekten Anwendung von Scrum. Beispielsweise kann der Product Owner Techniken zur Erstellung und Verwaltung von Product Backlog Items erfragen. Auch das Entfernen von Hindernissen für die Developer fällt in die Verantwortung des Scrum Masters. An der direkten Bearbeitung des Product Backlog oder Sprint Backlog ist er nicht beteiligt.

Tabelle 2 – Die Rollen in Scrum im Überblick

SOPHIST-Empfehlungen zur Dokumentation

Scrum macht den Developern keine Einschränkungen, welche Inhalte in welcher Form dokumentiert werden sollen. Zu den elementaren Bestandteilen der Dokumentation zählen die Anforderungen an das System. Als Hilfsmittel dazu liefert Scrum das Product Backlog bzw. das Sprint Backlog. Nahezu alle Anforderungen durchlaufen diese beiden Artefakte. Den Umfang und die Detailstufe für die Konservierung können die Developer selbst wählen. Use Case Diagramme dienen beispielsweise als Hilfsmittel. An dieser Stelle ist es besonders wichtig, dass alle Fachbegriffe definiert sind, um so den Interpretationsspielraum bei den Projektbeteiligten einzuschränken. Ein Glossar oder Begriffsmodell kann viele Unklarheiten beseitigen. In Abbildung 1 ist dazu ein Begriffsmodell zu den Rollen, Artefakten und deren Beziehungen in Scrum für einen schnellen Überblick aufgeführt.

Abbildung 1 – Begriffsmodell zu Scrum

Das Wissen, das während der Verfeinerung und Bearbeitung der Aufgaben von den Developern gesammelt wird, kann beispielsweise durch Modelle und Diagramme festgehalten werden. Sequenz- und Aktivitätsdiagramme dienen unter anderem zur Visualisierung der Geschäftsprozesse und Abläufe im System. Ein Vorteil von Modellen ist, dass sie untereinander verknüpft werden können. Dadurch lassen sich zum Beispiel Use Cases zu den modellierten Geschäftsprozessen zuordnen.

Fazit

In unserem Blog haben wir Ihnen die Rollen in Scrum vorgestellt. In Tabelle 2 sind diese kurz für Sie zusammengefasst. Neben den Rollen in Scrum haben wir Ihnen die Artefakte dieses Frameworks vorgestellt. Tabelle 1 fasst diese für einen schnellen Überblick zusammen.

Wir haben erläutert, dass in Scrum keine Vorgaben für den Umfang und die Detailstufen der Projektdokumentation definiert sind. Dadurch hat das Scrum-Team maximale Freiheiten und kann selbst über diese Punkte entscheiden. Genau an dieser Stelle liegt allerdings auch eine große Schwierigkeit: es gibt keine Richtlinien für eine sinnvolle Dokumentation.

An dieser Stelle haben wir Ihnen einige Empfehlungen für das Dokumentieren vorgestellt. Diese reichen von einem Begriffsmodell bzw. einem Glossar über die Verwaltung der Requirements bis hin zur Erstellung von untereinander verlinkten Modellen.

Aus dem agilen Umfeld kennen Sie bisher nur Scrum? Dann empfehlen wir Ihnen den zweiten Teil unserer Blogserie. Dort werfen wir einen Blick auf Adaptive Software Development und die darin definierten Rollen und Artefakte.

Falls Sie Fragen haben, können Sie sich damit gerne per E-Mail (heureka@sophist.de) oder per Telefon (0911 40 900 0) an uns wenden. Kommentare, Anmerkungen oder praktische Erfahrungen mit Scrum können Sie direkt hier im Blog hinterlassen.

Literaturverzeichnis

[1]        K. Schwaber und J. Sutherland, The Scrum Guide – The Definitive Guide to Scrum: The Rules of the Game, Oktober 2011.

[2]        J. Sutherland, Scrum Handbook, 2010.