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


Die Ankündigung von Moritz, Anforderungen gemeinsam zu analysieren und mit Bausteinen der Methode CARDS+ zu dokumentieren, hat das Team der Studenten überrascht. Einerseits haben sie erwartet, dass die Anforderungen bereits klar sind, andererseits kennt keiner von ihnen CARDS+. Moritz und Julius, der sich schnell als Sprecher des Teams etabliert, haben vereinbart, heute einen Workshop mit dem ganzen Team durchzuführen. Ziel der Veranstaltung ist eine Einführung in die agile Methode. Eine Stunde reicht Moritz nach seiner Einschätzung, um die Grundidee zu vermitteln. Er hat bereits alle Topics und nach seiner Einschätzung für den Projektstart wichtige Epics im Wiki angelegt. Die Begriffe, die er dort verwendet hat, sind im Glossar erfasst. Seine Einführung in der nächsten Stunde möchte er interaktiv gestalten, nur mit Flipchart und einem Satz Stifte bewaffnet. Seinen Laptop mit Beamer hat er aufgebaut, um Beispiele aus dem Wiki zu zeigen.

Alle sitzen, haben ein Getränk und ihren Notizblock vor sich. Moritz legt los. Er schreibt Projektdokumentation auf das Flipchart und streicht es gleich wieder durch.

« Zur Projektdokumentation zählen Protokolle, Berichte, Übersichten und Pläne. Sie ist notwendig, wir brauchen sie, damit unsere Prozesse funktionieren. Wir beschreiben damit Veränderungen, zeigen den aktuellen Status oder präsentieren den Fortschritt. », erklärt er um gleich darauf zu ergänzen: « Aber darüber reden wir heute nicht. »

Dann schreibt er Produktdokumentation und unterstreicht es mit den Worten: « Dafür werden wir CARDS+ einsetzen. Das hat erst Mal nichts mit Scrum zu tun, es gibt aber eine ganz wichtige Gemeinsamkeit: Agilität! »

Er lässt das Wort kurz wirken und erklärt weiter: « Es geht um inkrementelles Dokumentieren, passend zur agilen Entwicklung. Wir wollen gemäß dem agilen Manifest eine angemessene Beschreibung unseres Produktes am Ende jedes Sprints haben. »

Moritz schaut in die Runde und fährt fort: « Das Wichtigste ist, dass die Dokumentation mit dem Produkt wächst. Genau wie Entwickler ihren Code schrittweise aufbauen, sammeln wir im Wiki Seite für Seite Wissen. Bausteine sind die Elemente einer Struktur, die zu den Prozessen passen. Jeder Baustein ist so gestaltet, dass er das Ergebnis eines bestimmten Prozessschrittes aufnehmen kann. Systembeschreibung ist der Oberbegriff für die Bausteine Topic, Epic und Case, mit denen wir das Produkt fachlich beschreiben. Mit den Bausteinen Domain, Service, Event und Entity der Systemstruktur erfassen wir Komponenten und Datenstrukturen. »

Das Thema Architekturentwurf beginnt Moritz mit einem Zitat: « Die Architektur eines IT-Systems ergibt sich aus der Summe der getroffenen Entscheidungen. Jede Entscheidung schränkt den Freiheitsgrad der Entwickler ein und sollte daher bewusst getroffen werden. »

Während er redet, schreibt er am Flipchart die Bausteine Decision und Spec auf.

Jetzt holt Moritz etwas weiter aus. Entscheidungen und insbesondere ihre Herleitung müssen unbedingt dokumentiert werden. Geschieht dies nicht und jemand hinterfragt zu einem späteren Zeitpunkt den gewählten Lösungsansatz, erhält man nicht selten die Antwort: « Ich weiß es nicht, das war schon so. »

Teams sind daher gut beraten, jede Entscheidung systematisch mit dem Baustein Decision zu begründen und möglichst viele Aspekte und Alternativen einfließen zu lassen. « Code ist unsere Dokumentation. », ist häufig ein Argument, komplett auf die Dokumentation des Architekturentwurfs zu verzichten. Sicherlich ist Code die wohl zuverlässigste Informationsquelle – daher ist es auch so wichtig, dass eine Lesbarkeit nach höchsten Maßstäben angestrebt wird. Doch es gibt Aspekte, die sich nur schwer aus dem Code ableiten lassen. Moritz nennt als Beispiel wiederkehrende Lösungen, auf die sich ein Team geeinigt hat und denen es bei der Entwicklung folgt. Mit dem Baustein Spec beschreibt das Team solche konzeptionellen Muster.

Ein Blick auf die Uhr verrät Moritz, dass er bei seinen Erklärungen zu einem Ende kommen muss, will er im geplanten zeitlichen Rahmen von maximal zwei Stunden bleiben. Etwas abrupt beendet er daher seinen Vortrag und bittet die Studenten, auf Fragen vorerst zu verzichten. Er versichert ihnen aber, dass sie bei der praktischen Anwendung der Bausteine noch Gelegenheit bekommen, ihre Fragen zu stellen.

Zuletzt veröffentlichte Beiträge: