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


In der letzten Wochen gab es sehr kontrovers geführte Diskussionen über Dokumentation im Team. Es ging um die Frage der Angemessenheit und Vollständigkeit. Sie sprachen über Arbeitsdokumente, über Notwendigkeit und Lebensdauer solcher Dokumente. Moritz hat aber seinen Standpunkt klar gemacht, dass er Arbeitsdokumente nicht als Teil der Produktdokumentation akzeptieren wird. Die Studenten konnten aus mehreren möglichen Lösungen für dieses Dilemma wählen und sich bis heute für ein Vorgehen entscheiden.

Gleich nach dem Weekly stellt Moritz deshalb die Frage: « Konntet ihr euch für eine Lösung entscheiden? »

Julius tritt wie fast immer als Sprecher des Teams auf. « Ja, konnten wir. Wir wollen beide Lösungen. »

Moritz ist etwas erstaunt und bittet um eine Erklärung, was sie damit meinen.

Julius erklärt: « Wir wollen vor allem Informations- und Nachrichtenobjekte direkt im Wiki pflegen. Du hast in der Vergangenheit schon sehr gut vorgearbeitet. Darauf wollen wir aufbauen. »

Moritz nickt: « Ok, fein. »

Julius fährt fort: « Bei der fachlichen Beschreibung des Systems, also TopicEpic und Case, wünschen wir uns, dass du die notwendigen Anpassungen machst. Die Zusammenhänge für die Lösung im Case wird dir natürlich einer von uns erklären. »

« Welche Zusammenhänge meinst du? », fragt Moritz nach.

Jetzt antwortet Richard: « Du hast uns erklärt, dass eine Lösung im Case nur so eine Art Navigation in der Architektur ist. Wir sind sicher, dass wir dir sehr schnell die Essenzschritte erklären können, die du dann für uns aufschreibst. Quasi eine “reverse presentation”, wie du uns letztes Mal erklärt hast. »

Nach einer ganz kurzen Nachdenkpause akzeptiert Moritz auch diesen Vorschlag: « Ok, verstehe. Ich schreibe also die Lösung, wie ich sie verstanden habe, mit meinen Worten auf. Natürlich mit Verlinkung. Und einer von euch wird es im Anschluss prüfen. »

Jetzt ist wieder Julius dran: « Für die aktuelle Implementierung wollen wir den Vorschlag von dir umsetzen, den aktuellen Aufbau des Systems auf die Wand zu kleben. Mit Klebezetteln für die Komponenten und Klebestreifen für die Verbindungen. Wir werden jede Woche am Dienstag nach dem Weekly das Bild aktualisieren. »

« Zusätzlich werden wir jede Woche ein Foto machen und im Teambereich ablegen. », ergänzt Richard.

« Den Vorschlag mit Asciidoc findet ihr offensichtlich nicht gut? », fragt Moritz.

« Die Idee ist klasse. », antwortet Julius. « Wir glauben aber, dass uns der Code im Git und das Wiki als Ergänzung dazu reicht. »

Abwechselnd erzählen die Studenten von ihren Annahmen. Insgesamt sehen sie keinen Vorteil durch die Verwendung von Asciidoc.

Moritz fasst das Ergebnis aus seiner Sicht zusammen. Die Bausteine Topic, Epic und Case sind in seiner Verantwortung. Für die Lösung im Case braucht er aber ihre Mitarbeit. Informations- und Nachrichtenobjekte dokumentieren sie mit den Bausteinen Entity und Event, soweit es für das Verständnis der Implementierung notwendig ist. Sie wollen den Code lesbar gestalten, eventuell Javadoc nutzen. Den Baustein Service nutzen sie, um festzuhalten, was nicht im Code steht oder am Code schwer ablesbar ist, z. B. Besonderheiten bei der Verwendung eines API, Optimierungen, Geschäftsregeln oder Algorithmen. Code und die Spezifikation von Schnittstellen und Datenstrukturen befindet sich ausschließlich in Git.

In den nächsten Minuten ringen sie mit der Formulierung in der DOD. Moritz will keine Weichmacher. Das Team besteht aber darauf, dass der Umfang der Dokumentation weiterhin durch Akzeptanzkriterien in Trello festgelegt wird. Moritz akzeptiert, obwohl es mehr Arbeit für ihn bedeutet.

Nach einer kurzen Pause beginnt die erste Arbeitsgruppe mit der Gestaltung der Architekturwand. Sie orientieren sich am Zielbild im Wiki, am aktuellen Architekturbild von Richard und ihrer Kenntnis der Implementierung. Die Wand bietet auf jeden Fall ausreichend Platz. Im Medienkoffer gibt es Klebezettel in verschiedenen Größen und Farben und Klebestreifen in zwei Stärken. Sie legen fixe Farben für Loader, Matcher und Updater fest. Alle Klebezettel beschriften sie mit Name, Version und Technologie der Komponente. Breite Klebestreifen verbinden Komponenten.Auf die Klebestreifen schreiben sie den Topic-Namen und den Namen des Events. Praktisch wie in Richards Bild.

Während die erste Gruppe an der Wand arbeitet, überprüft Moritz zusammen mit der anderen Gruppe die Eigenschaften der bereits im Wiki mit dem Baustein Entity erfassten Informationsobjekte. Moritz’ Ziel ist ein gemeinsames Verständnis. Er macht deutlich, dass er kein Implementierungsmodell benötigt: « Eine Komponente hat seine eigene interne Implementierung für jede Entity. Der Name ist gleich. Schlüsselattribute werden gemäß der Identität definiert. Alle weiteren Attribute werden von den Eigenschaften abgeleitet, wie sie im Wiki bezeichnet und definiert sind. Erweiterungen oder Abweichungen sind möglich. Im Extremfall ist es nur eine Referenz. »

Beide Gruppen gestalten zügig ihr Bild der aktuellen Implementierung an der Wand. Auch die Informationsobjekte sind schnell abgestimmt und im Wiki aktualisiert.

Die Tabelle der Eigenschaften einer Reise ist noch nicht vollständig und muss  noch um die Beschreibung für Produkt, Linie, Abfahrt, Ankunft, Fahrtereignis und Station erweitert werden.

Zum Abschluss macht Richard das erste Foto von der Wand und speichert es im Teambereich ab. Ein guter Abschluss für den Tag. Richard nimmt noch die Aufgabe mit, alle Arbeitsdokumente aus dem Teambereich im Wiki zu entfernen, die jetzt durch die Architekturwand ersetzt wurden.

Zuletzt veröffentlichte Beiträge: