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


Der Fokus für das Weekly liegt diesmal ganz klar auf der Fixierung der Spielregeln für die Zusammenarbeit im Team und beim Programmieren und Dokumentieren. Moritz hat letzte Woche seinen Standpunkt formuliert und fordert neben einem funktionierenden Produkt eine angemessene Dokumentation im Wiki.

Jeder im Team soll Gelegenheit bekommen, seine Meinung zu sagen. Eine wunderbare Aufgabe für einen Scrum-Master. Leider gibt es im Team keinen. Moritz hat zwar eine Zertifizierung als Product-Owner, aber keine explizite Ausbildung als Scrum-Master. Außerdem haben die Studenten vor, nicht Scrum zu verwenden, sondern auf Kanban zu setzen. Das hat ganz pragmatische Gründe. Sie können sich aufgrund ihrer anderen Verpflichtungen im Studium nur einmal in der Woche gemeinsam als Team treffen. Zusätzliche Arbeitszeiten sind ganz unterschiedlich über die ganze Woche verteilt. Häufig arbeiten sie Zuhause. Tim meinte sogar, auch am Wochenende arbeiten zu wollen.

Moritz hat einen gut gefüllten Medienkoffer mitgebracht. Er hat in den letzten Jahren viele Scrum-Master als Teilnehmer einer Retrospektive oder einem Lessons-Learned-Workshop beobachten können. Er traut sich zu, diese Veranstaltung selbst zu moderieren, mit einer ganz einfachen Methode. Jeder Student und Moritz selbst als Mitglied des Teams bekommen 10 Minuten Zeit, auf Karten Wünsche und Ziele für ihre Zusammenarbeit in allen Bereichen aufzuschreiben. Die Aufgabe ist bewusst offen gehalten. Nach Ablauf der Frist hängt jeder seine Karten persönlich an die Wand und erzählt, was er damit meint. Nachdem alle Karten hängen, versuchen sie gemeinsam Cluster zu bilden mit den Hauptüberschriften Zusammenarbeit und Spielregeln. Für jeden Cluster finden sie eine gemeinsame, kompakte und prägnante Formulierung, die Moritz auf eine neue Karte schreibt und auf ein vorbereitetes Plakat klebt.

Beim Thema Zusammenarbeit wird schnell klar, dass die Studenten sich bereits gut kennen und bis auf Tim schon vor dem Projekt miteinander bekannt waren. Der Wunsch, Konflikte taktvoll und vorrangig zu behandeln ist für Moritz ein Zeichen für Respekt und Teamgeist, genauso wie die Verbannung der Telefone aus dem Arbeitsbereich. Alle finden die Idee des Glossars gut und sind gewillt, aktiv daran mitzuwirken. So wollen sie Mißverständnis durch eine gemeinsame Sprache vermeiden.

Moritz nutzt die Gelegenheit, mit zwei Karten und seiner Erklärung die Wichtigkeit des Wiki als Werkzeug für ihre Zusammenarbeit hervorzuheben. Zwei Aspekte sind ihm dabei wichtig. Das ganze Team nutzt als Leser das Wiki und gibt laufend Feedback und für jede Seite gibt es einen verantwortlichen Autor. Die Moderation von Kommentaren schafft zusätzlich eine Metrik für die Qualität der Seiten im Wiki. Die Regel ist einfach: Nur eine Seite ohne Kommentare ist eine gute Seite.

Eine Karte findet Moritz ganz besonders spannend: Code gehört allen! Das gefällt Moritz. Es ist seiner Meinung nach die Grundlage für sauberen, lesbaren Code. Der Anspruch ist Code, der von jedem im Team verstanden wird.

Bei den Spielregeln handelt es sich zum Großteil um Vorgaben für die Gestaltung des Codes. Die Prämisse »Code gehört allen« erfordert unter anderem Regeln für die Formatierung, für Zeichensatz und andere wichtige Einstellungen der Werkzeuge für die Entwicklung wie den Code-Editor, das Code-Repository oder das Build-Management.

Auch das Ziel sauberer und lesbarer Code wird geschärft. Prinzipien der Clean-Coder wie Einfachheit (KISS), Redundanzfreiheit (DRY), klare Verantwortlichkeit (SRP) oder gleiches Abstraktionsniveau (SLA) sollen angewendet werden. Die Karte mit der Forderung, Kommentare im Code zu vermeiden, wird zu Beginn kontrovers diskutiert und steht kurz davor, abgelehnt zu werden. Aber auch hier helfen die Argumente der Clean-Coder.

Aus rechtlichen Gründen oder weil es im Unternehmen vorgeschrieben ist, sind in der Regel Kommentare mit Hinweisen zum Hersteller, das Copyright oder die Lizenzbedingung in den Code erforderlich.

Standardkommentare werden in den Code-Editoren (z.B. Eclipse, IntelliJ, etc) zentral gepflegt und vor dem Entwickler verborgen. Eine manuelle Pflege ist nicht vorgesehen.

Guter, lesbarer Code zeichnet sich durch aussagekräftige Bezeichnungen für Klassen, Methoden oder Variablen aus. Kommentare, die nur wiederholen, was schon im Code steht, blähen den Code nur unnötig auf. Kommentare sind lästiges Geschwätz, wenn sie das Offensichtliche wiedergeben. So einen Kommentar zu lesen dauert häufig länger, als den Code zu lesen.

Eine Vorschrift, jede Klasse oder öffentliche Methode zwingend mit einem Kommentar zu versehen, führt in den meisten Fällen zu redundanten Kommentaren.

Redundante Kommentare haben keinen Wert. Sie sollten entfernt werden.

Ein Kommentar mit nützlichen Informationen über die Hintergründe oder nicht offensichtliche Probleme einer Implementierung ist ein guter Kommentar. Mit einem Kommentar kann auch die Bedeutung eines Teils des Codes hervorgehoben werden.

Wichtig ist, dass diese Kommentare gepflegt werden. Aber genau das ist die Schwierigkeit. Es erfordert Disziplin und Sorgfalt bei den Entwicklern.

Moritz erinnert mit seinen Karten an ihre Entscheidung, keine Begriffe der deutschsprachigen Domäne im Code in die englische oder irgendeine andere Sprache zu übersetzen. Er ergänzt mit einer weiteren Karte, dass Begriffe auch nicht verkürzt werden.

Das Glossar bildet dabei das Vokabular im Projekt. Es ist sozusagen ein Lexikon für Worte, die nirgends übersetzt oder verkürzt werden. Nicht im Code, nicht in den Testfällen und nicht in der Dokumentation.

Ergänzend zu den Begriffen der Domäne im Glossar gibt es auch einheitliche Bezeichnungen für Konzepte oder Entwurfsmuster. Moritz erwähnt die Konzepte “Loader”, “Matcher”, “Manager” und “Store” aus dem Komponentenüberblick. Bei der Bildung des Namens einer Komponente wird konsequent der Name des Konzeptes als Suffix verwendet, beispielsweise “FahrtMatcher”. Mit dieser ganz einfachen Regel gibt allein der Titel einer Service-Seite einen eindeutigen Hinweis auf das zugrundeliegende Konzept für die Implementierung. Wortspiele oder Verkürzungen sind hier nicht erwünscht. Gleichzeitig wird dadurch die Idee der Microservices aktiv gelebt.

Moritz erklärt: « Das Konzept ist als Blaupause zu verstehen. Es lässt euch ausreichend Spielraum für kreative Ideen. Gibt es trotzdem Abweichungen zum Konzept, schreibt ihr einfach entsprechende Hinweise mit Begründung in die Service-Seite im Wiki. Es ist schon ein Ziel der Konzepte, eine gewisse Nachvollziehbarkeit in die Implementierung unserer Komponenten zu bringen. »

Die nicht-funktionalen Aspekte sind derzeit noch offen, müssen aber geklärt werden, bevor die ersten technischen Entscheidungen getroffen werden.

Moritz nutzt die Gelegenheit, das Team auf ein wichtiges Ziel der Methode CARDS+ aufmerksam zu machen. Code und Testfälle sind ein wesentlicher Bestandteil der Produktdokumentation. Im Code steckt die Antwort, wie das Produkt im Detail funktioniert. Testfälle beschreiben, was das Produkt nachweislich leistet – und überprüfen es auch. Das Wiki beantwortet die Frage, warum das Produkt so ist, wie es gerade ist und wer es wann benutzt und schließt damit die Lücke, die Code und Testfälle lassen.

Nach fast einer Stunde sind alle Karten besprochen, gruppiert, bewertet und hängen aufgeteilt auf den beiden Plakaten an der Wand. Ein guter Zeitpunkt für eine Pause.

Zuletzt veröffentlichte Beiträge: