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


Im Weekly präsentiert das Team den aktuellen Stand für den Durchstich. Leider ist er nicht lauffähig. Sie begründen es mit einem aus ihrer Sicht notwendigen Refactoring des Codes, das sie noch nicht abschließen konnten.

« Nach unserer Einschätzung macht der Service PunktUpdater als eigenständige Komponente keinen wirklichen Sinn. Er braucht immer aktuelle Daten aus dem Store. Die Logik passt daher besser in den DatenManager. », erklärt Anne.

« Außerdem eliminieren wir dadurch den doppelten Datenstrom aus dem PunktUpdater zum Daten- und ReiseManager. Wir vermeiden gleichzeitig Probleme mit einer möglichen Überholung von Daten. », ergänzt Julius.

An der Architekturwand führen sie die Änderungen gemeinsam durch. Moritz erklärt sich bereit, diese Änderungen noch heute in das Wiki zu übernehmen. Er notiert sich die wichtigen Punkte. Die Studenten wirken etwas überrascht, weil sie davon ausgegangen sind, die Anpassung der Dokumentation selbst durchzuführen.

« Die Änderung ist kein Problem. Der Komponentenüberblick ist schnell angepasst. », behauptet Moritz. « Was ich dann noch anpassen muss finde ich ganz schnell heraus über die Seiteninformation von Service PunktUpdater. »

Gesagt, getan. Sie sehen, dass sich die Änderungen auf zwei Cases auswirken. Ein kurzer Blick in die Cases zeigt, dass jeweils nur ein Essenzschritt in der Lösung angepasst werden muss. Sie stellen gleichzeitig eine Lücke fest. Jeder Case eines Epics im Topic Reisewissen endet in der Regel an dem Punkt, an dem das Reisewissen für die Nutzung in der Assistenz bereitsteht. Das ist technisch gesprochen der Service DatenManager. Der Essenzschritt fehlt in beiden Fällen. Die Lücke wird Moritz mit seiner Änderung schließen. Nach dieser schnellen Recherche im Wiki sind die Studenten überzeugt, dass Moritz die Änderung wie versprochen schnell durchführen kann.

Das Team hat keine weiteren Themen für das Weekly. Die Studenten wollen das Refactoring beenden und den Durchstich in Ordnung bringen. Moritz legt los im Wiki.

Der erste Arbeitsschritt von Moritz ist das Zusammenlegen der Beschreibung von Service PunktUpdater und Service DatenManager. Die Arbeit beschränkt sich darauf, die Texte von einer Seite in die andere zu kopieren.

Nach dem Speichern der Änderungen will Moritz Feedback. Jetzt sind alle Entwickler da. Es bietet sich für Moritz daher die Gelegenheit, Feedback direkt von den Entwicklern einzuholen. “Pair Writing” nennt Moritz seinen Vorschlag in Anlehnung an “Pair Programming”. Anne und Richard erklären sich sofort bereit mitzumachen. Gemeinsam passen sie noch eine Formulierung in der dynamischen Sicht an. Dann sind alle zufrieden.

Im nächsten Arbeitsschritt ersetzt Moritz in der Lösung der betroffenen Cases den Service PunktUpdater durch den Service DatenManager. Dafür muss er nicht einmal Text schreiben. Er muss nur das Confluence-Makro “Include Excerpt” anpassen, da in jedem Case der zu ändernde Essenzschritt aufgrund der gewählten einheitlichen Lösung mit dem Event Punktdaten identisch ist. Das geht bei zwei Cases natürlich ruck zuck. An dieser Stelle ist er froh, die Methode CARDS+ gewählt zu haben. Der Arbeitsaufwand wäre selbst dann noch klein gewesen, wenn sie die Änderung erst später beschlossen hätten. Selbst eine viel größere Menge von Cases für das Reisewissen wäre sehr schnell geändert gewesen.

Im dritten Arbeitsschritt aktualisiert er den Komponentenüberblick in der Medienbibliothek. Auch das ist schnell erledigt. Durch die Abbildung wird die Vereinfachung so richtig gut sichtbar. Der Übergang von Domain Backend in Domain Assistenz besteht nur mehr aus einer losen Kopplung durch einen event-basierten Datenstrom.

Zur Sicherheit überprüft Moritz noch, ob die Änderung im Komponentenüberblick Änderungen in anderen Seiten erforderlich macht. Aber die Seiteninformation bestätigt, dass der Komponentenüberblick derzeit ausschließlich in der Hauptseite der Systemstruktur eingebettet ist. Und diese Seite hat keinen Text zum Bild.

Zum Abschluss muss Moritz die nicht mehr gültige Seite für den Service PunktUpdater entfernen. Er entscheidet sich für ein zweistufiges sicheres Löschen. Zuerst verschiebt er die Seite. Sie ist jetzt eine Unterseite der Bitte-Löschen-Seite im Wiki. Für alle Entwickler ist die Seite jetzt praktisch gelöscht, weil sie in ihrer Anzeige nicht mehr sichtbar ist. Sollte ein Entwickler jedoch irgendwo die Seite weiterhin verlinkt haben, z.B. in seinem persönlichen Bereich oder im Teambereich, dann würde der Entwickler die Fehlermeldung bekommen, dass er sich an einen Administrator wenden soll – das ist Moritz oder Richard. Zusätzlich bekommt Moritz als letzter Autor der Seite einen Hinweis per E-Mail, dass jemand eine gelöschte Seite ansehen wollte. Er kann aktiv auf diese Person zugehen und ihn informieren.

Eine Bitte-Löschen-Seite kann sehr einfach und mit Standardfunktionen von Confluence realisiert werden. Greift ein Autor oder Leser auf eine vorläufig gelöschte Seite zu, schickt Confluence eine E-Mail an den letzten Autor der Seite mit der Bitte um Zugriff auf die Seite. Durch die E-Mail-Benachrichtigung erkennt der Autor der vorläufig gelöschten Seite verstreute Links und kann andere Autoren und Leser gezielt informieren, dass die Seite bald gelöscht wird.

Weiterlesen auf cardsplus.info

Dieses Vorgehen erscheint auf den ersten Blick etwas kompliziert. Aber ab morgen arbeiten sie wieder verteilt. Moritz ist überzeugt: « Es sind die kleinen Dinge, die unsere Zusammenarbeit im Team verbessern. »

Insgesamt hat Moritz etwa eine Stunde für die unbedingt notwendigen Anpassungen im Wiki gebraucht. Die Architekturwand und die Produktdokumentation passen jetzt wieder zusammen. Moritz teilt dem Team mit, dass er im Wiki fertig ist. Er bittet sie, die Änderungen noch einmal kritisch zu lesen. Das muss aber nicht heute sein. Feedback sollen sie einfach als Kommentare hinterlassen.

Zuletzt veröffentlichte Beiträge: