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


Heute findet das erste Weekly vor der Architekturwand statt. Es ist die erste Gelegenheit, Änderungen an der Wand zu vorzunehmen. Schnell stellen sie aber fest, dass es seit letzter Woche gar keine Änderungen gab, die es zu berücksichtigen gilt. Auch das Weekly ist schnell erledigt, war doch die Erstellung der Architekturwand und die Definition weiterer Produktinkremente ihr vorrangiges Ziel.

Das Team möchte diese Woche endlich wieder Fortschritte in der Implementierung des Reise-Butlers machen. Zuvor bittet sie Moritz aber noch um eine Stunde ihrer Zeit. Er sieht eine gute Gelegenheit, seine versteckte Agenda mit der Produktdokumentation mit den Studenten zu besprechen. Er will mit offenen Karten spielen, was seine Ziele mit ihnen als Team betrifft.

« Ihr habt sicher schon gemerkt, dass professionelle Software-Entwicklung mehr ist als nur Programmieren. », beginnt Moritz, um sich sofort zu korrigieren: « Halt, streicht bitte das Wörtchen “nur”. »

Moritz fährt fort: « Programmieren und Dokumentieren sind beides sehr anspruchsvolle Tätigkeiten, die zur gleichen Zeit stattfinden. Natürlich gibt es eine Analyse von Anforderungen auch in agilen Teams. Aber diese Analyse hat nicht das Ziel, das letzte Detail einer Lösung festzulegen. Die Analyse soll nur den Rahmen abstecken, den Problemraum beschreiben. »

Kein Einspruch vom Team.

« Die Analyse ist ganz klar eine meiner Aufgaben. Das Ergebnis findet ihr im Wiki in der Systembeschreibung. Dafür verwende ich die Bausteine Topic, Epic und Case. »

« Ich dachte, wir sind für die Lösung im Case verantwortlich? », fragt Richard.

« Klar, ganz richtig. Danke für deinen Hinweis. », antwortet Moritz. « Trotzdem lege ich jeden Case an. Aber so wie du sagst: Noch ohne Lösung. »

Moritz blickt in die Runde und wartet auf weitere Reaktionen. Dann redet er weiter: « Beim Architekturentwurf möchte ich mich auf zwei Definitionen berufen. Erstens: Die Architektur einer Software ist die Summe fundamentaler Entscheidungen. Und zweitens: Eine fundamentale Entscheidung lässt sich nur schwer rückgängig machen. »

« Uns was bedeutet das für uns? », fragen Julius und Anne praktisch zeitgleich.

« Für euch bedeutet es, dass ich erwarte, dass ihr alles, was ihr nicht selber programmiert, mit mir abstimmt. Jedes Fremdprodukt erfasst ihr mindestens als Modul. Gibt es mehrere Optionen, dann begründet ihr die Entscheidung mit dem Baustein Decision. »

« Ich dachte, wir bekommen maximalen Spielraum von dir bei der Realisierung? », fragt Julius.

Die Studenten werden unruhig. Sie befürchten, ihre eigenen Ziele nicht zu erreichen. Sie sehen die Gefahr einer schlechten Beurteilung. Besonders Tim warnt vor zu viel Dokumentation als Zeitfresser.

« Es gibt in diesem Projekt Randbedingungen. Da wären die Kosten. Wir haben ein fixes Budget mit geringem Spielraum. Eure Mitarbeit im Projekt ist zeitlich begrenzt, eine Verlängerung ist unmöglich. Ihr denkt in erster Linie an euer Studium. Auch völlig in Ordnung. », erklärt Moritz. « Aus diesen Gründen muss ich darauf bestehen, dass die Ergebnisse eurer Arbeit so gesichert werden, dass andere Mitarbeiter oder Studenten ohne Schwierigkeiten fortsetzen können, was ihr begonnen habt. »

Die Studenten zeigen Verständnis für Moritz’ Beweggründe. Sie betrachten zum ersten Mal ganz bewusst die Risiken in diesem Projekt. Sie erkennen, dass sie nicht ohne Grund heute unbedingt etwas für den Fortschritt tun wollen, weil sie offensichtlich selbst nicht mit dem Stand der Dinge zufrieden sind. Moritz bestätigt allerdings, dass er mit der vorliegenden Dokumentation im Wiki durchaus zufrieden ist. Er spart auch nicht mit Lob für ihre Mitarbeit.

« Und jetzt klebt sowieso alles zum Stand der Realisierung nur mehr an der Wand! », witzelt Tim.

« Nein, nicht ganz. », widerspricht Moritz. « Es fehlt noch die Systemstruktur. Sie ist wichtig. Sie ist die Landkarte der Komponenten. Jede Komponente hat einen eindeutigen Namen, der auch im Code zu finden ist. Jede Komponente hat eine Service-Seite im Wiki. »

Zur Erinnerung wiederholt Moritz, was sie erst letzte Woche gemeinsam beschlossen haben. Den Baustein Service nutzen sie zur Dokumentation von Geschäftsregeln und Algorithmen. Informations- und Nachrichtenobjekte dokumentieren sie im Wiki mit den Bausteinen Entity und Event. Die Spezifikation von Schnittstellen und Datenstrukturen befindet sich ausschließlich im Code.

Moritz möchte die Bedeutung der Systemstruktur hervorheben. Der Einstieg in die Systemstruktur bildet der Komponentenüberblick. Dieses Bild gibt allein schon durch die Anordnung der Komponenten wichtige Hinweise auf Datenflüsse und Abhängigkeiten im System. Häufig gibt ein gut gewählter Name einer Komponente schon klare Hinweise auf seine Aufgabe. Durch die kompakte Sicht auf das System ist es sehr viel leichter, ein übergreifendes Schema für Namen durchzusetzen. Ein schlecht gewählter Name ist sehr schnell identifiziert. Namenskonflikte und die Doppelbelegung eines Begriffes werden so ganz früh vermieden.

Gemeinsamkeiten bei der Implementierung, sogenannte Entwurfsmuster, bekommen ebenfalls einen eindeutigen Namen, z.B. Adapter, Loader, Matcher oder Builder. Das sind technische Konzepte. Darum schlägt Moritz hier ganz bewusst englischsprachige Begriffe vor, zur Abgrenzung von den Fachbegriffen aus der Domäne.

Moritz bietet zum wiederholten Male seine Unterstützung an. Er sieht sich in seiner Rolle als Gärtner in der Verantwortung, die Beschreibungen im Wiki kompakt zu halten. Auch nicht zum ersten Mal erinnert er die Studenten an ein wichtiges Ziel der Methode CARDS+, nämlich die Vermeidung von Dokumentation.

Moritz sieht auf seine Uhr und merkt, dass er bereits überzogen hat. « Lasst uns die Stärken der Methode CARDS+ und die Möglichkeiten in Confluence effektiv nutzen. Bindet mich als Gärtner ein, um die Inhalte zu gestalten. Gebt mir euer Wissen. Nicht mehr und nicht weniger. Und glaubt mir: Lesen und kommentieren ist leichter als schreiben. Darum nehme ich euch gerne die Arbeit ab und lege für euch Seiten im Wiki an. Erzählt mir von einer Komponente, Schnittstelle oder Datenstruktur. Gemäß dem Prinzip der “reverse presentation” schreibe ich alles auf. Und ihr überprüft das Ergebnis. »

Zuletzt veröffentlichte Beiträge: