Programmieren ist eine kreative Tätigkeit, mit dem Ziel, Wissen in Software zu übersetzen. Die Devise lautet: Programmieren ist dokumentieren. Autoren der Produktdokumentation im Wiki setzen bewährte Prinzipien und Praktiken der Entwickler ein. Sie entwickeln Dokumente schrittweise, weil die Bausteine klar definiert und aufeinander aufbauend sind. Sie erstellen Inhalte in hoher Qualität, weil sie prüfbar sind. Der Produktverantwortliche erklärt in der Systembeschreibung, «wer» «wann» «welche» Fähigkeit der Software braucht. Die Frage, «wie» die Software funktioniert, beantwortet das Team in jedem Produktinkrement mit Spezifikationen und Testplänen — durch Veröffentlichung. Diese Prinzipien und ihre praktische Umsetzung mit cards+ sind Erfolgsfaktoren agiler Software-Entwicklung.
Mit «wir» sind dabei alle am Produkt beteiligten Personen gemeint, also interessierte Parteien, Produktverantwortliche und die gesamte Projektorganisation.
Wir machen implizites Wissen explizit
Wissen ist ein sehr wertvolles Gut. Wissen steckt aber erst einmal in den Köpfen der beteiligten Personen. Es ist implizit. Lesbar programmiert und angemessen kommentiert kann Code mit den Bausteinen Domain, Service, Entity, Event und Layout als explizites Wissen im Wiki veröffentlicht werden. Ein Produktverantwortlicher hat fundierte Kenntnisse über den Einsatz der Software. Er kennt die Ziele, die der Auftraggeber mit der Software verfolgt. Mit den Bausteinen Topic, Epic und Case kann er dieses Wissen mit dem Team teilen.
Wir können alle Dokumente prüfen
Prüfbarkeit ist ein wichtiges Qualitätsmerkmal einer guten Produktdokumentation. Durch die klare Struktur im Wiki und den Regeln für Inhalt und Form der Bausteine von cards+ haben Autoren ein Gerüst, an dem sie sich beim Schreiben orientieren können. Mit der Durchführung eines Reviews wird eine Seite formal und inhaltlich von anderen Autoren hinsichtlich dieses Gerüstes überprüft. Diese zielgerichtete Qualitätsprüfung ist eine planbare Aufgabe in einem agilen Entwicklungsprozess. Ergänzend dazu prüft jeder Leser beim Lesen der Seiten neben der Richtigkeit auch die Verständlichkeit der Inhalte. Mit der Kommentarfunktion im Wiki kann er dem Autor einer Seite nachvollziehbares Feedback geben. Jederzeit.
Wir sichern unser ganzes Wissen
Vollständigkeit ist ein weiteres wichtiges Qualitätsmerkmal einer guten Produktdokumentation. Die Bausteine Topic, Epic und Case reichen, um alle Fähigkeiten der Software als Systembeschreibung vollständig und prüfbar zu dokumentieren. Die Bausteine Domain, Service, Entity, Event und Layout beschreiben die Systemstruktur des IT-Systems vollständig und prüfbar. Der Baustein Decision reicht, um den Architekturentwurf nachvollziehbar als Sammlung aller für das IT-System relevanter Entscheidungen mit Begründung zu erfassen. Mit dem Baustein Concept werden die Konsequenzen der Entscheidungen dokumentiert.
Wir lernen angemessen Dokumentieren
Angemessenheit ist ein Ziel, für das es keine eindeutigen Regeln gibt. Trotzdem ist es ein wichtiges Ziel, weil nur so Dokumentieren zu einer leistbaren Aufgabe wird. Der vorgegebene Aufbau der Bausteine hilft den Autoren, das richtige Maß für den Umfang der Dokumente zu finden. Viele bekannte Praktiken und Prinzipien der Entwickler sind leicht auf die Arbeit im Wiki übertragbar. Mit Prinzipien wie KISS, DRY oder INVEST verfolgen Autoren beim Dokumentieren die gleichen Ziele wie Entwickler beim Programmieren. Ein Dokument ist angemessen, wenn ein Leser den Inhalt versteht und für seine eigene Arbeit verwenden kann. Bei der gemeinsamen Arbeit im Wiki bekommen die Autoren durch Feedback der Leser die notwendigen Impulse zur kontinuierlichen Verbesserung der Produktdokumentation.
Wir verstehen uns besser
Interessierte Parteien und die gesamte Projektorganisation finden schell eine gemeinsame Sprache. Das ist ein Erfolgsfaktor für die Qualität der Ergebnisse eines agilen Entwicklungsprozesses. Durch das Glossar und die Bausteine der Systemstruktur werden wichtige Begriffe eindeutig definiert und ausreichend gut erklärt. Das Wiki verschafft sowohl Lesern als auch Autoren einen Überblick über das Produkt und fördert ein gemeinsames Verständnis für Probleme und Lösungen.
Wir schaffen echten Wert für alle
Eine Produktdokumentation hat einen Wert für alle interessierten Parteien und die gesamte Projektorganisation. Sie wird aufgrund ihrer Qualität wertgeschätzt. Von allen. Autoren streben eine vollständige und richtige Dokumentation an. Das gelingt nur, wenn die Dokumente prüfbar sind. Die Dokumentation muss schlüssig sein, ihre Inhalte dürfen sich nicht widersprechen. Jedes Wissen wird am besten nur einmal erfasst. Dazu werden Teile vom Code, Spezifikationen und Testpläne durch Veröffentlichung im Wiki für alle lesbar.
Wir entwickeln Dokumente schrittweise
Eine Produktdokumentation wächst mit dem Produkt. Sie ist ein Ergebnis des agilen Entwicklungsprozesses. Sie muss daher mit dem gleichen Maßstab für die Qualität, mit dem gleichen prozessorientierten Ansatz für empirische, inkrementelle und iterative Arbeitsweise und mit den gleichen Werten hergestellt wird, wie auch die Software entwickelt wird. cards+ erweitert die Grenzen der Produktdokumentation. Im Wiki wird nichts dokumentiert, was Entwickler bereits angemessen mit lesbaren Teilen vom Code spezifizieren oder Tester bereits angemessen mit Testplänen in einer Testpyramide beschreiben. Mit jedem neuen Produktinkrement gibt es neue dokumentierte Informationen, die im Wiki veröffentlicht werden.
Wir achten auf dauerhaft hohe Qualität
Eine Produktdokumentation wird über die gesamte Lebenszeit eines Produktes benötigt. Durch Veränderungen im Projektumfeld oder in der Projektorganisation geht regelmäßig Wissen verloren, wenn es nicht dokumentiert wurde. cards+ ist ein prozessorientierter Ansatz für die Erfassung von Wissen mit einem hohen Anspruch an die Qualität der Ergebnisse. Autoren erfassen Wissen, wann es entsteht. Sie erarbeiten es zusammen mit den interessierten Parteien und Domänenexperten. Dabei unterstützen sie sich gegenseitig und lernen voneinander. Sie setzen das simple Prinzip der Pfadfinderregel für die Steigerung der Qualität der dokumentierten Informationen ein. Ein «sauberes» Dokument ist entsprechend den Vorgaben des Bausteins vollständig und hat keine offensichtlichen Fehler oder Lücken.