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


Die nächste spannende Aufgabe abseits der Implementierung ist die Schätzung der Produktinkremente. Auch diese Aufgabe will Moritz zusammen mit Richard bewältigen, damit der Rest des Teams sich auf die Umsetzung des ersten Produktinkrementes konzentrieren kann. Natürlich gibt es zu Beginn eine kurze Diskussion über die Notwendigkeit einer Schätzung bei einem agilen Entwicklungsprozess.

Richard berichtet über eine Vorlesung: « Ich habe gelernt, dass bei Scrum die Qualität des Produktes an erster Stelle steht. Der Umfang des Produktes wird nicht zu Beginn festgelegt, sondern wird schrittweise erweitert. Meilensteine gibt es nicht. Der Auftraggeber kann sich am Ende eines Sprints entscheiden, ob er das Produktinkrement einsetzt. Einen Projektplan gibt es auch nicht, nur ein vom PO priorisiertes Backlog mit Stories, die vom Team geschätzt werden. »

« Das ist alles richtig. », bestätigt Moritz sofort. « Bitte bedenke aber, dass wir neben der Entwicklung des Reise-Butlers verpflichtet sind, eine Art Werkvertrag zwischen deiner Uni und uns abzuschließen. Dazu müssen wir gemeinsam das “Produkt” Reise-Butler definieren. Der Aufwand für die Umsetzung muss im zeitlichen Rahmen des SE-Projektes bleiben. Es gibt ein festes Ende, quasi ein in Stein gemeißelter Meilenstein. »

« Das habe ich nicht vergessen. Darum sollten wir eine Art Backlog mit Stories in Trello anlegen. Du priorisierst. Wir schätzen. », schlägt Richard vor.

« Das wird nicht klappen », entgegnet Moritz. « Ihr habt euch bewusst gegen Scrum entschieden. Das ist ok. Wir arbeiten nicht in Sprints, sondern wir definieren Produktinkremente. Ich kenne aber eure “velocity” nicht, d.h. ich weiß nicht, wie viele “story points” ihr pro Woche schafft. Bis wir als Team eingespielt sind und ein Gefühl für unsere “velocity” haben, wird das Projekt schon fast zu Ende sein. »

« Hmm, ja, da ist was dran. », räumt Richard ein. “Was machen wir jetzt? »

« Ich kenne eine Schätzmethode, die sehr gut zur Methode CARDS+ passt. Wir werden daher nicht Stories, sondern Cases schätzen. », schlägt Moritz vor. Mit der Schätzmethode werden Cases in einer Skala von einfach, normal oder komplex mit Punkten bewertet. Die Punkte aller Cases werden addiert, mit Faktoren für technische Komplexität und das Projektumfeld gewichtet und mit einem Produktivitätsfaktor multipliziert. Das Ergebnis sind Personenstunden.

Die Schätzmethode «Use Case Points» (kurz UCP) kann erfolgreich in frühen Projektphasen mit geringem Aufwand zur Schätzung von Arbeitsaufwänden in Software-Projekten verwendet werden.

Weiterlesen auf http://digital.ub.uni-paderborn.de/hsmig/content/titleinfo/5490

« Du meinst also, wir nehmen einfach die Cases im Wiki, die wir eh schon für das Pflichtenheft angelegt haben und schätzen sie. », fasst Richard Moritz’ Vorschlag zusammen.

« Korrekt! Das ist die Idee. », bestätigt Moritz und zeigt Richard die bereits vorbereitete Excel-Datei mit den existierenden Cases aus dem Wiki. Gemeinsam bewerten sie die Cases und bestimmen die Faktoren.

Richard hat die Schätzmethode soweit verstanden. Er ist aber unsicher. « Es bleibt eine Schätzung. Wir kennen die Produktivität nicht. Wir stehen vor dem gleichen Problem wie vorhin mit den Stories im Backlog. Story-Points oder Use-Case-Points – das ist doch quasi das Gleiche. »

Auf diese Frage ist Moritz vorbereitet. « Nicht ganz. Wenn wir aufgrund von Erkenntnissen während der Entwicklung einen neuen Case erstellen oder einen bestehenden Case verändern, dann aktualisieren wir auch die Bewertung in der Excel-Datei. Das Ergebnis ist ein neuer Schätzwert. »

Mit Beispielen erklärt Moritz das Vorgehen.

Es gibt eine neue Herausforderung für das Produkt, weil

  • der Bedarf der Nutzer sich ändert,
  • eine kreative Idee entstanden ist,
  • ein bisher unbekannter, aber wichtiger Sonderfall eine besondere Lösung erfordert.

Es gibt einen neuen Case mit entsprechender Beschreibung der Ausgangslage und einer geeigneten Lösung.

Das in der Ausgangslage des Cases beschriebene Problem ist unverändert. Es ist jedoch eine neue Lösung erforderlich, weil

  • die erste Lösung ein Fehlschlag war und eine neue Lösung erforderlich macht,
  • eine optimierte Lösung zur Steigerung der Leistungsfähigkeit notwendig ist,
  • eine runderneuerte Lösung für bessere Wartbarkeit sorgt.

Eine Betrachtung von Kosten und Nutzen für das Produkt führt zur Entscheidung, die neue Lösung umzusetzen. Der Case wird aktualsiert.

Das in der Ausgangslage des Cases beschriebene Problem ist unverändert. Es stellt sich jedoch heraus, dass eine Lösung schwieriger umzusetzen ist als ursprünglich gedacht, weil

  • die gewählte Lösung ungeplante Kosten verursacht,
  • die gewählte Lösung fehlerhaft ist, eine andere Lösung aber einen massiven Umbau erfordert,
  • die gewählte Lösung rechtliche Probleme (Lizenzbedingungen, Urheberrecht) schafft.

Eine Betrachtung von Kosten und Nutzen für das Produkt führt zur Entscheidung, die neue Lösung nicht umzusetzen. Der Case hat jetzt keine Lösung mehr.

Der Vorteil der Schätzmethode für das Team ist nach Einschätzung von Moritz die Möglichkeit, ihrer Leistung im Projekt transparent zu machen – vor allem gegenüber der TU. Jetzt, am Beginn des Projektes, wird mit der Schätzung eine Zahl bestimmt. Diese Zahl muss das Team am Ende erreichen. Bei unerwarteter Komplexität, die sie erst bei der Realisierung erkennen, kann das Team in Abstimmung mit Moritz die Bewertung für einen Case erhöhen. Dadurch kann die Zahl erreicht werden, selbst wenn ein Case gestrichen wird, weil nicht mehr genug Zeit übrig bleibt. Und Zeit ist der limitierende Faktor in diesem Projekt. Das Team verschafft sich außerdem einen Freiraum bei der Gestaltung des Produktes. Sie können Erkenntnisse während der Entwicklung nutzen, um durch einen Tausch von Cases die Lösungen umsetzen, die in der geschätzten Zeit realisiert werden. Sie können einen Case aussortieren, bei dem sie auf unerwartete Schwierigkeiten stoßen. Ein Tausch ist immer dann unkritisch, wenn die Bewertung gleich ist.

« Dieses Vorgehen ist doch auch mit einem Backlog und Stories möglich, oder? », fragt Richard.

« Ja, sicherlich. Ein Backlog mit Stories zu schätzen wird in etwa den gleichen Aufwand bedeuten wie eine Schätzung von Cases. Auch die Genauigkeit der Schätzung ist vermutlich gleich. Aber der Vorteil ist klar: Stories sind keine nachhaltige Dokumentation. Nutzen wir jedoch Cases, investieren wir in eine lebendige, mit dem Fortschritt des Produktes wachsende Produktdokumentation. »

Richard hat die Vorteile der Schätzmethode erkannt. Er hat selbst noch einen weiteren Gewinn in diesem Vorgehen erkannt. Die Cases müssen sie auf jeden Fall vollständig erfassen, um am Ende des Projektes das geforderte Pflichtenheft zu erstellen. Und selbst in dem Fall, dass sie einen Case aus irgendwelchen Gründen streichen, bleibt für Moritz zumindest der Case als Dokumentation erhalten. Ein entscheidender Vorteil gegenüber einer Story.

Zum Abschluss beschließen sie, Stories nur für die Aufgabenplanung im Team zu nutzen. Alle wichtigen Information zum Produkt wollen sie ausschließlich im Wiki sichern. Voll motiviert verspricht Richard, darauf hinzuwirken, dass auch die anderen Teammitglieder aktiv an der Produktdokumentation mitarbeiten.

Zuletzt veröffentlichte Beiträge: