Dokumentieren in agilen Methoden (Teil 4) – Crystal

Im dritten Teil unserer Blogserie zum Thema „Dokumentieren in agilen Methoden“ haben wir Ihnen Lean Software Development (LSD) vorgestellt. Sie möchten die Inhalte noch einmal nachlesen? Hier geht’s zum vorherigen Artikel.

Im letzten Teil der Serie möchten wir Ihnen Crystal als agiles Framework vorstellen. Wie in der Blogserie bisher üblich werden auch hier die definierten Rollen und Artefakte des Frameworks erläutert. Die Inhalte des Beitrages stammen aus dem Buch Crystal Clear – A Human-Powered Methodology for Small Teams [1] sowie aus einem Vergleich von fünf agilen Methoden [2].

Crystal ist eine Methodensammlung für die Entwicklung von Systemen in Teams. Die darin enthaltenen Methoden haben sich bereits in der Community bewährt und können von den Entwicklungsteams individuell auf ihr Projekt angepasst werden. In Crystal wird das Projekt in kleine Teile, die Iterationen, zerlegt. Deren Länge variiert je nach Projekt zwischen einer Woche und zwei Monaten. Ziel dieser iterativen Vorgehensweise ist, dass durch eine frühe Auslieferung möglichst schnell Feedback vom Kunden in die Produktentwicklung einfließt. Bei Crystal muss nicht zwangsweise nach jeder Iteration ein auslieferbares Produktinkrement vorliegen. Wann Auslieferungen erfolgen, wird vom Management definiert. Nach jeder Iteration wird die Arbeitsweise des Teams im Entwicklungsprozess analysiert und bei Bedarf angepasst. Crystal ist sehr stark auf eine optimierte Kommunikation innerhalb des Teams ausgelegt und verzichtet daher auf eine detaillierte Prozessbeschreibung. Lediglich in der Praxis erprobte Strategien und Techniken zur Prozessverbesserung werden aufgezeigt.

Crystal-Projekte sind in zwei Dimensionen kategorisierbar. Je nach Gruppengrößen bekommt Crystal eine Farbbezeichnung zugewiesen. Je mehr Mitglieder am Projekt arbeiten, desto dunkler wird die Farbe von Clear über Yellow, Orange und Red. In der zweiten Dimension erfolgt eine Einschätzung der Kritikalität, in Form eines Härtegrades. C bezeichnet eher einfache Probleme. Die Auswirkungen von Fehlern steigen mit D, E und L immer weiter an. In Tabelle 1 ist die Kategorisierung der Crystal-Methoden dargestellt. Der Grund für diese Kategorisierung ist, dass Crystal je nach Farbe und Härtegrad verschiedene Basismethoden zur Verfügung stellt. Zu diesen Methoden zählen beispielsweise Reflection Workshops, das Blitz Planing oder Daily Stand-ups.

Blog_DokuCrystal_Bild 1

Tabelle 1 – Klassifizierung der Crystal-Projekte [2]

In den folgenden Abschnitten werden die verschiedenen Rollen in Crystal vorgestellt. Außerdem erfolgt eine Zuordnung verschiedener Artefakte, die diese Rollen betreffen und die die Durchführung des Projektes unterstützen.

In jedem Crystal-Projekt existieren unabhängig von der Projektgröße ein Sponsor, verschiedene User, der Lead Designer und Designer Programmer. Crystal empfiehlt, diese vier Rollen mit unterschiedlichen Personen zu besetzen, um deren Verantwortlichkeiten klar abzugrenzen. Je nach der Größe des Projektes können weitere spezialisierte Rollen im Team auftauchen. Dazu zählen Business Expert bzw. Expert User, Technical Facilitator, Business Analyst/Designer, Project Manager, Architect, Design Mentor, UI Designer, Reuse Point, Writer und Tester. Der Reuse Point identifiziert wiederverwendbare Softwarekomponenten innerhalb des Systems. Writer sind für die Erstellung der Dokumentation zuständig. Eine Verteilung mehrerer Rollen auf eine Person ist möglich. Tabelle 2 liefert einen Überblick über die Rollenverteilung.

Blog_DokuCrystal_Bild 2

Tabelle 2 – Die Rollen in Crystal im Überblick

„Ich brauche Geld!“ – Der Sponsor stellt den Geldgeber im Projekt dar. Er entscheidet in kritischen Situationen über die Umverteilung des Geldes auf die einzelnen Bereiche im Projekt. Dafür benötigt er alle Informationen vom Team, die ihm bei der Entscheidungsfindung unterstützen. Er erstellt das Mission Statement, in dem der allgemeine Projektrahmen definiert ist. Darin werden allgemeine Ziele des Projektes, wie das Lieferdatum, Kosten oder auch Performance des Produktes, priorisiert. Der Umfang dieses Dokuments sollte eine Seite nicht überschreiten. Es stellt die grundsätzliche Ausrichtung des Teams dar.

Das Team selbst besteht aus allen beteiligten Personen und Rollen im Projekt. Es ist für die Bearbeitung der einzelnen Projektaufgaben und die Umsetzung der Anforderungen und damit für die Erstellung des Produktes verantwortlich. Mögliche Artefakte, die das Team erstellt, sind Regeln, Richtlinien und Methoden für die Teamarbeit. Es legt selbstständig die Rollenverteilung im Projekt und die Länge der Iterationen fest, die auch schriftlich in der Team Structure erfasst werden sollten. Am Ende einer jeden Iteration wird die bisherige Arbeitsweise untersucht und es werden Probleme, positive Aspekte und Verbesserungsvorschläge diskutiert. Festgehalten werden diese Punkte in den Reflection Workshop Results.

„Ein Team braucht einen Kapitän!“ – Eine der wichtigsten Rollen im Team ist die des Lead Designers. Dabei handelt es sich meist um einen sehr erfahrenen Entwickler, der das Team leiten kann. Er besitzt umfassende Kenntnisse im Design von Systemen und kann dieses Wissen an seine Teammitglieder übertragen. In größeren Projekten wird er dabei von einem Architect unterstützt. An der Erstellung einer Architecture Description sind beide Rollen beteiligt. Die Architecture Description ist eines der zentralen Bestandteile einer technischen Dokumentation. Dazu zählen beispielsweise Komponenten und Schnittstellen innerhalb des Systems. Diese Beschreibung wird in der Regel in einer frühen Phase des Projektes erstellt und im Folgenden weiter vervollständigt.

Crystal ordnet den Usern des Systems eine zentrale Position im Entwicklungsprozess zu. Sie liefern wichtige Informationen für die Funktionen, die das Produkt beinhalten muss. Häufig erfolgt eine Unterteilung der Nutzerrolle in Business Expert und Expert User. Der Business Expert ist mit den Business Rules, also branchentypischen Prinzipien, vertraut. Der Expert User besitzt Hintergrundwissen zu den Geschäftsprozessen und stellt einen Nutzerrepräsentant dar. Bei der detaillierten Funktionsbeschreibung werden sie von den Business Analysts und Business Designern unterstützt.

Das Wissen der User ist die Grundlage für die Actor-Goal List. Sie beschreibt, welchen Nutzern des Systems welche Anwendungsfälle zugeordnet sind. In den Use Cases werden die Anwendungsfälle der Akteure mit dem System, systeminterne Anwendungsfälle und das entsprechende Systemverhalten zum Ausdruck gebracht. Im Requirements Document werden Anforderungen und Designentscheidungen dauerhaft und nachvollziehbar festgehalten. Da Crystal zu den agilen Methoden zählt, handelt es sich bei diesen Artefakten um lebende Dokumente. So können Änderungen an den Anforderungen über den gesamten Produktlebenszyklus verfolgt werden.

Die Designer-Programmer repräsentieren die letzte entscheidende Rolle in Crystal. Sie bearbeiten die Projektaufgaben. Neben dem Quelltext zählen verschiedene Design-Sketches und -Notes zu ihren Artefakten. Auch Domain Modelle können während ihrer Arbeit entstehen. Zudem ist ihnen die Erstellung von Tests zugewiesen. Design-Programmer können beispielsweise die Rolle des UI Designers, des Database Designers oder des Testers übernehmen.

In umfangreicheren Projekten kann ein Project Manager die Koordination des Teams und des Entwicklungsprozesses übernehmen. In Abstimmung mit dem Team definiert er Meilensteine für die Projektdurchführung. In der Project Map werden alle Projektaufgaben, deren Abhängigkeiten und Prioritäten festgehalten. Im Release Plan werden diesen Aufgaben Fälligkeitsdaten zugeordnet. Außerdem können darin Termine für Nutzerinspektionen enthalten sein. Für die Projektüberwachung und einen schnellen Überblick ist es sinnvoll, auch die tatsächlichen Lieferdaten zu vermerken. Im Iteration Plan werden die Projektaufgaben für die Designer detaillierter aufgelistet. Bedrohungen für das Projekt werden von dem Project Manager und dem Team in der Risk List festgehalten. Sie ist Grundlage für die Verbesserung des Entwicklungsprozesses und die frühzeitige Erkennung von Fehlern.

Zugegeben, in Crystal stehen mehr Rollen und Artefakte zur Verfügung als beispielsweise in Scrum. Daraus ergibt sich folgende Frage:

„Müssen Sie alle Rollen verteilen und jedes Artefakt erzeugen?“

Crystal macht keine Vorgaben, welche Rollen bzw. welche Artefakte erzeugt werden müssen. Die Rollenverteilung sowie der Dokumentationsumfang sind sehr stark vom jeweiligen Projekt und vom Team abhängig. Es ist nicht notwendig, jede Rolle zu besetzten. Bei näherer Betrachtung wird allerdings deutlich, dass für einige Punkte die Verantwortlichen klar definiert werden sollten. Dazu zählt der Sponsor, der das Geld im Projekt verwaltet. Auch der Lead Designer und der Expert User bzw. Business Expert sollten in einem Projekt als technische und fachliche Ansprechpartner vorhanden sein. Die Designer-Programmer müssen sich nicht auf einen Fachbereich spezialisieren. Je nach ihren Fertigkeiten kann ihr Einsatzgebiet variieren.

Um den zweiten Teil der Frage nach den zu erzeugenden Artefakten zu beantworten, soll ein Verweis auf das Buch „Crystal Clear – A Human-Powered Methodology for Small Teams“ dienen:

„The question always arises as to just what documentation is needed. In Crystal Clear the answer is:

whatever the sponsor and the team decide.“

Die Tabelle 3 liefert einen Überblick über mögliche Artefakte in Crystal:

Blog_DokuCrystal_Bild 3

Tabelle 3 – Die Artefakte in Crystal im Überblick

Fazit

Crystal definiert viel mehr Artefakte als Scrum, ASD oder auch LSD. Diese Dokumente reichen von allgemeinen Punkten wie der Aufgaben- und Release-Planung bis hin zu Details in der Systemarchitektur (siehe Tabelle 3). Auch bei den Rollen nimmt Crystal eine feinere Trennung der Zuständigkeiten vor (siehe Tabelle 2). Dabei wurden in diesem Blog nur die wichtigsten Rollen vorgestellt und weitere mögliche zusätzliche Verantwortlichkeiten nur genannt.

Die vorgestellten Artefakte und Rollen sind bei der Verwendung von Crystal auf die jeweiligen Gegebenheiten im Projekt anzupassen. Es ist gut möglich, dass nur ein Teil der Artefakte erzeugt werden und dass nicht alle Rollen von einer Person besetzt sind. Die Entscheidungsgewalt über die Dokumentationsarbeit liegt wie in Scrum, ASD und LSD bei dem gesamten Team.

In unserer vierteiligen Blogserie haben wir Ihnen verschiedene agile Frameworks für die Softwareentwicklung vorgestellt und sind besonders auf den Aspekt der Dokumentation eingegangen. Wir haben gesehen, dass in keinem der Frameworks konkrete Aussagen zu Dokumentationsinhalten gemacht werden. Lediglich Empfehlungen zu Inhalten werden gegeben.

Aus diesem Grund beschäftigen sich die SOPHISTen derzeit mit der Entwicklung eines Leitfadens für die Dokumentation im agilen Umfeld. Neuigkeiten zu diesem Thema erhalten Sie wie immer in unserem SOPHIST-Blog.

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 Crystal können Sie direkt hier im Blog hinterlassen.

Literaturverzeichnis

[1]        Alistair Cockburn, Crystal Clear – A Human-Powered Methodology for Small Teams, Pearson Education, Inc., 2005.

[2]        Diane Elizabeth Strode, The Agile Methods: An Analytical Comparison of Five Agile Methods and an Investigation of Their Target Environment. Appendix K, Application of the analytical framework, 2007.

2 Gedanken zu „Dokumentieren in agilen Methoden (Teil 4) – Crystal

  1. Vielen Dank für die Darstellung der agilen Frameworks. Ein besonderes Interesse hätte ich an einer Auflistung der Vor- und Nachteile der einzelnen Frameworks in Bezug auf die Dokumentation. Welche strukturellen Hindernisse sehen Sie in den einzelnen Frameworks und wie kann man diese umgehen oder wie kann man Dinge und Prozesse umbauen, damit man bessere Lösungen bauen kann? (immer auf das Dokumentieren bezogen) Für Anregungen dieser Art wäre ich Ihnen sehr dankbar! (oder sogar die Weiterführung dieser Reihe?) Würde die Ergebnisse gerne zum Weiterdenken in meinen Blog mit einbeziehen: http://easyrequirement.blogspot.de/ :-)

  2. Hallo Herr Baumann,

    wir haben zu diesem Thema eine Masterarbeit, die Ihre Fragen beantworten sollte. Wir können sie aber leider nicht veröffentlichen. Falls Sie daran Interesse haben, können Sie sich gerne bei mir melden (andre.pflueger@sophist.de).

    Viele Grüße
    André Pflüger

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert