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


Der Tag beginnt für Moritz mit einer guten Nachricht. Ein Schreiben der TU hat bestätigt, dass die Bewerbung für das Projekt Reise-Butler angenommen wurde. Fünf Studenten werden im kommenden Semester als Team eine erste Realisierung der Smartphone-App versuchen. Moritz ist klar, dass der Versuch auch scheitern kann. Er kann die Leistungsfähigkeit und -bereitschaft schwer einschätzen. Aus diesem Grund möchte er einige zentrale Randbedingungen festlegen.

Die erste Einschränkung betrifft die Plattform für die Smartphone-App. Moritz möchte, dass sich die Studenten nur auf Android oder iOS konzentrieren. Eine Rückfrage bei der TU zeigt, dass bis auf einen alle Studenten bereits Erfahrung mit Android haben. Zwei Studenten arbeiten sogar neben dem Studium in einer Firma, die sie für die Programmierung von Smartphone-Apps beschäftigt. Mit Apples iOS haben nur zwei Studenten Erfahrung. Mit der Festlegung auf Android ist auch die Entscheidung für die Programmiersprache gefallen. Es wird Java.

Die nächste Einschränkung muss Moritz intensiver mit Verena diskutieren. Moritz ist der Meinung, dass das Team sich auf die Smartphone-App konzentrieren soll. Das vorrangige Ziel ist ein Prototyp, der die Navigation in der App und die Präsentation der Informationen zeigt. Alle Daten werden direkt in der App simuliert. Verena hält dagegen, dass dadurch das Projekt weniger spannend für die Studenten ist. Und einen Prototyp als Ziel findet sie nicht gut. Besser wäre ein MVP, das tatsächlich funktioniert.

Am Ende finden sie einen Kompromiss. Der Reise-Butler ist eine Smartphone-App mit Server-Komponenten in der Cloud. Wahrscheinlich wird es AWS. Die Daten, also Fahrpläne der Verkehrsmittel und Informationen über Sehenswürdigkeiten im Verlauf der Reise werden vorgehalten, aber nicht aktualisiert. Echtzeitdaten der Verkehrsmittel werden simuliert.

Moritz dokumentiert diese Entscheidungen mit dem Baustein Decision der Methode CARDS+.

Diese Übersichtsseite zeigt alle dokumentierten fundamentalen Entscheidungen mit Auswirkung auf die Entwicklung des Produktes oder den Betrieb des IT-Systems.

Im Abschnitt “Entscheidungen durchsuchen” kann ein Leser in den Entscheidungen suchen. Die Suche ist dabei auf Unterseiten dieser Übersichtsseite eingeschränkt.

Im Abschnitt “Entscheidungen nach Kategorie” werden Entscheidungen in vordefinierten Kategorien gruppiert. Die Kategorien sind Stichworte.

Im Abschnitt “Neue Entscheidung” können neue Entscheidungen mit der vorbereiteten Vorlage angelegt werden. Die Liste der Entscheidungen ist nach dem Datum der letzten Änderung sortiert. Entwickler können so schnell erkennen, welche Entscheidungen in letzter Zeit dokumentiert wurden.

Diese Übersichtsseite zeigt alle für dieses Produkt dokumentierten individuellen Konzepte.

Im Abschnitt “Konzepte durchsuchen” kann ein Leser in den Konzepten suchen. Die Suche ist dabei auf Unterseiten dieser Übersichtsseite eingeschränkt.

Im Abschnitt “Neues Konzept” können neue Konzepte mit der vorbereiteten Vorlage angelegt werden. Die Liste der Konzepte ist nach dem Datum der letzten Änderung sortiert. Entwickler können so schnell erkennen, welche Konzepte in letzter Zeit dokumentiert wurden.

Diese Übersichtsseite zeigt alle sogenannten «Fremdprodukte”, die für die Entwicklung dieses Produktes eingesetzt werden. Dazu zählen Bibliotheken, die eingebunden werden, Werkzeuge für die Entwicklung oder Komponenten der technischen Infrastruktur des IT-Systems.

Im Abschnitt “Module durchsuchen” kann ein Leser in den Konzepten suchen. Die Suche ist dabei auf Unterseiten dieser Übersichtsseite eingeschränkt.

Im Abschnitt “Neues Modul” können neue Module mit der vorbereiteten Vorlage angelegt werden. Die Liste der Module ist nach dem Datum der letzten Änderung sortiert. Entwickler können so schnell erkennen, welche Module in letzter Zeit dokumentiert wurden.

Für Moritz war wichtig, dass er mit dem Baustein Decision die Diskussion und das vorläufige Ergebnis der Diskussion mit Verena festgehalten hat. Moritz ist aber klar, dass er die Diskussion auch mit dem Team noch einmal führen muss. Das betrifft vor allem Entscheidungen, die direkte Auswirkungen auf die Entwickler hat.

Es gibt Plattformen, die eine Entwicklung für sämtliche mobile Betriebssysteme erlaubt. Das klingt nach einem schönen Traum. Aber auch eine native, auf ein bestimmtes mobiles Betriebssystem optimierte App hat Vorteile.

Die Entscheidung durch den Product-Owner ist pragmatisch und wirtschaftlich motiviert: Fokussierung auf ein erreichbares Ziel. Außerdem war ja die Ausschreibung für das Projekt schon mit Prämissen versehen, die praktisch diese Entscheidung vorweg genommen hat.

Der Reise-Butler wird vorerst nur für Smartphones mit dem Betriebssystem Android entwickelt. Android gibt es aber in einer Vielzahl von Versionen. Welche ist die richtige für dieses Projekt?

Der Product-Owner entscheidet sich vorläufig für das SDK-Level 23 und begründet es aus seiner Sicht. Das Team wird später die Entscheidung bestätigen oder mit ausreichend guten Gründen und in Abstimmung mit dem Product-Owner ändern.

Jeder Leser kann diese Entscheidung kommentieren. So bekommt die Entscheidung mehr Gewicht.

Die Wahl der Programmiersprache ist eine wichtige Entscheidung. Sie muss früh getroffen werden, weil sie später die Wahl der Technologien und Werkzeuge beeinflusst.

Bei der Entscheidung hat der Product-Owner die Qualifikation seines Teams berücksichtigt. Die Einstiegshürde für die Entwickler soll so gering wie möglich sein. Er verlässt sich auf die Einschätzung seines Teams.

Nach seiner Einschätzung bestens vorbereitet kann es Moritz kaum mehr erwarten, die Studenten persönlich kennen zu lernen.

Zuletzt veröffentlichte Beiträge: