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


Das Team trifft sich zum Weekly. Richard darf als Erster berichten, was seine Klärung zum Pflichtenheft ergeben hat. Die Regularien für ein SE-Projekt geben kein bestimmtes Format vor. Ein Export aus dem Wiki ist somit zulässig. Das Pflichtenheft ist Teil des Vertrages der TU mit dem Auftraggeber für die Abrechnung der Kosten. Das spielt für Moritz eine untergeordnete Rolle, weil die Firma eMundo als Auftraggeber seine Arbeitszeit und der TU eine Pauschale bezahlt. Viel wichtiger ist ihm, dass die Studenten ihre Arbeitszeit zielgerichtet auf die Realisierung des Reise-Butlers einsetzen.

Richard übernimmt die Aufgabe, die Projektbeschreibung zu erstellen. Dafür gibt es eine Vorlage der TU, an der er sich orientiert. Moritz unterstützt Anne und Georg, damit sie Epics und Cases schnell erarbeiten und im Wiki schreiben können. So wollen sie so schnell wie möglich die vertraglichen Angelegenheiten erledigen. Zeitgleich sollen Julius und Tim sich Gedanken über den Entwurf der Screens der Smartphone-App machen. Unter anderem müssen sie die Entscheidung für den SDK-Level der nativen App treffen. Moritz schwört Julius und Tim darauf ein, sich Gedanken über Nutzererfahrung und Nutzerführung zu machen. Die App soll begeistern.

« Kümmert euch bitte vorerst nicht darum, woher die Daten kommen. Geht davon aus, dass es ein Backend gibt, das Wissen und Fahrpläne aus verschiedenen Quellen im Internet bezieht und für die App bereitstellt. Konzentriert euch darauf, Fahrten, Objekte, Dienste und Termine für den Fahrgast als Nutzer der App einzusetzen. »

Für diese Grundtypen des Wissens aus dem Backend hat Moritz jeweils eine Seite mit dem Baustein Entity vorbereitet. Die Datentypen der Assistenzfunktionen und die Repräsentation des Nutzers der App hat er ebenfalls mit einer Entity-Seite beschrieben. Gemeinsam gehen sie die Seiten der Domänen durch. Moritz beantwortet geduldig alle Fragen. Gleichzeitig verbessert er den Inhalt der Seiten, wenn sich eine neue Erkenntnis aus den Gesprächen oder seinen eigenen Erklärungen ergibt.

Für die Darstellung der Relationen nutzt er das Fachklassenmodell aus der Medienbibliothek, deren Elemente er mit den Entity-Seiten verlinkt. Damit schafft er eine beidseitige Verknüpfung. Ein Leser kann aus der grafischen Ansicht mit einem Klick in die Seite im Wiki wechseln, wo er die Details findet. Mit einem Klick kann er genauso schnell aber wieder zurück in die grafische Ansicht wechseln. Moritz macht auch einen Vorschlag für die Definition der Identität jedes Informationsobjektes. Die vorläufige Beschreibung der Klassen reicht für ein grundlegendes Verständnis. Nach den Informationsobjekten stellt Moritz noch die Komponente vor, mit der sie beginnen sollen. Auch hier hat er bereits Vorarbeit geleistet und mit dem Baustein Service eine Seite im Wiki angelegt.

Die Beschreibung im Wiki ist bestenfalls als rudimentär zu bezeichnen. Hier erwartet er sich aber Feedback aus dem Team.

Während Moritz im Wiki die Seite mit dem Komponentenüberblick aufruft, appelliert er an das Team: « Bitte denkt daran, dass wir die Namen der Komponenten bereits abgestimmt haben. Der Service ReiseManager ist die Schnittstelle der App zum Server. Sorgt bitte dafür, dass der Code dazu passt. »

« Müssen wir jetzt jede Klasse zuerst im Wiki erfassen? », fragt Tim etwas provokant.

« Nein, um Gottes Willen », antwortet Moritz. “Ich bitte euch nur, in diesem Fall ReiseManager als Bezeichner auch für die Komponente zu benutzen, z.B. als Name für das Build-Projekt und die Starter-Klasse eines Spring-Boot-Projektes. Es geht darum, mit dem Namen aus dem Wiki den Einstieg in den Code zu schaffen. Ohne Umweg, direkt den Namen in der IDE eingeben und eine gleichnamige Klasse finden. Von dort will ich den weiteren Code der Komponente erkunden können. Wie ihr das sicherstellt überlasse ich euch. »

« Gilt das auch für das Git-Repo? », fragt Julius.

« Gute Frage. Ja, auf jeden Fall. Es hat sich allerdings bewährt, den Namen nur in Kleinbuchstaben zu schreiben und ein Kürzel für die Domäne als Präfix zu setzen. Die Regel ist einfach: Die durch Camel-Case hervorgehobenen Wortteile werden komplett in Kleinbuchstaben geschrieben und durch einen Bindestrich getrennt. Und für jede Domäne legen wir einfach ein Kürzel fest. In dem konkreten Beispiel würde das Git-Repo “as-reise-manager” heißen. »

« Immer dieser Regeln! », mault Tim.

Moritz kontert: « Ihr seid fünf Entwickler. Wir entwickeln ein Produkt. Ich befürchte, ohne ein paar gemeinsame Regeln wird es nicht gehen. Ich lasse euch großen Spielraum. Aber ich will kein Chaos. Ich persönlich bin Anhänger der Clean-Code-Initiative, nicht in allen Punkten, aber vieles finde ich gut und nützlich. Macht euch Gedanken, wie die Spielregeln beim Programmieren und Dokumentieren sind. »

« Schon wieder dokumentieren! », mault Tim weiter.

« Denk bitte daran, dass unter anderem auch deine Note am Ende des Projektes von der Qualität der Dokumentation abhängt », antwortet Moritz schon leicht verärgert.

Richard meldet sich jetzt zu Wort: « Ich hab mir CARDS+ angeschaut. Das ist gar nicht so schlimm. Irgendwie hat das schon Hand und Fuß. Tim, ganz ernsthaft, hast du bis jetzt ‘was im Wiki dokumentieren müssen? Moritz hat alles gemacht. Und ich finde, es ist ganz ordentlich. »

Und Julius ergänzt: « Ganz ehrlich, ohne Spielregeln beim Programmieren geht es gar nicht. Ich hab keine Lust, den Code zuerst formatieren zu müssen, bevor ich dran arbeiten kann. Und wenn ich den Code selbst beim dritten Mal lesen nicht verstehe, dann schreibe ich lieber alles neu. Manchmal zumindest. »

« Georg und ich kümmern uns um die Dokumentation, Richard macht die Projektbeschreibung. Du darfst mit Julius die App gestalten. Also jammer nicht! », spricht Anne aus, was sie über Tims Verhalten denkt.

Vorsichtig greift Moritz moderierend ein. Im Grunde genommen sind alle im Team motiviert. Jeder will seine Aufgaben erledigen. Sie verstehen die Notwendigkeit einer angemessenen Dokumentation, auch Tim. Als zusätzliche Aufgabe nehmen die Studenten mit, sich Gedanken über die Spielregeln im Team zu machen. Nächste Woche wollen sie einen Workshop dazu machen. Ein guter Abschluss für heute.

Zuletzt veröffentlichte Beiträge: