Der Reise-Butler ist die Smartphone-App für den wissbegierigen Reisenden und Fallbeispiel für die Methode CARDS+.


Moritz will den Workshop zügig abschließen und beginnt damit, die beiden Plakate zu fotografieren. Tim ist als erster der Studenten zurückgekehrt und beobachtet Moritz in seinem Tun.

« Sollten wir das Ergebnis von heute nicht mit deinem CARDS+ dokumentieren? », fragt Tim plötzlich, als alle anderen Studenten ebenfalls wieder anwesend sind.

Unabhängig von der etwas seltsamen – oder provokativen – Formulierung ist die Frage überraschend für Moritz. Tim hat sich in den vergangenen Wochen seit Projektstart nicht unbedingt als begeisterter Autor im Wiki gezeigt. Moritz fragt vorsichtig nach: « Reichen dir die Plakate nicht? »

« Wir sind aber nicht immer hier! », antwortet Tim. Und er hat natürlich recht.

« Ja, klar », sagt Moritz. « Ich hatte ja auch gedacht, dass ich die Fotos im Teambereich in Confluence ablege. Den Teambereich gibt es noch nicht. Aber es ist eine sehr gute Gelegenheit, einen Bereich für uns als Team anzulegen. »

Tim ist offensichtlich noch nicht zufrieden. « Wir haben doch schon einen Bereich. Warum noch einen? »

Jetzt muss Moritz einen kurzen Moment nachdenken. Er ist sich nicht sicher, ob die Rückfrage auf einen Sinneswandel hinsichtlich dem Wiki zurückzuführen ist oder doch Tims flapsigen Art geschuldet ist. Immerhin hat er sich bis zuletzt gegen jede Art von Dokumentation mit Händen und Füßen gewehrt. Und plötzlich sorgt er sich um das Wiki. Moritz überlegt, wie er antworten soll.

« Im Wiki müssen wir zwischen Produkt- und Projektdokumentation unterscheiden. », zitiert er einen wichtigen Leitsatz von CARDS+ zur Abgrenzung des Einsatzbereichs der Methode.

Und jetzt holt er so richtig aus: « Wie der Name schon sagt, beschreibt eine Produktdokumentation das Produkt, sowohl aus fachlicher als auch technischer Perspektive. Gemäß der Methode CARDS+ besteht sie aus verschiedenen Bausteinen, die im Verlauf des agilen Entwicklungsprozesses verwendet werden, das Wissen über das Produkt zu erfassen, das nicht im Code oder in den Testfällen steckt. Es gibt zwei einfache Regeln für die Produktdokumentation. Es muss einen passenden Baustein geben und es darf keine Veränderung beschreiben. Alles andere gehört automatisch zur Projektdokumentation. Das ist dann jene Dokumentation, die gebraucht wird, um die Änderungen oder Verbesserungen am Produkt zu planen und zu steuern, z.B. mit Stories in einem Backlog. Verschiedene Arten von Plänen, Protokolle, Abstimmungen, Zwischenergebnisse, Analysen gehören ebenfalls dazu. »

Richard hat sich schon etwas mit CARDS+ beschäftigt und schlägt vor, die Plakate mit dem Baustein Decision zu dokumentieren. « Wir haben ja gemeinsam entschieden! », begründet er seinen Vorschlag.

Moritz entgegnet: « Warum sollten wir das tun? Diese Spielregeln haben doch nichts mit dem Produkt zu tun. Sie sind wichtig. Sie helfen uns als Team, Aufgaben besser zu bewältigen, effektiver zusammenzuarbeiten. »

Tim zeigt sich verwirrt. « Das verstehe ich nicht. Die letzten Wochen schwörst du uns auf die Wichtigkeit der Dokumentation ein. Und bei den Spielregeln reichen plötzlich Fotos. »

« Wie ich schon sagte, müssen wir zwischen der Produktdokumentation und einer Projektdokumentation unterscheiden. CARDS+ hilft uns, das Wissen über unser Produkt mit den vorgefertigten Bausteinen nachhaltig zu sichern. Die Produktdokumentation existiert so lange wie das Produkt selbst. Sie muss gute Qualität haben, muss korrekt sein. Sie muss einen Wert für uns haben, muss hilfreich sein. Sie ist Teil des Produktes, wie Code und Testfälle. Im Gegensatz dazu hilft uns die Projektdokumentation, unsere Zusammenarbeit zu planen und zu steuern. Protokolle sind nur für bestimmte Zeit interessant. Eine Story kann in der Regel archiviert werden, wenn sie erfolgreich umgesetzt wurde. Viele dieser Dokumente werden nur für kurze Zeit gebraucht oder veralten sehr schnell. »

Moritz macht eine kurze Pause und wartet, ob Tim etwas erwidern will.

Tim bleibt still, aber Richard hakt jetzt nach. « In vielen Beiträgen zu agiler Entwicklung wird betont, dass vor allem Kommunikation, also miteinander reden, der wesentliche Erfolgsfaktor ist. Bei Scrum gibt es das Daily und weitere Regeltermine am Beginn oder Ende des Sprints. Dadurch kann auf umfassende Dokumentation verzichtet werden. »

« Das ist vollkommen richtig”, stimmt Moritz zu. “Bleiben wir bei Scrum. Zu Beginn eines Sprints brauchen wir sehr viele Informationen und treffen Annahmen. Während des Sprints produzieren wir daraus Code. Wir schreiben Tests, um die Funktionalität abzusichern. Am Ende des Sprints ist ein neues Produktinkrement fertig. Und die Produktdokumentation muss ebenfalls fertig sein. Sie umfasst aber wesentlich weniger Informationen, als wir zu Beginn des Sprints hatten. Denn der Großteil der Informationen wurde in Code transformiert. »

Schweigen.

Anne meldet sich zu Wort. « Wenn ich dich richtig verstehe, dann nutzen wir die Projektdokumentation, um uns auf den Sprint vorzubereiten. Am Ende des Sprints machen wir daraus Code, Tests und Bausteine im Wiki. »

Moritz nickt. « Ich hätte es nicht besser formulieren können! Und ich würde an der Stelle noch einen Schritt weiter gehen. Wir nutzen Projektdokumentation, wenn wir sie brauchen. Wir können aber auch darauf verzichten, wenn wir den Austausch von Informationen auch ohne schriftliche Dokumentation schaffen. »

In dieser Art und Weise diskutieren sie noch eine Weile. Am Ende kristallisiert sich heraus, dass sie tatsächlich versuchen wollen, mit einer minimalen Projektdokumentation zu starten. Moritz wird den Teambereich in Confluence anlegen und die Fotos hochladen. Er wird eine Startseite mit den Kontaktdaten der Teammitglieder gestalten. Auf sanften Druck von Moritz werden sie aber eine Produktdokumentation erstellen und pflegen. Die Methode CARDS+ ist gesetzt. Er wird die Rolle des Gärtners im Wiki übernehmen, verspricht, dass er alle Seiten vorbereiten wird, sobald sie gebraucht werden. Das Team hat die Verantwortung, rechtzeitig jeden Bedarf anzumelden und Moritz die notwendigen Informationen zuzuspielen. Das Team verpflichtet sich außerdem, das Wiki aktiv zu nutzen und Fehler in den Seiten direkt auszubessern oder Ideen, Fragen oder offene Punkte als Kommentare zu hinterlassen.

Zuletzt veröffentlichte Beiträge: