Читать книгу Der Scrum-Reiseführer - Tobias Renk - Страница 22

Auf Basis der Produktziele kann eine Product RoadmapProduct Roadmap erstellt werden. Der Begriff Roadmap lässt einen Wasserfall-Ansatz vermuten. Sie ist jedoch eine Strukturierungshilfe für die Produktziele. Für einen überschaubaren Zeithorizont wird der Weg zum nächsten Produktziel aufgezeigt.

Abbildung 16:

Einordnung der Product Roadmap

Hierbei können unterschiedliche Roadmap-Typen zum Einsatz kommen. Die wohl bekannteste Roadmap ist an den Funktionen des Gesamtproduktes bzw. des nächsten Produktziels (auf Ebene der Features oder Epics) ausgerichtet. Abbildung 17 zeigt eine solche Feature RoadmapFeature Roadmap.

Abbildung 17:

Feature Roadmap

Die Feature Roadmap wird meistens für einen größeren Zeithorizont genutzt. Typisch sind Zeiträume von größer als einem Jahr. Wenn es viele Features gibt, kann die Roadmap schnell unübersichtlich werden und die Abhängigkeiten zwischen den Features werden nicht ausreichend berücksichtigt. In solchen Konstellationen hat sich die zielorientierte RoadmapZielorientierte Roadmap bewährt (siehe Abbildung 18). Bei dieser Roadmap erfolgt die Strukturierung anhand von Hauptfunktionen zu einem Ziel auf der Roadmap. Dadurch bleibt die übergeordnete Sichtweise auf die Basis der Ziele erhalten, die Details sind ebenfalls erkennbar. Das Backlog ist damit klarer strukturiert. Bei der zielorientierten Roadmap wird, je nach Produktausprägung, ein Zeitraum von sechs Monaten bis zu maximal einem Jahr genutzt, wobei alle ein bis drei Monate eine Überprüfung und Anpassung anhand der Sprintergebnisse vorgenommen werden sollte.

Abbildung 18:

Zielorientierte Roadmap

Ein weiterer Vorteil der zielorientierten Roadmap ist, dass sie Roadmap-Ziele hat. Entweder werden kurzfristige Produktziele abgebildet – dann sind bereits alle Anforderungen an die Ziele erfüllt – oder sie werden durch Unterziele auf dem Weg zu den nächsten Produktzielen ergänzt. Im zweiten Fall sind für die Unterziele ebenfalls die grundlegenden Kriterien für Ziele zu erfüllen. Zumindest sollte jedem Unterziel eine sinnvolle Metrik, mit der die Zielerreichung gemessen wird, zugewiesen werden. So können der Entwicklungsfortschritt und die damit einhergehende Wertsteigerung auf dem Weg zum Produktziel geprüft werden.

Die Features der zielorientierten Roadmap lassen sich einfach auf die Formulierung der Sprintziele übertragen. Im Grunde stellt dieser Übertrag die gleiche Beziehung wie zwischen Produktzielen und deren Unterzielen in der Roadmap dar. Ein Sprintziel wird erst bei der Sprintplanung vom Scrum Team formuliert und ist die selbstverpflichtende Zielvorgabe für den aktuellen Sprint, ohne dabei zu definieren, welche Arbeit dafür erforderlich ist. Dadurch bleibt die Flexibilität erhalten.

In der Praxis ist dieser einfach klingende Ansatz schwieriger umzusetzen. Ein Grund dafür kann sein, dass nicht fokussiert genug auf ein Produktziel hingearbeitet wird. Möglicherweise gibt es auch zu viele Vorstellungen darüber, was im nächsten Sprint umgesetzt werden sollte, um das Produktziel zu erreichen. Einige Teammitglieder denken vielleicht an neue Funktionen, während andere der Meinung sind, dass erstmal die Infrastruktur erweitert und bereitgestellt werden müssen. Beides kann richtig sein und zum Sprintziel passen, muss es aber eben nicht. So wird die Festlegung auf ein Sprintziel zu einer Herausforderung. Achten Sie darauf, dass Sie sich am Ende auf ein Sprintziel verständigen und diese Diskussion nicht mit einer Reihe oder sogar ohne ein echtes Sprintziel endet.

Schließen Sie eine Funktion alle zwei bis drei Sprints immer auf der Feature- oder Epic-Ebene ab (siehe Abbildung 19). Die Sprintziele lassen sich so wesentlich konkreter formulieren. In diesem Szenario könnte das erste Sprintziel daher „Bereitstellung der Infrastruktur“ lauten. Das zweite Ziel könnten Sie als „Verbesserung von Feature XY“ festlegen. Auf diese Weise wird das Team motiviert, gemeinsam auf ein Thema hinzuarbeiten, anstatt alles parallel machen zu wollen und an unterschiedlichen Themen zu arbeiten. Selbstverständlich darf die agile Vorgehensweise bei der Entwicklung der Sprintziele nicht zu kurz kommen. Sollte sich während eines Sprints herausstellen, dass aufgrund eines unerwarteten Aufwands oder einer blockierten Aufgabe nicht alles erledigt werden kann, ermitteln Sie gemeinsam mit dem Product Owner, ob das das Sprint Backlog reduziert wird. Das Sprintziel sollte dabei nicht verändert werden. „Alle User Stories aus der Sprintplanung sind zu erledigen“ ist daher kein sinnvolles Sprintziel. Es muss auch dann erreicht werden können, wenn es nicht vollständig der Planung entspricht. Das Sprintziel „Reduzierung der Code-Komplexität von Feature XY“ bietet zum Beispiel ausreichend Spielraum.

Abbildung 19:

Produkttaktik

Im obigen Sprintziel aus den Bereich Refactoring könnte es das Ziel sein, eine 20-prozentige Verbesserung der Code-Komplexität zu erreichen. Was passiert, wenn nur 19 % erreicht wurden? Lässt sich dann noch immer von Erfolg sprechen? Vermeiden Sie deshalb vage Begriffe wie Erfolg oder Erfüllung von Zielen. Deutlicher wird es am Beispiel der Sorites-Paradoxie (Paradoxie des Haufens) oder an der Paradoxie des Eubulides (Paradoxie vom Kahlköpfigen). Die Sorites-Paradoxie beinhaltet die Frage, ab wann ein Sandhaufen kein Sandhaufen mehr ist, wenn einzelne Sandkörner entfernt werden.

 Gegeben: Ein Sandhaufen, aus dem einzelne Körner entfernt werden.

 Annahme: Das Entfernen eines einzelnen Korns verwandelt einen Haufen nicht in einen Nicht-Haufen.

 Paradoxie: Was passiert, wenn bei der bestehenden Annahme der Prozess „Entfernen eines einzelnen Sandkorns“ oft genug wiederholt wird? Ist ein einzelnes Sandkorn dann noch ein Haufen? Wenn nicht, wann hat es sich von einem Haufen in einen Nicht-Haufen verändert? Ist ein Sandhaufen durch die Anzahl der Körner definiert? Wenn ja, was ist, wenn alle Körner nebeneinander angeordnet sind?

Die Paradoxie des Eubulides stellt die Frage, wie viele Haare ein Mensch besitzen muss, um nicht als kahlköpfig zu gelten. Beiden Paradoxien liegt die Annahme zugrunde, dass ein einzelnes Sandkorn oder ein einzelnes Haar nicht über die Ausprägung Haufen oder behaart oder kein Haufen bzw. kahl entscheiden könne. Die Paradoxie zeigt sich in beiden Fällen, wenn versucht wird, etwas zu bestimmen, für das keine genaue Definition existiert.

Dieser Herausforderung können Sie umgehen, indem ein fester Grenzwert festgelegt wird. (Beispiel: 20-prozentige Reduzierung der Komplexität des Programmcodes). Gängige Praxis ist auch, einen Grenzbereich (Beispiel: 15- bis 20-prozentige Reduzierung der Komplexität des Programmcodes) oder mehrere Grenzwerte (Beispiel: Bei unter 8 bis 10 % ist das Ziel nicht erreicht, zwischen 10 und 15 % ist das Ziel erfüllt, bei über 15 % wird das Ziel übertroffen) zu verwenden. Sie können auch im Gruppenkonsens prüfen, ob das Ziel erreicht wurde (Beispiel: Gruppe entscheidet, ob die Verbesserung der Programmcodes ein Erfolg war). Lassen Sie bei der Bewertung genügend Spielraum. Welches Team hat schon Lust, das Sprintziel regelmäßig zu verfehlen, obwohl es nur wenige Prozentpunkte hinter den Zielvorgaben liegt?

Abbildung 20:

Überprüfungsintervalle von der Taktik bis zur Vision

Wie auch immer die Sprintziele bewertet werden, sie haben Auswirkungen auf das nächste Ziel der Product Roadmap. Daher sollten die Sprintergebnisse, abhängig von der Länge der Sprints, alle paar Wochen oder nach zwei bis drei Sprints dahingehend untersucht werden, ob das nächste Ziel auf der Product Roadmap noch realistisch ist. Abhängig davon kann das nächste Sprintziel darauf ausgerichtet werden. Vielleicht ist auch eine Korrektur der Ziele auf der Roadmap notwendig, um das nächste Produktziel zu erreichen. Daher sollte auch die Roadmap alle paar Monate (abhängig vom Roadmap-Typ, der Sprintlänge und den Produkttypen) überprüft und angepasst werden. Wenn anhand der Roadmap erkannt wird, dass ein Produktziel nicht erreicht wird oder obsolet geworden ist, sollte auch das Produktziel angepasst werden. Das sollte alle zwei bis neun Monate erledigt werden. Das Gleiche gilt für die Produktstrategie und die Vision. Prüfen Sie diese alle sechs bis zwölf Monate und nehmen Sie entsprechende Anpassungen vor. So erreicht man eine Rückkopplung von den Sprintergebnissen bis hin zur Produktvision (siehe Abbildung 20).

Abbildung 21:

Schritte von der Produktidee zu den Sprintzielen

In Abbildung 21 sind nochmal die wesentlichen Schritte auf dem Weg von der Produktidee zu den Sprintzielen zusammengefasst. Abbildung 22 zeigt die Rückkopplung, ausgehend von Sprintergebnissen bis hin zur Anpassung der Produktausrichtung.

Abbildung 22:

Von den Sprintergebnissen zur Anpassung der Produktausrichtung