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


Letzte Woche im Weekly haben Moritz und das Team das Produktinkrement Null auf den Weg gebracht. Das Ziel ist klar: Sie schaffen eine Arbeitsumgebung für die Entwicklung. Sie setzen auf Automatisierung, die ihnen jetzt etwas Zeit kostet, später aber hilft, schneller Fortschritte zu machen.

Während der Großteil des Teams die aktuellen Aufgaben bearbeitet, kümmern sich Richard und Moritz um die Definition weiterer Produktinkremente. Die Grundlage ist die Produktdokumentation im Wiki. Den groben Rahmen für den Reise-Butler im Rahmen des SE-Projektes hat Moritz bereits beim Projektstart mit den Topics abgesteckt. Daran hat sich nichts geändert. Eine Reihe von Epics hat Moritz ebenfalls schon vor einiger Zeit erfasst, als er Verena das Projekt präsentierte, um von ihr die Zusage zur Finanzierung des SE-Projektes zu bekommen. Weitere Epics hat Moritz durch das Feedback der Studenten beim Kickoff des Projektes aufgenommen.

Jetzt möchte Moritz zusammen mit Richard mit dem Baustein Case den durch Epics  begrenzten Problemraum des Produktes Reise-Butler erfassen. Dabei geht es vor allem darum, jeden Case mit einem aussagekräftigen Titel im Wiki anzulegen. Wo der Titel offensichtlich nicht reicht, verwenden sie den Abschnitt Ausgangslage zur Klärung. Der Abschnitt Lösung bleibt in allen Fällen offen.

Schnell stellen sie fest, dass sie kein gemeinsames Verständnis von einem Case haben. « Was ist eigentlich ein Case? », fragt Richard bereits etwas frustriert.

Moritz versucht sich an einer Definition: « Ein Case beschreibt eine in sich geschlossene Funktion, mit einer klaren Ausgangslage und einem Ziel. Nimm als Beispiel die Anmeldung. Der Case beginnt im Login-Screen. Die Nutzerdaten werden dann in einem Service überprüft. Der Case endet im Start-Screen der App. »

« Und was passiert im Fall ungültiger Daten, z.B. falsches Passwort? », fragt Richard.

« Dann haben wir vermutlich weitere Cases. Alle beginnen im Login-Screen, enden aber unterschiedlich. Ist der Nutzer unbekannt, endet der Case im Screen für die Registrierung. Ist das Passwort falsch, endet der Case erneut im Login-Screen. »

Richard formuliert weitere Bedenken: « Das ist aber umständlich, das kann ganz schnell ganz viele Kombinationen geben. »

« Ja, dass kann schon sein. Unser Ziel ist es aber, alle fachlichen Probleme zu erfassen, die wir lösen wollen. Denkst du zu technisch, wirkt die Dokumentation wie Code in Prosa, mit Formulierungen wie «wenn die Daten gültig sind, mach das, sonst etwas anderes. Das ist nicht wirklich nützlich. Und schwer zu lesen. Es darf nicht sein, dass ich einen Case mehrfach lesen muss, um ihn zu verstehen. Mir geht es um den Überblick über den Problemraum. Wenn ich die genaue Lösung wissen will, dann frage ich euch. »

Moritz erzählt über eine Erfahrung aus einem Projekt, das die Aufgabe hatte, eine Abstraktion für unterschiedliche Bauteile wie Kartenleser, Belegdrucker, Tastatur oder Bildschirm eines Fahrkartenautomaten zu realisieren. Der verantwortliche Product-Owner hatte anfangs Schwierigkeiten mit dem Baustein Case. « Gemeinsam haben wir uns in einen Nutzer des Automaten versetzt. So haben wir Cases mit Titeln wie “Case Reiseparameter eingeben”, “Case Scheckkarte zum Bezahlen verwenden” oder “Case Kreditkarte zum Bezahlen verwenden” identifiziert. »

Richard stellt eine Frage: « Und was ist jetzt mit den Bauteilen, die du erwähnt hast? Gibt es auch Cases für Kartenleser, Belegdrucker, Tastatur oder Bildschirm? »

« Nein, gibt es nicht! », antwortet Moritz. « Die Bauteile sind Teil der Lösung. Mit dem Baustein Layout werden die Anzeigen am Bildschirm beschrieben. Der Kartenleser ist ein Basisdienst, spielt eine Rolle bei den Bezahlvorgängen mit Chipkarten. »

In einem weiteren Beispiel geht es um die Bereitstellung von Bahnhofsplänen. Bilddaten können von externen Web-Clients oder mobilen Apps über ein REST-API geladen werden. Die fachliche Sicht auf diese Lösung ist überschaubar: Ein Epic Bahnhofsplan bildet den Rahmen. “Case Bahnhofsplan suchen” beschreibt die Schnittstellenoperation, mit dem Abnehmer herausfinden, welche Pläne in welchem Format verfügbar sind. Anfangs wird nur PNG angeboten, was durch den “Case Bahnhofsplan als PNG-Kachel bereitstellen” dokumentiert wird. Mit jedem weiteren Format kommt ein neuer Case dazu. Die technische Lösung ist aber in allen Fällen praktisch identisch, da die Pläne zentral in einem einzigen Format gespeichert sind und nur für die Auslieferung im REST-API konvertiert werden.

Richard hat jetzt genug Beispiele gehört. Sie beschließen, mit den Cases für das Reisewissen zu beginnen. Gemeinsam formulieren sie jeden Titel, Seite für Seite. Viele Cases haben ein wiederkehrendes Muster. So üben sie eine Zeitlang, bis Richard offensichtlich den Bogen heraus hat. Bald haben sie eine ganze Menge Seiten im Wiki erfasst, mindestens jedoch einen Case je Epic.

Richard und Moritz nutzen die verbleibende Zeit für das Anlegen von Cases. Im Bereich Reisewissen wird Richard fast schon zu kreativ. Moritz muss als Product-Owner bremsend Einfluss nehmen. Beim Fahrtwissen hingegen fehlt Richard der Einblick in betriebliche Prozesse in den Verkehrsunternehmen. Hier kann Moritz seine Erfahrung aus anderen Projekten einbringen. « Es wird! », denkt sich Moritz zufrieden.

Moritz war von Anfang an klar, dass es mit den Studenten in der begrenzten Zeit praktisch unmöglich ist, sofort ein markttaugliches Produkt zu erstellen. Das Team kann aber eine Grundlage dafür schaffen. Leisten sie gute Arbeit, besteht die Möglichkeit, das Projekt weiterzuführen. Das hat Verena bereits angedeutet. Eine Verlängerung des Projektes mit diesem Team ist allerdings ausgeschlossen. Es ist unklar, ob es ein weiteres SE-Projekt gibt oder der Reise-Butler als internes Ausbildungsprojekt für neue Mitarbeiter positioniert wird. In allen Fällen ist gute Code-Qualität und eine angemessene, korrekte Produktdokumentation alternativlos.

Zuletzt veröffentlichte Beiträge: