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


Nach einer ganz kurzen Pause von fünf Minuten geht es mit dem praktischen Teil weiter.

« Wir befinden uns gerade in der Projektinitialisierung. Jetzt legen wir den Umfang des Produktes, den “scope” fest. Wir nutzen den Baustein Topic, um genau dieses Wissen zu sichern. », sagt Moritz und zeigt auf das Wort Topic am Flipchart.

Der Baustein Topic dient zur Klärung der Projektumfangs («Scope») zwischen Product-Owner und Auftraggeber. Er bildet die Basis für die Systemdokumentation und führt alle thematischen, prozessualen, funktionalen Aspekte des IT-Systems im Überblick («Big Picture») ein. Innovationen oder einfach Erfolg führen dazu, das Produkt zu erweitern, was durch neue Topics dokumentiert wird.

Ein Topic zeigt die Grenzen des Produktes und wird in der Sprache der Stakeholder geschrieben.

Weiterlesen auf cardsplus.info

Im Wiki gehen sie gemeinsam die bereits von Moritz vorbereiteten Topics Reisewissen, Assistenz, Fahrplan und Fahrtwissen durch. Nachdem alle Fragen vorläufig geklärt wurden geht es weiter: “Eine Anforderung ist der Wunsch des Auftraggebers, das IT-System zu verändern. Ein Epic ist keine Anforderung. Ein Epic ist ein Ergebnis der Anforderungsanalyse und bildet den Rahmen für eine beliebig große Menge von Cases. Alle Epics und Cases zusammen beschreiben das Produktinkrement.”

Der Baustein Epic enthält das Ergebnis der Anforderungsanalyse. Er enthält einfach gesagt die Beschreibung eines geschlossenen Problemraums des Produktes. Es kann wachsen, es bündelt gleichartige Lösungen zu einem Ganzen. Ein neues Epic ist notwendig, wenn eine Anforderung an das Produkt, also ein neuer Problemraum, eine Lösung erfordert, die anders als die bisher realisierten Lösungen ist.

Ein Epic benennt Dinge, die ein IT-System für den Nutzer tun soll. Es wird wird in der Sprache der Nutzer geschrieben.

Weiterlesen auf cardsplus.info

Der Baustein Case wird verwendet, um einen Anwendungsfall, einen Sonderfall mit besonderer Lösung oder eine Situation ohne Lösung zu beschreiben. Die im Case beschriebene Ausgangssituation ändert sich nicht, sondern wird geschärft oder zu einem anderen oder neuen Case abgegrenzt. Die Lösung im Case kann sich jedoch ändern. Die Gründe sind vielfältig: Steigerung der Leistungsfähigkeit oder Robustheit, Änderungen in der Infrastruktur oder neue Erkenntnisse mit Auswirkung auf die Implementierung. Auch die Aufarbeitung technischer Schulden kann zu einer neuen Lösung führen.

Ein Case ist so klein wie möglich geschnitten und in sich abgeschlossen sowie testbar (Prinzip INVEST). Er bildet den Übergang von der Systembeschreibung in die Systemstruktur. Der Abschnitt Ausgangssituation wird in der Sprache der Nutzer geschrieben. Der Abschnitt Lösung im Case wird für Entwickler geschrieben.

Weiterlesen auf cardsplus.info

Im Wiki gehen sie erneut gemeinsam die vorbereiteten Epics aus dem Topic Reisewissen durch. Zur kurzzeitigen Erheiterung trägt das Stichwort Heuriger im Glossareintrag für Gastronomie bei. Keiner der Studenten kannte dieses Wort.

Moritz schaut auf die Uhr. Noch 15 Minuten bis zur Pause. Er möchte die verbleibende Zeit nutzen, um den Studenten die Möglichkeit zu bieten, in einem Blitzlicht ihre ersten Eindrücke zu teilen. Er erklärt: « Blitzlicht ist eine Methode, um schnell die Stimmung, eine Meinung oder anderes Feedback zu bekommen. Ich würde euch jetzt bitten, dass sich jeder kurz zu CARDS+ äußert. Bitte maximal zwei Minuten. »

Julius beginnt: « Ich habe verstanden, dass wir inkrementell dokumentieren sollen. Das höre ich zum ersten Mal. In einer Vorlesung haben wir Scrum besprochen. Dort hieß es, dass mit der Methode inkrementell und iterativ entwickelt wird. Ich kann mir gut vorstellen, wie ich so programmiere und freue mich auch schon, es in diesem Projekt auszuprobieren. Aber ich kann mir gerade nicht vorstellen, wie das beim Dokumentieren gehen soll. »

Die anderen Studenten scheinen ähnliche Gedanken zu haben und nicken zustimmend. Eine Diskussion über Agilität entbrennt.

Mit einem Blick auf die Zeit unterbricht Moritz die Diskussion und bittet Richard mit seinem Blitzlicht fortzufahren: « So wie ich es verstanden habe, ist das Lastenheft nicht fertig. Wir starten das Projekt also mit einer unfertigen Dokumentation, die wir außerdem laufend ändern sollen. Führt das nicht ins Chaos? »

Alle blicken Moritz fragend an, der sie aber erinnert, dass es im Blitzlicht nur darum geht, Gedanken auszutauschen, ohne Diskussion. Er verspricht aber, dass er diesen Punkt noch einmal aufgreifen wird, wenn sie über den agilen Entwicklungsprozess und das Product-Backlog reden.

Georg und Tim äußern sich sehr ähnlich.

Tim hat zusätzlich eine sehr spannende Erkenntnis formuliert: « So ein Produktinkrement besteht aus Code, Tests, Skripte, Konfigurationen und Dokumentation. Und du sagst, wir sind als Team für alle Teile verantwortlich. »

Moritz bestätigt diese Annahme.

Zum Abschluss spricht Anne: « Du hast bei deinen Erklärungen sehr häufig von Feedback gesprochen. Einmal hast du gesagt, dass es wichtig ist, dass wir aufmerksame Leser sein müssen, damit die Qualität der Dokumentation stimmt. Aufmerksam heißt doch, dass wir dauernd auf Änderungen in der Dokumentation reagieren müssen. Das erscheint mir sehr anstrengend zu sein. »

Jetzt lässt sich Moritz doch zu einer Antwort hinreißen: « Für Dokumentation gilt das gleiche wie für Code. Inkrementell Dokumentieren ist nicht anders als inkrementell Programmieren. »

Die Zeit ist um, das Blitzlicht ist zu Ende. « Vielen Dank für euer Feedback! », sagt Moritz abschließend und fährt im gleichen Atemzug fort: « Ich denke, wir haben uns die Pause redlich verdient. Wir treffen uns in 15 Minuten wieder. »

Zuletzt veröffentlichte Beiträge: