Jedes inkrementelle Vorgehensmodell basiert auf der Idee der kleinen Schritte zur Reduktion der Komplexität. Mit dem Cynefin-Framework können wir die evolutionäre Natur komplexer Systeme veranschaulichen. In den Inkrementen reduzieren wir jedes vorliegende komplexe Problem in ein kompliziertes, manchmal sogar offensichtliches Problem. Damit machen wir ein komplexes Problem beherrschbar. Wir wollen maximal flexibel gegenüber Veränderungen sein, ohne in Chaos abzudriften.

17-inkrementell-dokumentieren

Die agile Software-Entwicklung basiert auf einem inkrementellen Vorgehen. In einem Wiki arbeiten wir auch nach diesem Prinzip, denn Wissen kann inkrementell erfasst werden.

Inkrementelle Entwicklung

Betrachten wir agile Software-Entwicklung am Beispiel Scrum. In Scrum dreht sich alles um Sprints. Ein Sprint ist das Versprechen, für eine begrenzte Zeit ein gemeinsames Ziel zu verfolgen, das nicht mehr verändert wird. Für begrenzte Zeit haben wir eine sehr stabile Planung. Scrum benötigt nur drei Rollen und fordert von den Personen Disziplin bei den Zeremonien. Der Product-Owner hat eine Vision und einen langfristigen Plan, das Product-Backlog, welches er immer wieder anpasst. Er zeigt sich verantwortlich für das Produkt – strategisch und finanziell. Die Aufgabe des Scrum-Masters ist es, dem Team ungestörte Arbeit zu ermöglichen und die Einhaltung der Zeremonien zu überwachen. Der Scrum-Master interagiert insofern auch mit dem verantwortlichen Product-Owner. Das Team ist selbstorganisiert und entscheidet ohne Projektleiter und äußeren Einfluss selbst, wie die Arbeit erledigt wird. Die Größe des Teams liegt bei 3 bis 9 Personen. Der Entwurf der Software-Architektur, Programmieren, Testen und Dokumentieren der Software sind Aufgaben eines cross-funktionalen Teams. Neben der Stärkung der Zusammenarbeit geht es vor allem darum, das komplexe Problem in den Griff zu bekommen. Insgesamt lässt sich beobachten, dass die Vorteile agiler Entwicklung allgemein akzeptiert sind.

Kontinuierliche Verbesserungen

Scrum sagt nichts darüber aus, wie das Team programmieren und dokumentieren soll. Aber mit der Retrospektive gibt es eine Zeremonie mit dem Ziel, Probleme im geschlossenen Kreis zu besprechen (Las-Vegas-Prinzip) und Potentiale für Verbesserungen zu ermitteln. Längst haben sich Prinzipien und Praktiken bei den Entwicklern etabliert, die gerne in einem Atemzug mit Scrum genannt werden: Die Forderung nach lesbaren Code (englisch clean code), Vermeidung von Redundanzen (Prinzip DRY), die Reduktion auf das Notwendige (Prinzip KISS), um nur einige Beispiele zu nennen. Viele dieser Praktiken und Prinzipien ermöglichen eine kontinuierliche Verbesserung der Code-Basis. Auch im Bereich Test gibt es viele Ansätze, um den hohen Anspruch an die Qualität durch Testabdeckung und – automatisierung zu erfüllen. Mit der sogenannten Test-Pyramide wird der Mix verschiedener Test-Arten verdeutlicht. Aufbauend auf einer großen Zahl von Unit-Tests werden abhängig von Test-Strategie und Software-Architektur schrittweise Integrations- und Akzeptanz-Tests ergänzt. Test-getriebene Entwicklung (englisch test driven development, kurz TDD) zielt auf möglichst hohe Testabdeckung ab, als Kernaufgabe des Teams. Bei verhaltensgetriebener Entwicklung (englisch behaviour driven development, kurz BDD) handelt es sich um Praktiken für das Schreiben von Tests, die idealerweise gemeinsam mit TDD und Unit-Tests zum Einsatz kommen. Im Prinzip zeigt BDD, wie man richtig testet – nämlich nicht die Implementierung, sondern das Verhalten des Codes.

Permanente Kommunikation

Ein wesentliches Ziel der Zeremonien von Scrum ist die permanente Kommunikation. Am Anfang eines jeden Sprints wird ein Sprint Planning Meeting abgehalten. Der Product-Owner vermittelt dem Team, welche Änderungen am Produkt notwendig sind. Das Team entwickelt einen Plan für die Umsetzung und entscheidet, wie viele der Anforderungen im Sprint umgesetzt werden. Jedes Mitglied des Teams kann seine Meinung sagen und muss dem Plan für den Sprint zustimmen (englisch comittment). An jedem Arbeitstag des Sprints findet ein sogenanntes Daily Scrum statt. Es ist ein maximal 15 minütiges Meeting, bei dem das Team seinen Tag gemeinsam plant und mit dem Scrum-Master über mögliche Hindernisse (englisch impediments) spricht. Der Product-Owner kann am Daily Scrum teilnehmen und zuhören, um so ganz direkt und aktuell informiert zu werden. Schließlich gibt es noch das Sprint Review Meeting. Es ist der Abschluss des Sprints und öffentlich, d.h. neben dem Team, dem Scrum-Master und dem Product-Owner können auch Stakeholder teilnehmen. Im Meeting präsentiert das Team selbst die Ergebnisse des Sprints. Der Product-Owner entscheidet, ob eine Anforderungen vollständig und korrekt umgesetzt wurde. Stakeholder können zusätzlich wertvolles Feedback geben.

Inkrementell dokumentieren

Im Manifest für agile Software-Entwicklung steht geschrieben, dass wir funktionierende Software mehr als umfassende Dokumentation schätzen sollen. Es steht jedoch nirgends geschrieben, auf Dokumentation komplett zu verzichten. Eine angemessene Produktdokumentation ist genauso wichtig wie das fertige Produkt, beides muss vorhanden sein. Was liegt also näher, als beides inkrementell zu erstellen und laufend zu aktualisieren? Viele Arbeitsweisen, Praktiken und Prinzipien der Entwickler lassen sich auch auf Aufgaben der Business-Analysten und Redakteure technischer Dokumentation übertragen. Redundanzen in der Dokumentation führen häufig zu widersprüchlichen Texten. Sie sind aufgrund fehlender Metriken und Werkzeuge noch schwerer zu finden als duplizierter Code. Das Ziel einer User-Story ist eine einfach und kompakt formulierte Anforderung. Eine gemeinsame Sprache, die sich an der fachlichen Domäne orientiert, vermeidet Missverständnisse. Inkrementell dokumentieren bedeutet aber auch, dass wir zwischen Projekt- und Produktdokumentation trennen müssen. Am Beginn eines Sprints benötigt ein Team sehr viel Wissen über das Produkt. Diese umfangreiche Projektdokumentation transformiert das Team während des Sprints in Code und Test. Am Ende des Sprints muss eine Produktdokumentation genau das beschreiben, was nicht durch Code und Test ausreichend beschrieben wird. Eine angemessene Dokumentation schließt daher genau diese Lücke.

Fazit

Agile Methoden beinhalten immer ein schrittweises Voranschreiten. Als agile Methode profitiert CARDS+ von den Erkenntnissen aus der inkrementellen Entwicklung und nutzt die Vorteile durch kontinuierliche Verbesserung. Permanente Kommunikation ist ein Erfolgsfaktor auch bei der Anforderungsanalyse. Jede Dokumentation hat wie Code eine innere Struktur, besteht aus Bausteinen mit einem klar formulierten und prüfbaren Inhalt. Es bietet sich ganz einfach an, eine Produktdokumentation im gleichen Prozess zu schreiben, in dem auch das Produkt programmiert und getestet wird. Die Tätigkeit des Dokumentierens muss wie Programmieren und Testen zur Kernaufgabe des cross-funktionalen Teams werden.