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


Die ersten Wochen seit dem offiziellen Projektstart mussten Moritz und das Team eine ganze Reihe von Entscheidungen treffen. Moritz hat sich in dieser Zeit bemüht, so viel wie möglich im Wiki aufzuschreiben, mit den Bausteinen der Methode CARDS+.

Mittlerweile gibt es auch einen Teambereich in Confluence. Die Gestaltung dieses Bereiches überlässt er ganz dem Team. Richard hat sich in der letzten Zeit sehr motiviert gezeigt, die Pflege dieses Bereiches zu übernehmen. Für Moritz ist es eine Entlastung, so kann er sich voll auf die Rolle des Gärtners für die Produktdokumentation konzentrieren.

Einen ersten Projekterfolg kann das Team ebenfalls verbuchen. Sebastian, der Betreuer der Studenten, akzeptiert stellvertretend für die TU das aus dem Wiki exportierte Dokument mit den Bausteinen Decision, Topic, Epic und Case als Pflichtenheft. Der vorläufige Stand im Wiki hat ihn überzeugt. Er vertraut darauf, dass zum Projektende die Qualität stimmt und das Pflichtenheft vollständig ist. Er vergisst auch nicht darauf hinzuweisen, dass ein Teil der Beurteilung der Arbeit der Studenten von diesem Dokument abhängt.

Moritz schlägt die Verwendung von JIRA vor. Da sie sich schon ganz am Anfang aufgrund ihrer Arbeitszeiten gegen Scrum als agile Methode entschieden haben, wollen sie lieber aufgabenbasiert arbeiten, wie bei Kanban. Die Realisierung werden sie aber in Anlehnung an Scrum in Produktinkremente zerlegen. Das Team schlägt Trello als Alternative vor. Trello ist kostenlos, überall verfügbar und leicht zu bedienen.

Richard kennt Trello bereits sehr gut. Er nutzt es sogar privat zur Organisation seines Studiums. Einstimmig wird er vom Team zum Administrator gewählt. Er wird sich heute noch darum kümmern, ein neues Board für das Projekt anlegen. Glücklicherweise hat bereits jeder im Team und auch Moritz ein persönliches Konto bei Trello. Richard muss daher nur die Nutzerdaten einsammeln, eine Organisation für das Team anlegen und das Board mit den Listen “To do”, “Do it” und “Done” anlegen.

Nachdem dieser wichtige Punkt geklärt war, nutzen sie diesmal das Teamwork für die Definition der Ziele des ersten Produktinkrements. Moritz nennt es Produktinkrement Null.

Anne fragt: « Warum beginnst du die Zählung der Inkremente bei Null? »

« Mit der Null möchte ich ausdrücken, dass wir erst ein paar wichtige Grundlagen schaffen müssen, bevor wir richtig loslegen können. Wir brauchen eine Automatisierung für Integration und Lieferung. Das ist mir sehr wichtig. Alle Komponenten können auf Knopfdruck installiert werden. Unit-Tests werden automatisch ausgeführt. Komplexere Teststufen werden regelmäßig ausgeführt, zu bestimmten Zeiten oder als Teil eine CI-Pipeline. »

Für die Erreichung dieser wichtigen Ziele formulieren sie Aufgaben, die Moritz einzeln Task für Task in Trello anlegt und dem Produktinkrement Null zuordnet. In wenigen Worten umschreibt er jeweils die Aufgabe, so wie sie eben besprochen wurde, für alle sichtbar durch den Beamer an die Wand geworfen.

Die ersten Aufgaben betreffen den Aufbau der Arbeitsumgebungen. Moritz schlägt eine Unterscheidung der Rollen Dev/DevOp und Tester vor. « Die Unterschiede ergeben sich, sobald ihr eure Werkzeuge auswählt. Wenn ihr keine Unterscheidung braucht, schließen wir einfach den Task für den Tester! », verteidigt Moritz seinen Vorschlag. Er kann sich aber nicht durchsetzen, weil niemand im Team einen Vorteil darin sieht, zwischen Entwickler und Tester zu unterscheiden.

Jeder Entwickler im Team benötigt eine lokale Arbeitsumgebung mit Code-Editor und Zugriff auf Confluence, Trello, Fitnesse, Gitlab und die Cloud-Infrastruktur bei Amazon.

Moritz appelliert an das Team: « Bitte denkt bei der Konfiguration der Werkzeuge an die Spielregeln, die wir zuletzt vereinbart haben. Ihr könnt eure Arbeitsumgebung gestalten, wie ihr wollt. Mir ist aber wichtig, dass Code und Testfälle für alle im Team lesbar sind. Auch für mich. »

Zuletzt veröffentlichte Beiträge: