© Bakhtiar Zeint/Shutterstock.com
Agile Produktentwicklung von Theorie bis Praxis – Teil 2

Agiles Schätzen und Planen


Im vorangegangenen Artikel „Scrum – eine Einführung für Entwickler“ wurden die Themen Product Backlog und User Stories kurz angesprochen und dabei erläutert, dass auch in agiler Produktentwicklung eine Einschätzung von Anforderungen mit Blick auf Umfang und Komplexität notwendig ist. In diesem Artikel wird nun näher darauf eingegangen und zusätzlich ein Überblick darüber gegeben, wie man von Schätzungen eines zeitlichen und inhaltlichen Rahmens für die grobe Roadmap- oder Releaseplanung hin zu einer konkreten Einschätzung von Anforderungen für die Planung der Iteration gelangt. Dabei wird gerade auch beim Prozess des Schätzens als Grundlage für die Planung klar werden, dass die Entwickler selbst die Schätzungen mit auf den Weg bringen.

Bei Agilität kommen die Planungen und Schätzungen aus den Teams, die auch für die schlussendliche Umsetzung zuständig sind. Auch wenn agile Entwicklungsteams meist keine offiziellen Rollen wie User-Experience-Designer, Entwickler, Tester usw. anerkennen, haben die Teammitglieder natürlich dennoch ihre Spezialisierungen. Darum sollen zumindest für diesen Artikel Entwickler, Programmierer oder Coder auch als solche anerkannt und als solche bezeichnet werden.

Von der Vision zur Schätzung

Wie eingangs schon erwähnt, gehört es auch zum agilen Entwicklungsvorgehen, wie zum Beispiel Scrum, dass die Planung von Umfang und Zeitrahmen der anstehenden Produktentwicklung aussagekräftig sein muss. So mancher könnte dabei aber auch die Frage stellen: „Warum denn überhaupt planen, wir sind doch jetzt agil?“

Agilität bedeutet nicht nur, in Iterationen und damit in einem maximalen Horizont von vier Wochen zu planen. Eine der großen Herausforderungen für das Produktmanagement ist es, zusammen mit dem Team, also auch den Developern, eine Antwort auf die Frage „Welche Inhalte können wir bis wann zur Verfügung stellen?“ zu finden. Das erfüllt keinen Selbstzweck, sondern dient dem Unternehmen oder der Organisation sowohl bei der Entscheidungsfindung als auch bei der Planung von Themen entlang der Produktentwicklung. Alle Maßnahmen wie Marketing, Werbung, Schulungen und der Aufbau von Infrastruktur, die die Entwicklung und die zugeordneten Releases flankieren, brauchen eine zugehörige Planung. Auch in Agilität gilt es, Kosten abzuschätzen, Gewinne zu kalkulieren und Risiken zu minimieren, indem man den Umfang (Scope) in Einklang mit den zeitlichen Anforderungen und den zur Verfügung stehenden Ressourcen bringt. Im Unterschied zu anderen Vorgehensmodellen, wie zum Beispiel dem Wasserfallmodell, liegt der Fokus auf der Planung und nicht dem Plan selbst. Die Erfahrung hat gelehrt, dass viele Unternehmen und Organisationen mit dem Versuch zu kämpfen hatten und haben, ein Konzept für die Fertigstellung von Softwareprojekten auch nur annähernd präzise aufzustellen. Agile Planung konzentriert sich also mehr auf den Prozess des Planens anstatt auf das Ergebnis, das am Ende dieses Prozesses steht.

In anderen Worten ausgedrückt geht es darum, den Plan nicht als ein in Stein gemeißeltes Dokument zu betrachten, in dem Änderungen maximal über Change Requests und das zugehörige Changelogs eingebracht werden. Entlang des agilen Manifests (Kasten: „Das Agile Manifest“) und des Grundsatzes „Responding to change over following a plan“ ermutigt Agilität sogar Änderungen im Plan. Das bedeutet nicht, dass man zwingend an den Zeitpunkten für Releases rütteln muss, sondern, dass man etwas dazugelernt hat oder einen Fehler vorhersehen und somit vermeiden konnte, und sich das dann durch Planung im geänderten Konzept widerspiegelt. Das können zum Beispiel Änderungen in den Ansprüchen des Marktes, dem Verhalten der Benutzer oder einfach nur neue rechtliche Anforderungen sein. Ganz aktuell würde es nichts helfen, im Plan an der Mehrwertsteuer von 19 Prozent festzuhalten, wenn – durch die Coronapandemie beeinflusst – die 16 Prozent Mehrwertsteuer beschlossene Sache sind. Während der agilen Planung erfolgt die Entscheidungsfindung immer wieder (unter Verwendung empirischer Inspektions- und Anpassungsmechanismen) und wird unter Berücksichtigung der vorliegenden Informationen über das gesamte Projekt verteilt. In diesen Prozess, der zu Änderungen des Plans ...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang