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


Die Klausuren sind Geschichte, die Studenten haben wieder Zeit, sich mit dem Projekt Reise-Butler zu beschäftigen. Moritz freut sich, die Studenten zum Regeltermin Weekly zu begrüßen. Dieser Anglizismus hat sich eingebürgert für das regelmäßig Dienstag früh stattfindende Treffen. Das Weekly ist gleichzeitig Review, Refinement und Planung, um in Begriffen von Scrum zu sprechen. Review, weil sie immer mit der Präsentation der Ergebnisse der letzten Woche beginnen. Planung, weil sie beschließen, welche Aufgaben sie in dieser Woche erledigen wollen. Und Refinement, weil Moritz in der verbleibenden Zeit Fragen beantwortet.

Wegen der Klausuren kann das Team diesmal nichts präsentieren. Aber Moritz nutzt die Gelegenheit, um die neuen Inhalte im Wiki zu zeigen.

« Der Komponentenüberblick soll euch helfen, eine gemeinsame Vorstellung vom System zu bekommen. Mit den Service-Seiten im Wiki habt ihr zu jeder Komponente einen Anker. Dort könnt ihr Fragen und Ideen als Kommentare hinterlassen. Während der Implementierung tragt ihr die verwendeten Module ein. Dort könnt ihr Hinweise hinterlassen, wenn in der Komponente unerwartete oder überraschende Programmierung notwendig war.”

Tim meldet sich. « Was sind Module? », fragt er.

« Module subsummieren alle Technologien, Bibliotheken und Werkzeuge, die wir beim Programmieren verwenden. Das sind Datenbanken, der Message-Broker, Caches und Proxies. Dazu zählen auch Dienste im Internet, z.B. Facebook, Google und Co. »

Moritz zeigt im Wiki den Katalog der Module, die er bereits erfasst hat.

« Und wir dürfen alle diese Module verwenden? », fragt jetzt Julius.

« Grundsätzlich gibt es hier keine Beschränkungen. Der Einsatz muss halt angemessen sein. Ich möchte euch den größtmöglichen Spielraum lassen. Ich will aber eure Entscheidungen verstehen und nachvollziehen können. Aus diesem Grund werdet ihr bitte jedes weitere Modul ebenfalls im Wiki erfassen. Ich helfe euch dabei natürlich. CARDS+ ist eine agile Methode. Ich nutze Bausteine der Methode schon von Anfang an. Ihr kennt schon Topics und Epics. Auch Decisions kennt ihr schon, z.B. zur Frage der Übersetzung von Begriffen im Code. »

« Also bleibt es dabei, dass wir die Begriffe deutsch lassen? », hakt Tim sofort nach.

« Ja, so sehe ich das. », bestätigt Moritz. Er wartet einen Moment, ob Tim noch etwas entgegnet. Aber Tim scheint sich mit der Entscheidung abgefunden zu haben.

Moritz greift das ursprüngliche Thema auf und erklärt weiter: « Bei den Fachklassen verhält es sich ähnlich wie beim Komponentenüberblick. Die Diagramme sollen euch helfen, eine gemeinsame Vorstellung von den Datenstrukturen des Systems zu bekommen. Die verknüpften Entity-Seiten im Wiki sind der Platz für die Erfassung von Wissen, aber auch der Rahmen für Fragen oder Ideen. »

Plötzlich entbrennt eine heftige Diskussion über Dokumentation. Schnell wird klar, dass sie ziemlich genervt sind, weil sie für das SE-Projekt und eine positive Beurteilung einen Projektplan und ein Pflichtenheft erstellen müssen. Das ist eine ganze Menge Dokumentation. Moritz trifft da mit seiner Präsentation des Wiki gerade einen wunden Punkt. Zum Schluss zitiert Richard auch noch den zweiten Punkt des agilen Manifests: « Funktionierende Software ist unser Ziel, nicht Dokumentation. »

Moritz entgegnet vorsichtig: « Funktionierende Software ist uns wichtiger als umfassende Dokumentation. Das sehe ich auch so, keine Frage. Das bedeutet aber nicht, dass wir auf eine Dokumentation verzichten. Wir brauchen eine angemessene Dokumentation. CARDS+ hilft mir persönlich dabei, den Arbeitsaufwand im Wiki so gering wie möglich zu halten. Aber ich soll euch Fragen beantworten, über die App, das Backend, die Datenquellen. Also muss ich mich vorbereiten. Ich mache das sehr strukturiert mit den Bausteinen. Damit spare ich sogar Zeit und mache weniger Fehler. Und mit den Service– und Entity-Seiten gebe ich euch die gleiche Chance. Ich erwarte nicht, dass ihr die Methode beherrscht. Aber ich erwarte, dass ihr ein Wiki benutzt und versteht, welche Information wo hingehört. Ich will euer Feedback zu Ungenauigkeiten, Verbesserungen und Fehler. Mindestens als Kommentar. »

Stille. Offensichtlich denken die Studenten nach.

Julius ist der Erste: « Wenn ich dich richtig verstehe, dann nutzt du das Wiki, um den Reise-Butler zu beschreiben, sowohl fachlich, als auch technisch. Du erwartest von uns, dass wir da mitmachen. Richtig? »

« Richtig”, sagt Moritz, « Die Qualität der Dokumentation im Wiki hängt ganz stark von euch ab. Ihr programmiert das System, ihr bestimmt, wie es funktioniert. Darum ist es auch ganz wichtig, dass wir im Wiki nichts beschreiben, was durch euren Code oder Testfälle besser erklärt wird. Das Wiki beantwortet aber, wer es benutzt, wann und warum ein Nutzer es tut. Diese Fragen kann kein Code beantworten. »

« Aber dafür gibt es Code-Kommentare! », widerspricht Tim.

« Ja, Code-Kommentare wären eine Alternative. Aber dann verlange ich zwei Dinge. Erstens müsst ihr sicherstellen, dass ihr das ganze fachliche Wissen mit Code-Kommentaren erfasst. Zweitens benötige ich einen für mich lesbaren »Export« der Code-Kommentare. Ihr seid dann allein verantwortlich für die Qualität der Dokumentation, ich kann euch kaum helfen. Finde ich einen Fehler in der Dokumentation, müsst ihr die Korrektur im Code machen. »

Und an Tim direkt gerichtet: « Wie würde deine Dokumentation ausschauen? Glaubst du, dass es weniger Arbeitsaufwand ist, statt im Wiki direkt im Code zu dokumentieren? »

Offensichtlich überfordert Moritz Tim gerade mit seinen direkten Fragen. Um das Thema vorerst zum Abschluss zu bringen, erklärt Moritz, wie wichtig in diesem konkreten Projekt eine angemessene Dokumentation ist. Die Mitarbeit der Studenten ist begrenzt, es ist unwahrscheinlich, dass sie nach dem Ende des SE-Projektes als Team zusammen bleiben. Im besten Fall wird der Reise-Butler von eMundo übernommen und als internes Projekt weiterentwickelt. Aber auch bei internen Projekten wechseln die Mitarbeiter häufig. Oder das interne Projekt wird für eine unbestimmte Zeit auf Eis gelegt, wenn Mitarbeiter in anderen Projekten gebraucht werden. Sauberer Code, ausreichende Testabdeckung und eine hochwertige Dokumentation sind wichtige Voraussetzungen, um jederzeit die Arbeit am Reise-Butler fortzusetzen.

Eine kurze Pause kommt jetzt gerade recht und wird von allen freudig angenommen.

Zuletzt veröffentlichte Beiträge: