Dokumentation ist ein Thema in jedem Projekt. Genau wie beim Programmieren von Code gibt es eine agile Methode, die es uns erlaubt, Dokumentation in guter Qualität zu erstellen und vor allem zu pflegen. In einem agilen Umfeld muss die Tätigkeit des Dokumentierens eine Aufgabe im cross-funktionalen Team sein. Wir müssen beim Dokumentieren die gleichen Werte vertreten wie beim Programmieren und Testen von Software. Die Produktdokumentation ist der Versuch, das wertvolle Produktwissen vollständig zu erfassen. Die Inhalte der Systembeschreibung, die Architekturdefinition und Handbücher müssen die gleichen Qualitätsansprüche erfüllen wie programmierter Code.

Die Methode CARDS+ besteht aus Prinzipien und Praktiken, die uns helfen, dieses Produktwissen langfristig in guter Qualität zu erhalten.  CARDS+ ist einfach. Die Methode orientiert sich ganz stark an agilen Methoden wie Scrum und XP, mit denen wir erfolgreich Software entwickeln. Die Produktdokumentation ist wie die Software ein Bestandteil des Produktes. Business-Analysten sind wie Entwickler und Tester Teil des cross-funktionalen Teams. Der Großteil der Aufgaben zur Erstellung und Pflege der Produktdokumentation wird wie das Programmieren und Testen der Software im Rahmen eines Sprints erfüllt.

Längst haben sich in den Projekten Werkzeuge für die Abbildung des Product- und Sprint-Backlogs durchgesetzt. Damit wurden aber die Grenzen aufgehoben, die durch die ursprüngliche Idee der Karten gesetzt wurden. Die Folge ist, dass sehr viel Produktwissen in Stories für den Kunden nicht mehr nutzbar ist. In letzter Konsequenz geht wertvolles Wissen verloren.

CARDS+ als Name der agilen Methode hat sich aus der ursprünglichen Idee der Karten (englisch: cards) von XP entwickelt. Das Plus-Zeichen steht einfach für Weiterentwicklung.

User stories are written on cards. The card does not contain all the information that makes up the requirement. Instead, the card has just enough text to identify the requirement, and to remind everyone what the story is. The card is a token representing the requirement. It’s used in planning. Notes are written on it, reflecting priority and cost. It’s often handed to the programmers when the story is scheduled to be implemented, and given back to the customer when the story is complete.
Ron Jeffries

Die Karte ist die Metapher für eine Seite im Wiki. Die Methode macht Vorgaben und definiert Strukturen für Inhalt und Gestaltung von Seiten in einem Wiki. Wie in der ursprünglichen Idee von XP besitzen wir mit den Seiten kompakte “Karten” für die Kommunikation. Stakeholder und Product-Owner schreiben “Karten” vom Typ Topic, um die Einordnung der Software in die Geschäftsfelder des Unternehmens zu beschreiben. Product-Owner und Business-Analysten benutzen “Karten” vom Typ Epic, um  den Bedarf der Nutzer aus Anforderungen an die Software zu erfassen. Analysten, Entwickler und Tester nutzen die “Karten” vom Typ Case und Layout für die Spezifikation der Software.

Es ist eine wesentliche Eigenschaft der Methode CARDS+, dass die Bausteine der Produktdokumentation wie die Karten eines Kartenhauses (englisch: house of cards) aufeinander aufbauen. Jede Karte muss in einer bestimmten Reihenfolge in einer festgelegten Art und Weise aufgestellt werden, um am Ende ein vollständiges Kartenhaus zu bilden.

Das Kartenhaus ist eine Metapher für die Produktdokumentation. Es ist nur dann stabil und vollständig, wenn alle Karten vorhanden sind. Fehlt eine Karte, dann stürzt das Kartenhaus in sich zusammen.

Eine weitere Analogie der Methode CARDS+ mit einem Kartenhaus ergibt sich aus der Form. Die Karten des Kartenhauses bilden eine Pyramide genau so wie die Ergebnisse der Methode verschiedene aufeinander aufbauende Ebenen sind. Das Kartenhaus visualisiert sehr schön die Idee der Vermittlung von Wissen vom Groben ins Feine (englisch: top down).

Mit CARDS+ haben wir die “besseren Karten”.