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


Das Thema Projektbeschreibung ist nicht mehr auf der Agenda des Teams. Der abschließenden Export aus dem Wiki von Projektbeschreibung, Pflichtenheft und Glossar und die Excel-Datei mit der Schätzung hat das Team offiziell und termingerecht bei ihrem Betreuer Sebastian abgegeben. Das erste Feedback von ihm war positiv. Durch die Vorarbeiten des Teams bezüglich Automatisierung von Build und Test steht dem Team eine gut funktionierende Arbeitsumgebung zur Verfügung. So lautet zumindest die Aussage des Teams im heutigen Weekly.

Moritz macht den Vorschlag, das Team in zwei Arbeitsgruppen zu teilen. Er begründet den Vorschlag als Chance zur Steigerung der Geschwindigkeit (englisch: velocity) des Teams. Durch die gewählte Architektur lassen sich nach Moritz’ Einschätzung alle Aufgaben ganz grob in die Bereiche Datensammlung und Präsentation der Daten aufteilen. Nach einer kurzen, aber intensiven Diskussion zur Abgrenzung der Aufgabenbereiche führt eine Abstimmung zu folgender Aufteilung. Anne und Richard übernehmen als Gruppe eins alle Komponenten im Backend. Ihre Hauptaufgabe ist die Anbindung der Datenquellen für Fahrplan und Reisewissen im Internet. Folglich kümmert sich Gruppe zwei, bestehend aus Julius, Georg und Tim, um die Komponenten der Assistenz und um die Android-App. Aus der Diskussion über die Aufgabenbereiche der beiden Gruppen hat sich eine sehr wichtige Frage zur Klärung ergeben.

« Wie können wir sicherstellen, dass beiden Gruppen unabhängig voneinander entwickeln können? », bringt Julius das Problem auf den Punkt.

« Wir setzen auf einen event-basierten Datenfluss mit Kafka. Dadurch ist die Kohäsion der Komponenten von Haus aus sehr gering. Dann reicht es, wenn wir Events als Schnittstelle betrachten. Wenn ich Avro richtig verstanden habe, dann können wir damit einen Event formal beschreiben. », schlägt Richard vor.

Anne hat Bedenken: « Wir wissen doch jetzt noch gar nicht, wie so ein Event am Ende ausschauen muss. Wir legen uns da viel zu früh fest! »

« Das ist kein Problem. Ich weiß aus eigener Erfahrung in einem anderen Projekt, dass Avro eine Schema-Evolution unterstützt. Kompatible Änderungen sind dann gar kein Problem mehr. », erklärt Julius.

Moritz bestätigt diese Annahme auch aus seiner Erfahrung.

Es ist offensichtlich, dass es den Studenten an diesem Punkt an Erfahrung mangelt. Moritz bietet seine Hilfe an. Er macht den Studenten klar, dass er seine Unterstützung nicht als ihr Product-Owner, sondern quasi als externer Software-Experte gibt.

Der Lösungsvorschlag von Moritz ergibt sich aus der weitestgehend event-basierten Microservice-Architektur. Jede Komponente hat klare Schnittstellen, über die sie asynchron Daten bezieht und andere Schnittstellen, über die sie Daten asynchron wieder abgibt. Diese praktisch in Echtzeit stattfindende Datenverarbeitung wird auch «streaming» genannt. Unterstützt wird dieses Konzept mittlerweile von einer ganzen Reihe Open-Source-Produkten aus der Apache-Welt: Spark, Storm, Flink, Samza. Alle diese Produkte bieten eine ausgereifte Integration von Kafka als Message-Broker. Moritz empfiehlt mit Kafka Streams ein API als leichtgewichtige Alternative, die er in einem Kundenprojekt kennengelernt hat. Das Projekt war erfolgreich, der Einsatz von Kafka und Kafka Streams ein Erfolgsfaktor.

Die beiden Arbeitsgruppen bekommen den Auftrag, die gerade diskutierten Entscheidungen für asynchrone Datenübertragung und kontinuierliche Datenverarbeitung im Wiki mit dem Baustein Decision zu dokumentieren. Nach einer knappen Stunde ist die Arbeit erledigt.

Moritz und das Team sind zufrieden, sind doch wichtige Entscheidungen gut vorbereitet oder bereits gefallen und nachvollziehbar für alle begründet.

Ein weiterer Auftrag an beide Gruppen ist die Durchführung eines Design-Workshops, in dem sie gemeinsam Events definieren sollen. Aufgrund der fortgeschrittenen Zeit und ihrer selbst auferlegten Beschränkung auf sechs Stunden für das Teamwork beschließen sie, das Weekly nächste Woche ausfallen zu lassen und die gewonnene Zeit für den Workshop zu verwenden.

Praktisch mit dem Verabschieden gibt Moritz dem Team noch einen Vorschlag auf den Weg: « Denkt doch darüber nach, ob ihr den beiden Arbeitsgruppen einen Namen geben wollt. Ich persönlich finde es auf Dauer lästig, immer von Gruppe eins oder zwei zu sprechen. »

Zuletzt veröffentlichte Beiträge: