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


Nach der Pause wollen Moritz und das Team die Gelegenheit nutzen, um die Methode CARDS+ in der Praxis anzuwenden. Ziel ist es, in der nächsten Stunde die ersten Cases gemeinsam zu entwickeln und für alle im Raum sichtbar direkt im Wiki zu erfassen.

Alle sitzen wieder, haben ein neues Getränk und ihren Notizblock vor sich. Moritz reißt das Blatt mit dem Überblick über die Produktdokumentation vom Flipchart ab und befestigt es für alle gut sichtbar daneben direkt an der Wand. Dann stimmt er sich kurz mit den Studenten ab, wie sie die Stunde gemeinsam gestalten wollen.

Moritz tritt neben das Flipchart und stellt die Frage: « Wollen wir uns mit dem Wissen über Gebäude beschäftigen? »

Zustimmendes Gemurmel ertönt.

Moritz fährt fort: « Sehr gut. Nun stellt euch vor, ihr fahrt an einem Gebäude vorbei. Was würde euch interessieren? »

Anne beginnt: « Das hängt davon ab, was für ein Gebäude es ist. Bei einer Burg oder Burgruine würde ich mich fragen, wie sie heißt, wie alt sie ist, ob sie noch bewohnt wird, solche Sachen halt. »

Julius lacht und fragt Anne: « Hast du schon einmal gehört, dass jemand in einer Burgruine wohnt? »

« Mann, du weißt schon, was ich meine. », antwortet Anne etwas pikiert.

« Ja, schon klar.”, antwortet Julius, immer noch amüsiert und redet weiter: “Ich habe mir bei so manchen Villen auch schon die Frage gestellt, wem sie gehört, wer sie bewohnt, ob der Besitzer ein VIP ist, den ich kenne. »

Richard, Georg und Tim äußern sich ähnlich.

Moritz greift nun moderierend ein. Er wiederholt die Definition für die Bausteine Epic und Case und erklärt das Prinzip INVEST. Er schlägt vor dass sie in zwei Gruppen versuchen, passende Situationen zu identifizieren und mit dem Baustein Case zu erfassen. Moritz schreibt den Titel des Epics auf das Flipchart und ruft die entsprechende Seite im Wiki auf.

Bevor sie die Gruppenarbeit beginnen, formuliert Moritz noch eine Randbedingung. Ein Gebäude ist im fachlichen Modell ein Ort mit einem Namen, einer Kurzbeschreibung, einer Position mit Koordinaten, mindestens einem Vorschaubild und einer URL zur Weiterleitung in das Internet, z.B. zu einem Artikel in Wikipedia. Diese Randbedingung hat er im Wiki bereits mit dem Baustein Entity dokumentiert.

In den folgenden 10 Minuten erarbeiten sie den Titel und eine kurze Beschreibung für eine Reihe von Cases. Die Vorschläge der beiden Gruppen sind unterschiedlich. Es kristallisieren sich aber drei Kategorien heraus, mit denen sie die Gebäude grob unterscheiden wollen: Privat genutzte Häuser, öffentliche Gebäude, und auf Anregung von Richard Anlagen des Militärs. Die Studenten sehen, wie Moritz die Vorlage für den Baustein Case nutzt, um schnell Seite für Seite im Wiki anzulegen. Beim Schreiben des Textes im Abschnitt Ausgangslage verknüpft er sofort die wichtigsten Begriffe wie Fahrgast, Verkehrsmittel oder Gebäude mit den Seiten im Glossar.

Etwas verwundert sind sie, als er den ganzen Abschnitt Lösung unverändert lässt. Moritz erklärt: « Jetzt wollen wir den Problemraum für unsere App beschreiben. Wir wollen verstehen, warum wir etwas brauchen, wer etwas braucht und wann er es braucht. Wer ist bei uns klar: Der Fahrgast. Wann ist in diesem Fall auch klar: Während der Fahrt. Bleibt noch das Warum. Und darauf konzentrieren wir uns jetzt in der Beschreibung der Ausgangslage. »

Moritz gibt ihnen noch ein paar Tipps auf den Weg: « Achtet bitte darauf, dass Cases innerhalb eines Epics einheitlich gestaltet sind. Schafft ihr das nicht, dann würde ich annehmen, dass das Epic eventuell zu groß ist. In diesem Fall teilt ihr das ursprüngliche Epic, macht zwei oder mehr Epics daraus. In der Abgrenzung der neuen Epics beschreibt ihr, wo ihr die Grenze zieht, wie ihr geteilt habt. Haltet die Beschreibung kompakt, nutzt Verknüpfungen mit Begriffen im Glossar. »

Die Zeit ist fast um. Moritz beendet seine Arbeit im Wiki. Zum Abschluss stellt er die Frage, ob jeder im Team versteht, was die Bausteine Topic, Epic und Case bedeuten.

Leider reicht die Zeit nicht mehr, um auf alle Rückfragen der Studenten einzugehen. Zur Erleichterung der Studenten macht Moritz klar, dass die Analyse der Anforderungen und die Pflege des Wiki in diesem Bereich vorrangig seine Aufgabe ist. Moritz unterstreicht, dass er sich über kreative Vorschläge immer freut. Und er macht klar, dass der Baustein Case die Grundlage für die Realisierung ist: « Ein Case ist in der Dokumentation der Übergang des fachlichen Problems in die technische Lösung. Eure Mitarbeit an der Lösung ist auf jeden Fall notwendig. »

Mit diesen Worten beendet Moritz diese Veranstaltung. Er kündigt aber gleichzeitig den nächsten Schritt an: Den Architekturentwurf.

Zuletzt veröffentlichte Beiträge: