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


Das Team macht gerade gute Fortschritte bei der Entwicklung. Das Weekly verläuft äußerst unaufgeregt. Die Dokumentation in Confluence ist auch stabil, weil Änderungen fast ausschließlich in der Dokumentation im Git-Repository stattfinden. Das manuelle Hochladen der Markdown-Dokumente mit Copy&Paste in die Confluence-Seiten erledigt Moritz mittlerweile in wenigen Minuten.

Das Thema Qualitätsmerkmale läßt Moritz nicht mehr los. Er möchte das Team einbinden, mindestens jedoch aufmerksam machen. Er schlägt dem Team vor, dass sie ab nächster Woche immer eine Stunde investieren, um ein von Moritz im Wiki vorbereitetes Qualitätsmerkmal zu besprechen und die Seite gemeinsam zu aktualisieren. Beginnen will er mit dem Qualitätsmerkmal Wartbarkeit. Hier sollten alle Entwickler eine starke Meinung haben.

Richard fragt nach. « Ist es nicht zu spät, um Qualitätsmerkmale zu definieren? »

« Wenn du mit “definieren” meinst, dass ich jetzt anfange, mir Qualitätsmerkmale zu wünschen, dann hast du recht. Dafür wären wir reichlich spät dran. », antwortet Moritz.

« Aber mit Qualitätsmerkmalen meinst du doch Skalierbarkeit, Performance. Oder Wartbarkeit, wie du vorhin vorgeschlagen hast. »

« Ja. Das ist richtig. »

« Genau. Und diese Qualitätsmerkmale hätten wir ganz am Anfang besprechen müssen. »

Moritz merkt an Richards Widerstand, dass er seinen Ansatz doch etwas ausführlicher erläutern muss.

« Wir sind uns einig, dass wir agil entwickeln wollen. Zwar nicht mit Scrum, aber ähnlich agil. »

Alle Studenten nicken.

« Im Verlauf von vielen Wochen seit unserem Projektstart haben wir viele Entscheidungen gemeinsam getroffen. Die wichtigsten haben wir mit dem Baustein Decision dokumentiert. Wir haben alle “fremden” Produkte, die wir einsetzen, z.B. Spring, Kafka oder Avro, mit dem Baustein Spec erfasst. Zusätzlich haben wir uns ein paar Rahmenbedingungen für unsere eigenen Komponenten und die App gesetzt und ebenfalls mit dem Baustein Spec angemessen dokumentiert. Richtig? »

« Richtig! », bestätigen alle.

« Dann ergeben sich doch eine ganze Reihe von Qualitätsmerkmalen ganz automatisch aufgrund unserer Entscheidungen. Das sind keine Wünsche, dass sind Fakten, die wir geschaffen haben. Ich möchte gerne diese Fakten übersichtlich zusammenfassen und nach Qualitätsmerkmalen gruppieren. »

Moritz erklärt ganz kurz die Grundlagen seines Ansatzes, also die ISO 9126 bzw. deren Nachfolger, die ISO 25010, und die dort vorgeschlagenen Qualitätsmerkmale. Er zeigt anhand seiner ersten eigenen Versuche die Chancen auf, die sich durch CARDS+ mit seinen maßgeschneiderten Bausteinen Decision und Spec ergeben.

Den Studenten ist anzusehen, dass es in ihren Köpfen arbeitet.

« Das klingt irgendwie total logisch. Und so einfach. », fasst Julius als erster seine Erkenntnis zusammen.

Anne und Georg sind unsicher und halten sich zurück.

« Machst du das in deinen Kundenprojekten auch so? », fragt Richard.

« Nein. Ich gestehe, dass ich so zum ersten Mal vorgehe. Es ist ein Versuch. In Kundenprojekten bin ich in der Regel mit einem umfangreichen Katalog von Qualitätsanforderungen konfrontiert, die aber häufig so ungenau formuliert sind, dass ein sehr großer Spielraum bei der Umsetzung bleibt. Mengengerüste werden so berechnet, dass sie praktisch die denkbar obersten Grenzen darstellen, die später nie erreicht werden. », fasst Moritz seine persönlichen Erfahrungen zusammen.

« Und wer braucht diese neue Art von Zusammenfassung von Entscheidungen? », fragt Tim.

« Ich, zum Beispiel. Als PO möchte ich wissen, was mein Produkt leistet, funktional und nicht funktional. Die Zusammenstellung hilft mir, alle Entscheidungen in einen größeren Kontext zu bringen. Ich kann eventuell Widersprüche in den Entscheidungen entdecken. Ihr gebt mir außerdem ein Werkzeug in die Hand, mit dem ich die Auswirkungen einer größeren Änderung sogar selbst beurteilen kann. »

Moritz merkt, dass die Studenten noch Fragen haben. Er will heute den Studenten jedoch nicht zu viel Zeit stehlen mit seiner unangekündigten Initiative. Mit dem Versprechen, dass sie sich in den nächsten Wochen mit allen acht Qualitätsmerkmalen der ISO 25010 beschäftigen werden, kann er die aufkeimende Diskussion beenden. Zum Abschluss gibt er den Studenten die Aufgabe mit, sich Gedanken über die Eigenschaften einer wartbaren Software zu machen und ihre eigenen Maßnahmen für dieses Ziel zu identifizieren.

Zuletzt veröffentlichte Beiträge: