Die Methode CARDS+ ist ein agiler Ansatz, um Wissensmanagement in Software-Projekten richtig zu organisieren und zielgerichtet und inkrementell zu dokumentieren. Mit einer festen Struktur in einem Wiki und Prinzipien und Praktiken der Entwickler bringen wir Effizienz und Qualität in die Erstellung und Pflege einer Produktdokumentation.

Dokumentation “entwickeln”

Ein einigermaßen komplexes Software-Produkt ohne Dokumentation ist für mich nicht vorstellbar. Jedoch können oder müssen wir uns über den Prozess der Erstellung der Dokumentation Gedanken machen. Im allgemeinen Sprachgebrauch werden Dokumente geschrieben oder erstellt, nicht entwickelt. Ein Dokument zu entwickeln bedeutet für mich, es schrittweise aufzubauen. Das geht aber nicht mit jeder Art von Dokumentation.

Dokumente können wir ganz grob in Projekt- und Produktdokumentation einteilen. Die Beschreibung einer Aufgabe in einem Backlog, eine Anforderung an das Produkt, Anweisungen, Richtlinien, Analysen, Protokolle, Abstimmungen, etc. sind Teil der Projektdokumentation.

Die Verwaltung und Bewertung einer Anforderung ist nicht Teil der Methode CARDS+. Das Ergebnis der Anforderungsanalyse wird jedoch mit den Bausteinen Epic und Case angemessen in der Produktdokumentation dokumentiert

Für die Erfassung und Steuerung von Aufgaben in einem Backlog bietet CARDS+ keinen Baustein an. Mit den Bausteinen Case und Layout kann jedoch wichtiges Wissen für eine Aufgabe frühzeitig und strukturiert in der Produktdokumentation erfasst werden.

Im Projektalltag finden laufend Abstimmungen statt. Ein Prinzip des agilen Manifests besagt, dass die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ein Gespräch von Angesicht zu Angesicht ist. Abstimmung mit großer Tragweite führen zu Entscheidungen, die es wert sind, dokumentiert zu werden. CARDS+ bietet dafür den Baustein Decision an.

Projektdokumentation ist unverzichtbar für das Aufrechterhalten unserer Prozesse und der Kommunikation in der Projektorganisation.

CARDS+ bietet für die Projektdokumentation keine Lösung!

Die Artenvielfalt ist einfach zu vielfältig, die Bedürfnisse der interessierten Parteien zu unterschiedlich und die Lebensdauer der Dokumente sehr oft zu gering für einen wirtschaftlich vertretbaren Ansatz einer Standardisierung.

Ganz anders verhält es sich mit einer Produktdokumentation. Sie wird über die gesamte Lebenszeit eines Produktes gebraucht. Ein Produkt entsteht, indem Visionen und Ideen in Software transformiert werden. Testfälle sichern die Qualität der Software ab. Konzepte, Spezifikationen und Handbücher geben Einblick in die Funktionen des Produktes für Nutzer, Betreiber und Entwickler der Software. CARDS+ will eine Projektorganisation in die Lage versetzen, eine angemessene, korrekte und vollständige Produktdokumentation für alle Zielgruppen zu erstellen und über die gesamte Lebenszeit des Produktes in gleichbleibender Qualität zu pflegen. Die Dokumentation braucht dafür eine prüfbare Struktur mit aufeinander aufbauenden und auf ihren Zweck ausgerichtete Bausteine.

Bausteine im Produktmanagement

Für das Produktmanagement gibt es unterschiedliche Vorgehensmodelle. Agile Ansätze setzen vor allem auf Flexibilität und Anpassung. Statt ausführlicher und umfangreicher Planung zu Beginn eines Projekts werden das adaptive Planen in Sprints, schnelles Erkennen von Problemen (englisch: fail fast) sowie die effiziente Kommunikation im Team unterstützt.

Der Auftraggeber und interessierte Parteien (z.B. Nutzer) bestimmen den Umfang des Produktes. Der Baustein Topic dokumentiert diesen Rahmen. Wichtige Begriffe aus den Abstimmungen mit Auftraggeber und Fachleuten erfassen wir sofort im Glossar. Eine weitere Detaillierung ist häufig nicht sofort möglich. Trotzdem können wir mit den Bausteinen Epic und Case allein durch den Titel und einer vorläufigen Beschreibung wichtiges fachliches Wissen sichern.

Der Autor (i.d.R. der Product-Owner) nutzt den Baustein, um sein Verständnis vom Umfang (englisch: scope) des Produktes zu beschreiben. Mit der Beschreibung konkretisiert er so früh wie möglich seine Vision des Produktes. Er tut das am besten bereits beim Start des agilen Entwicklungsprojektes, unter Einbeziehung des Auftraggebers.

Ein Leser (z.B. der Auftraggeber) kann sich durch die Liste der untergeordneten Epics einen sehr kompakten Überblick (englisch: management summary) über den fachlichen Rahmen des Produktes verschaffen.

Weiterlesen auf cardsplus.info

Der Autor (i.d.R. der Product-Owner) hat mit dem Baustein die Möglichkeit, produktspezifische Anwendungsteile frühzeitig mit einem guten Titel zu versehen und so den Grundstein für eine gemeinsame Sprache von Auftraggeber, Product-Owner und Team zu legen.

Ein Leser (z.B. Entwickler oder Tester) lernt einen wichtigen Begriff der fachlichen Domäne kennen.

Weiterlesen auf cardsplus.info

Mit dem Baustein kann der Autor (i.d.R. der Product-Owner) einzelne Fähigkeiten des Produktes vorläufig beschreiben. Zum Start der Entwicklung kann ein Case identifiziert werden, der geeignet ist für die Realisierung eines fachlichen Durchstichs, eines Experimentes zur Verifizierung technischer Konzepte. Auch in späteren Phasen des Projektes kann ein Case verwendet werden, um neue oder geänderte technische Konzepte zu überprüfen.

Ein Leser (z.B. Entwickler oder Tester) kann sich frühzeitig über eine geforderte Fähigkeit des Produktes informieren.

Weiterlesen auf cardsplus.info

Neben der Definition des Umfanges eines Produktes mit dem Baustein Topic treffen wir wichtige Entscheidungen, die in der Regel große Auswirkung auf die Entwicklung des Produktes haben. Solche Entscheidungen werden dadurch charakterisiert, dass es für ein bestimmtes Problem mehr als eine denkbare Lösung gibt. CARDS+ hat den Baustein Decision, um das Problem mit allen betrachteten Lösungen zu dokumentieren – auch jene, die ausgeschlossen wurden. Vor allem geht es darum, die Wahl einer bestimmten Lösung nachvollziehbar zu begründen.

Der Autor (i.d.R. der Product-Owner oder der Gärtner des Teams) erfasst frühzeitig, am besten bereits beim Start des agilen Entwicklungsprojektes, mit dem Baustein wichtige Rahmenbedingungen des Auftraggebers für das Produkt.

Ein Leser (z.B. Entwickler oder Tester) kann seine Entscheidungen abhängig von diesen Randbedingungen treffen.

Weiterlesen auf cardsplus.info

Der Baustein Decision kann auch für die frühzeitige Dokumentation von Qualitätsmerkmalen verwendet werden. Hier gibt es immer mindestens zwei Lösungsoptionen: Das Qualitätsmerkmal ist relevant oder eben nicht. Aus wirtschaftlicher Sicht sind frühe Entscheidungen zu Qualitätsmerkmalen, bewusst und korrekt getroffen, ein echter Erfolgsfaktor.

Bausteine der Anforderungsanalyse

Anforderungen zum richtigen Zeitpunkt, in der richtigen Tiefe und verständlich dargestellt, das ist die Aufgabe der Anforderungsanalyse (englisch: requirements engineering). Die Umsetzung der Anforderung muss sich in den Grenzen bewegen, die durch die im Projektmanagement festgelegten Topics gesetzt werden. Die erfolgreiche Zuordnung einer Anforderung zu einem Topic ist darum die erste Validierung einer Anforderung.

Anforderungen sind Teil der Projektdokumentation. Erst durch die “Anwendung” einer Anforderung auf das Produkt und seine Architektur entsteht Produktdokumentation mit den Bausteinen Epic und Case. Mit beiden Bausteinen wird der Problemraum des Produktes beschrieben, nicht die Anforderung. Die weitestgehend vollständige Beschreibung in den Epics und Cases ist die zweite Validierung einer Anforderung.

Für eine effektive, zielgerichtete Entwicklung ist es essentiell, dass das Team alle Probleme vollständig versteht, damit es eine passende und wirtschaftlich umsetzbare Lösung finden kann. Betrachten wir das Vorgehen bei der Analyse, dann nutzen wir eine Anforderung, um mindestens ein neues Problem zu identifizieren.

  • Ein “großes” Problem, z.B. ein neuer Anwendungsteil, beschreiben wir mit dem Baustein Epic. Im selben Schritt können wir bereits erkennbare Standardfunktionen mit dem Baustein Case erfassen.
  • Für ein “kleines” Problem, z.B. ein neue Funktion in einem existierenden Anwendungsteil, gibt es bereits ein Epic. Wir müssen nur mehr die neue Funktion mit dem Baustein Case beschreiben.

In beiden Situationen bleibt die Lösung im Baustein Case offen, wir konzentrieren uns auf die Beschreibung der Ausgangslage.

Der Autor (i.d.R. der Product-Owner oder der Gärtner des Teams) gibt mit diesem Baustein im Abschnitt Motivation einen groben Überblick (englisch: big picture) über den Anwendungsteil aus der Perspektive eines Nutzers. Fast genauso wichtig wie der Überblick über die Funktionen in diesem Epic (“Was”) ist die Abgrenzung zu anderen Epics (“Was nicht”).

Ein Leser (z.B. Entwickler oder Tester) enthält genau die Information, die notwendig ist, um den Anwendungsteil zu verstehen. Gleichzeitig bietet ein Epic dem Leser eine Übersicht über alle untergeordneten Cases.

Weiterlesen auf cardsplus.info

Der Autor (i.d.R. der Product-Owner oder der Gärtner des Teams) beschreibt die Ausgangslage einer einzelnen Funktion aus der Perspektive eines Nutzers.

Ein Leser (z.B. Entwickler oder Tester) muss die Ausgangslage für eine Funktion verstehen, um im Rahmen der Architektur eine Lösung zu finden.

Weiterlesen auf cardsplus.info

Ein perfektes Nutzererlebnis (englisch: user experience) ist ein Qualitätsmerkmal jeder erfolgreichen Anwendung. Für das Verständnis eines Anwendungsteiles, wie er im Baustein Epic beschrieben wird, ist es hilfreich, die Perspektive der Nutzer einnehmen zu können. Ein geeignetes Instrument ist das Konzept der Persona. Eine Persona ist keine wirkliche Person, sondern sie charakterisiert einen bekannten Nutzertyp mit ausgeprägten Eigenschaften und einem konkreten Nutzerverhalten. Sie schafft Empathie und ein Verständnis für Personen, welche das Produkt wirklich bedienen. CARDS+ hat zwar keinen vordefinierten Baustein für eine Persona. Aber auch ohne Baustein kann eine Persona anhand ihres eindeutigen Namens in die Beschreibung im Baustein Epic integriert werden. Zusätzlich werden mit dem Baustein Layout Skizzen der UX-Designer in der Produktdokumentation erfasst. Das ist besonders wertvoll bei der Beurteilung der Komplexität einer Benutzeroberfläche. Denn sehr oft gilt: Ein Bild sagt mehr als tausend Worte.

Der Autor (i.d.R. der UX-Designer oder der Gärtner des Teams) nutzt den Baustein, um Entwürfe für eine Benutzeroberfläche oder Bilder eines Prototypen zu veröffentlichen.

Ein Leser (z.B. Entwickler oder Tester) bekommt eine Vorstellung, wie die Benutzeroberfläche aussehen soll.

Weiterlesen auf cardsplus.info

Bei agilen Vorgehensweisen kommt laufend Feedback vom Team und interessierten Parteien (englisch: stakeholder). Wir sind dadurch in der Lage, die Produktdokumentation kontinuierlich zu verbessern. Das Wissen über den Problemraum des Produktes wächst.

Dokumentation “agil” entwickeln

Die Werte des agilen Manifests bilden das Fundament agiler Entwicklung. Mit CARDS+ kann auch Dokumentation agil entwickelt werden. Agil Dokumentieren bezeichnet ein schrittweises Erfassen von Entscheidungen und Wissen in einem agilen Prozess. Die Struktur der Produktdokumentation ist so gestaltet, dass jedes Ergebnis in einem Prozessschritt mit einem geeigneten Baustein gesichert werden kann. Wir schreiben nur das auf, was wir jetzt wissen. Keine Wünsche, keine Vermutungen. Aufgrund der maßgeschneiderten Struktur können wir trotzdem jeden Baustein in kurzer Zeit abschließen. Eine wichtige Bedingung für ein agiles Entwicklungsprojekt, um Dokumentation als ein weiteres Ergebnis eines Sprints zu fordern.

Die bisher vorgestellten Bausteine Topic, Epic, Case (ohne Lösung) und Layout beschreiben den Problemraum des Produktes. Sie bilden die Systembeschreibung. Alle weiteren Bausteine von CARDS+ sind Teil der technische Dokumentation. Sie zerfällt in die Bereiche Architekturentwurf und Systemstruktur.

Die Bausteine der technischen Dokumentation schaffen die Grundlage für eine gemeinsame Sprache von Product-Owner, Entwickler und Tester durch eine frühzeitige Festlegung von Begriffen im Glossar und Namen für Komponenten und wichtigen Objekten mit den Bausteinen Domain, Service, Event und Entity. Die gemeinsame Sprache gilt dann nicht nur für die Produktdokumentation, sondern findet sich auch in den Namen von Klassen und Namensräumen im Code wieder.

Bausteine für den Architekturentwurf

Der Architekturentwurf ist ein Sammelbegriff für Dokumentation, mit der wir wichtige Entscheidungen und Konzepte beschreiben. Bevor Entwickler eine Entscheidung treffen, betrachten sie in der Regel mehrere Alternativen. Am Ende bleibt eine Lösung als gut begründeter Favorit übrig. Oder keine Lösung ist geeignet.

Software architecture is the set of design decisions which, if made incorrectly, may cause your project to be cancelled.
Eoin Woods

CARDS+ folgt der Grundidee, dass die konsequente Dokumentation aller getroffenen Entscheidungen, deren Rücknahme bzw. Veränderung große Auswirkung auf das Produkt haben, sinnvoll ist. Programmiersprachen, Architekturstile, Betriebssysteme, Infrastrukturen, Bibliotheken und Werkzeuge beeinflussen ganz wesentlich das Produkt. Der Baustein Decision ist geeignet, solche Entscheidungen nachvollziehbar zu dokumentieren.

Der Autor (i.d.R. ein Vertreter oder der Gärtner des Teams) erfasst fundamentale Entscheidungen des Teams mit großer Tragweite. Die Ausgangslage beschreibt er “lösungsoffen” und vergleicht mindestens zwei Lösungsoptionen (z.B. SWOT-Analyse). Eine Decision spiegelt immer den aktuellen Stand der Diskussion im Team wieder und hat daher auch einen Status (in Arbeit oder entschieden). Eine Entscheidung wird immer begründet.

Ein Leser (z.B. Entwickler oder Tester) hat eine Übersicht über wichtige Entscheidungen und kann nachlesen, wann und von wem sie getroffen und wie sie begründet wurde.

Weiterlesen auf cardsplus.info

Konzepte verwendet ein Team, um Konsequenzen von Entscheidungen in einem größeren Zusammenhang zu bringen. Ein wiederkehrendes Muster bei der Implementierung (englisch: pattern) oder ein übergreifende Konzept wird mit dem Baustein Spec festgehalten. Eigenschaften, Einschränkungen und Besonderheiten von Modulen, d.h. “fremden” Bestandteilen eines Produktes, werden ebenfalls mit dem Baustein Spec erfasst. Ein besonderes Augenmerk liegt in beiden Fällen auf den nicht funktionalen Aspekten.

Der Autor (i.d.R. ein Vertreter oder der Gärtner des Teams) verwendet den Baustein zum Veröffentlichen eines produktspezifischen Konzeptes. Er geht auf Details zur Umsetzung und auf nicht funktionale Aspekte ein. Eine Spec spiegelt immer den aktuellen Stand der Diskussion im Team wieder und hat daher auch einen Status (in Arbeit oder gültig).

Ein Leser (z.B. Entwickler oder Tester) kann sich über wichtige übergreifende Konzepte informieren.

Weiterlesen auf cardsplus.info

Der Autor (i.d.R. ein Vertreter oder der Gärtner des Teams) verwendet den Baustein zum Aufbau eines Verzeichnisses von Produkten anderer Hersteller. Er gibt Hinweise auf Dokumentationen des Herstellers, klärt nicht funktionale Aspekte, Lizenzbedingungen und Möglichkeiten für technischen Support. Produktspezifische Handlungsanweisungen runden die Beschreibung gegebenenfalls ab.

Ein Leser (z.B. Entwickler oder Tester) kann sich über wichtige im Einsatz befindliche Produkte anderer Hersteller informieren.

Weiterlesen auf cardsplus.info

Entscheidungen werden hinterfragt. Konzepte werde angepasst. Die Bausteine Decision und Spec sind jedoch eine große Chance, unnötige Vielfalt in den Lösungen zu vermeiden. Entwickler können jederzeit nachlesen, welche Lösungen in der Vergangenheit erfolgreich umgesetzt wurden. Neue Lösungen sind nur dann notwendig, wenn die bekannten Lösungen nicht mehr reichen oder äußere Einflüsse (z.B. geänderte Qualitätsmerkmale) uns dazu zwingen.

Bausteine der Systemstruktur

Unter dem Sammelbegriff Systemstruktur bündelt CARDS+ die Bausteine Domain, Service, Event und Entity. Sie haben das Ziel, die Struktur der Software zu erfassen und einen Überblick über das Zusammenspiel der Komponenten geben.

Software architecture is loosely defined as the organizational structure of a software system including components, connections, constraints, and rationale.
Paul Clements

Die Begriffe aus dem “domain driven design” wurden bewusst für die Bezeichnung der Bausteine von CARDS+ gewählt. Auch das Ziel der gemeinsamen Sprache verfolgen beide Ansätze.

Der Autor (i.d.R. ein Vertreter oder der Gärtner des Teams) gibt einer Zusammenstellung von Komponenten und Objekten mit einer starken Kohäsion einen gemeinsamen Namen.

ktip Das Team kann den Baustein nutzen, um die Struktur im Code-Repository (z.B. Git) im Wiki zu dokumentieren.

Ein Leser (z.B. Entwickler oder Tester) findet in diesem Baustein Wissen, das ihm hilft, die Struktur der Software zu verstehen.

Weiterlesen auf cardsplus.info

Der Autor (i.d.R. ein Vertreter oder der Gärtner des Teams) gibt einer Komponente mit dem Titel einen eindeutigen Namen. Er pflegt den Steckbrief (u.a. die verwendeten Technologien) und beschreibt die Komponente so, wie er sie einem Kollegen zum Einstieg erklären würde. Zusätzlich bietet der Baustein die Gelegenheit,

  • technische Prozesse im Inneren,
  • Optimierungen im Code,
  • Abweichungen von übergreifenden Konzepten und
  • Einschränkungen der Implementierung

zu dokumentieren. Ganz allgemein geht es um Wissen, das gar nicht oder nur sehr schwer aus dem Code herausgelesen werden kann.

ktip Das Team muss beachten, dass der Autor den Baustein nicht nutzt, um etwas zu dokumentieren, was an anderer Stelle bereits vom Team dokumentiert wurde. Testfälle der Testpyramide sind ein Beispiel. Für die Beschreibung der der technischen Prozesse bietet sich die Integration von Asciidoc– oder Markdown-Dokumenten aus dem Code-Repository (z.B. Git) in das Wiki an.

Ein Leser (z.B. Entwickler oder Tester) findet in diesem Baustein Wissen, das ihm hilft, die Komponente zu verstehen.

Weiterlesen auf cardsplus.info

Der Autor (i.d.R. ein Vertreter oder der Gärtner des Teams) gibt einem Nachrichtenobjekt (z.B. Ereignis, Meldung oder zeitgesteuerter Auslöser) mit dem Titel einen eindeutigen Namen. Er pflegt den Steckbrief und beschreibt wichtige Eigenschaften des Objektes so, wie er sie einem Kollegen zum Einstieg erklären würde. Zusätzlich bietet der Baustein die Gelegenheit,

  • die Herkunft des Nachrichtenobjektes,
  • Abweichungen von übergreifenden Konzepten und
  • Einschränkungen der Implementierung

zu dokumentieren. Ganz allgemein geht es um Wissen, das gar nicht oder nur sehr schwer aus dem Code herausgelesen werden kann.

ktip Das Team muss beachten, dass der Autor den Baustein nicht nutzt, um etwas zu dokumentieren, was an anderer Stelle bereits vom Team dokumentiert wurde. Für die Beschreibung der technischen Spezifikation des Objektes bietet sich die Integration von Schemabeschreibungen (z.B. Avro oder XSD) aus dem Code-Repository (z.B. Git) in das Wiki an.

Ein Leser (z.B. Entwickler oder Tester) findet in diesem Baustein Wissen, das ihm hilft, das Nachrichtenobjekt zu verstehen.

Weiterlesen auf cardsplus.info

Der Autor (i.d.R. ein Vertreter oder der Gärtner des Teams) gibt einem wichtigen Informationsobjekt mit dem Titel einen eindeutigen Namen. Er pflegt den Steckbrief und beschreibt die Identität und weitere wichtige Eigenschaften des Objektes so, wie er sie einem Kollegen zum Einstieg erklären würde.

ktip Anders als bei den Bausteinen Service und Event gibt es nicht nur eine Implementierung für ein Informationsobjekt. Das bedeutet, dass es in der Regel nicht nur eine konkrete Umsetzung gibt. Der Baustein Entity gilt in diesem Fall nur als “Verständnismodell”. Die genaue Definition der Identität eines Objektes hilft beim Entwurf der Persistenz von Komponenten.

Ein Leser (z.B. Entwickler oder Tester) findet in diesem Baustein Wissen, das ihm hilft, das Informationsobjekt zu verstehen.

Weiterlesen auf cardsplus.info

Ein Punkt ist besonders wichtig: Wir brauchen keine Dokumentation, die im Detail erklärt, wie Code funktioniert. Lesbarer Code, Code-Kommentare und code-nahe Artefakte zählen bei CARDS+ auch als Dokumentation.

Nur im Code steckt die Wahrheit!

Das ist eine Tatsache, die wir akzeptieren und zu unserem Vorteil verwenden, indem wir zumindest code-nahe Artefakte für unsere Produktdokumentation erschließen.

Ab diesem Zeitpunkt gilt: Programmieren ist dokumentieren!

Bei agiler Entwicklung mit Scrum kann ein Product-Owner die Regeltermine Refinement, Sprint-Planning und -Retrospektive nutzen, um Feedback auch zur Produktdokumentation einzusammeln.

Das “missing link” der Dokumentation

In der Systembeschreibung beschreiben wir den Problemraum. Dieser Teil der Dokumentation ist das Abbild der Realität, die Wirklichkeit. Je mehr wir über die Welt wissen, in dem das Produkt eingesetzt wird, desto besser werden unsere Lösungen. Das Produkt beschreiben wir mit den Bausteinen des Architekturentwurfs und der Systemstruktur. Dieser Teil der Dokumentation ist das Abbild der Realisierung, das Ergebnis des Entwicklungsprozesses. Bei agiler Entwicklung schreitet die Produktdokumentation im Gleichschritt mit dem Produkt voran. Das Ende eines Sprints ist der Punkt, an dem Dokumentation, Code und Testfälle eine Einheit bilden: Das Produktinkrement.

Das “missing link” der Dokumentation ist der Baustein Case. Er bildet den Übergang der Systembeschreibung in die Systemstruktur und umgekehrt.

  • Ein Product-Owner kann aus seiner fachlichen Sicht ableiten, welche technischen Komponenten (Baustein Service) und Objekte (Bausteine Event und Entity) an der Lösung einer Funktion (Baustein Case) seines Produktes beteiligt sind.
  • Ein Tester kann einschätzen, welche Funktion (Case) sich auf eine Komponente (Baustein Service) auswirkt, für die er Testfälle schreibt.
  • Ein Entwickler kann den fachliche Kontext (Bausteine Topic, Epic und Case) seiner Komponente (Baustein Service) für sein Verständnis herausfinden .

Der Baustein Case hat den Abschnitt Ausgangslage, in dem wir eine einzelne, nicht weiter teilbare Funktion des Produktes beschreiben. Nach Abschluss der Realisierung der Funktion ergänzen wir die gewählte Lösung in Form von Essenzschritten. Diese kompakte Liste beschreibt die Lösung als eine Art Pfad durch die Komponenten des Systems. Sie ist eine Art “Navigation” durch die Komponenten des Systems und bildet den Übergang von der fachlichen in die technische Sicht.

Der Autor (z.B. ein Vertreter oder der Gärtner des Teams) ergänzt die Ausgangslage einer einzelnen Funktion um die Beschreibung der Lösung aus der Perspektive eines Entwicklers.

Ein Leser (z.B. Entwickler oder Tester) kann neben der fachlichen Ausgangslage einer Funktion die Lösung im Rahmen der Architektur nachlesen.

Weiterlesen auf cardsplus.info

Jetzt ist das Feedback des gesamten Teams mit moderierten Kommentaren im Wiki besonders wichtig. Es ist für die Qualität der Produktdokumentation entscheidend, Fehler im Produktinkrement frühzeitig zu erkennen und alles Wissen für das Verständnis der Software zu sammeln. Sofort, nicht später.

Es gilt: Dokumentiert ist kommuniziert!

In einer Kultur der direkten Kommunikation und vollständigen Transparenz ist die Produktdokumentation ein zusätzlicher Kanal, über den das Team Wissen austauscht. Jeder ist Leser. Durch die klare Struktur mit den Bausteinen und der Einsatz eines Wiki gibt es für ein motiviertes Team keine Hürden, die sie vom Dokumentieren abhalten könnten. Jeder kann daher auch Autor sein.

Fazit

CARDS+ tritt mit dem Versprechen an, die Erstellung und Pflege einer qualitativ hochwertigen Produktdokumentation zu ermöglichen. CARDS+ ist kein geschlossenes Vorgehensmodell, kein Prozess. Aus diesem Grund kann CARDS+ in bestehende Prozesse integriert werden. Autoren können jede Technik des Projektmanagements und der Anforderungsanalyse verwenden, um Ergebnisse zu produzieren. CARDS+ ist hier als Werkzeug zu verstehen.