Das req42-Framework
req42 ist alles, was Sie zum erfolgreichen Umgang mit Wünschen und Anforderungen in einer agilen Organisation brauchen. Wir nennen die Rolle, die für gutes Requirements Engineering zuständig ist, „Product Owner“ – und folgen damit dem Vorschlag von Scrum. (Sie können in Ihrem Umfeld natürlich andere Bezeichnungen für diese Rolle etablieren, wie z.B. Business Analyst, Requirements Engineer, Product Manager, Solution Manager). Wir bleiben der Einfachheit halber bei Product Owner.
Ergebnisorientiert – nicht prozessorientiert
req42 ist (wie das Schwester-Framework arc42 für Architekten) ergebnisorientiert und nicht prozess-orientiert aufgebaut. Es bietet Ihnen 12 Dinge an, die ein guter Product Owner im Griff halten sollte. In anderen Worten: 12 Artefakte, die man als Requirements-Verantwortlicher entwickeln und pflegen sollte. Denn:
Agiles Requirements Engineering ist viel mehr als nur das Product Backlog managen.
Die folgende Abbildung zeigt Ihnen das „Universum des Product Owners“ von req42. Als „Leitstern“ in der Mitte steht natürlich der Product Backlog als wichtigstes Artefakt, mit dem Sie sicherlich die meiste Zeit verbringen werden. Aber rundherum kreisen viele andere Artefakte, die Sie in Ihrer Rolle als Produkt-Owner aus Managementsicht oder aus Requirements-Sicht ernst nehmen sollten.
Die
blauen
Himmelskörper sind die eher requirements-orientierten Ergebnisse,
die
roten
Planeten sind die eher management-orientierten Aufzeichnungen,
und der
grüne
Planet stellt die Zwischenergebnisse Ihres Entwicklungsteams dar (die laufend gelieferten Produkt-Inkremente), die Sie als Product-Owner abnehmen müssen.
Die sechs Hauptaufgaben von Product Ownern:
Diese Ergebnisse, deren Aufbau, ihre Verwaltung und Pflege stehen im Mittelpunkt unserer Betrachtungen. Als didaktische Hilfsmittel haben wir aber auch die sechs Hauptaktivitäten eines Product Owners benannt, die im folgenden Bild dargestellt sind.
An den Doppelpfeilen zwischen den Tätigkeiten sehen Sie, dass Sie in der Rolle als Produkt Owner ständig mit all diesen Tätigkeiten befasst sind und beliebig zwischen den einzelnen Tätigkeiten wechseln können. Sie dienen nur der besseren Lehrbarkeit und Vermittelbarkeit.
req42 ist prozess-agnositisch. Es gibt keinen vorgeschriebenen Prozess, den Sie einhalten müssen. Wir empfehlen natürlich einen agilen Prozess, bei dem nur die Anforderungen detailliert ausgearbeitet werden, die demnächst für die Umsetzung als Produkt-Inkrement gebraucht werden.
Kein Dokument, sondern einfach geordnetes Wissen
Wir hoffen, dass die Metapher des Universums Sie davon abbringt, dass Sie alle Artefakte in Form eines Dokumentes verwalten müssen. Sie sollten diese Artefakte nur in irgendeiner Form greifbar haben, die es allen beteiligten Stakeholdern ermöglicht, darüber vernünftig zu kommunizieren.
Stellen Sie sich diese Artefakte als Schrank vor, wo jedes Artefakt sein eigens Fach hat. Der Schrank sollte heute natürlich keiner sein, der mit viel Papier in unterschiedlichen Fächern gefüllt ist, sondern lieber ein Wiki mit entsprechender Aufbaustrukur oder irgendeine andere elektronische Sammlung. Mit so einem Schrank können Sie das Universum des Product Owners durchnummerieren und die Artefakte in dem jeweiligen Schrankfach unterbringen.
Dieses Nummerierungsschema verwenden wir auch in unserem „Praxishandbuch für Agiles Requirements Engineering – Tipps zum Kommunizieren & Dokumentieren von Anforderungen“. Dort finden Sie eine voll ausgearbeitete Fallstudie, in der alle Fächer von req42 gefüllt sind, sowie über 100 Tipps für Product Owner.
- Vision/Ziele
- Stakeholder
- Scope-Abgrenzung
- Product Backlog
4.1 Epics
4.2 Features
4.3 User-Storys - Modelle zur Unterstützung
- Qualitätsanforderungen
- Randbedingungen
- Domänen-Terminologie
- Betriebsmittel & Personal
- Teamstruktur
- Roadmaps
- Risiken/Annahmen
(Wenn Sie den grünen Planeten – die Produkt-Inkremente – vermissen: diese sind im Schrank Ihres Entwicklungsteams enthalten. Als Produkt-Owner gehört Ihnen dieses Artefakt nicht; sie prüfen es nur nach Freigabe.)
Wie die Planeten des Universums bzw. die Fächer des Schranks mit den Aufgaben eines Product Owners zusammenhängen zeigt die folgende Tabelle. Sie sehen etwas deutlicher, mit welchen Artefakten Sie sich als Product Owner bei welcher Tätigkeit hauptsächlich auseinandersetzen müssen.
| Aufgabe | Artefakte |
|---|---|
| Clean Start | 9. Betriebsmittel & Personal |
| 1. Vision/Ziele | |
| 2. Stakeholder | |
| 3. Scope-Abgrenzung | |
| funktionale Anforderungen klären | 4. Product Backlog |
| 5. Modelle zur Unterstützung | |
| 8. Domänen-Terminologie | |
| Qualitäts- und Randbedingungen klären | 6. Qualitätsanforderungen |
| 7. Randbedingungen | |
| Planen und Schätzen | 10. Teamstruktur |
| 11. Roadmaps | |
| 12. Risiken/Annahmen | |
| Produkt-Inkremente prüfen | 13. Produkt-Inkrement |
req42 ist mehr als Scrum
Der Siegeszug und die Verbreitung von Scrum hat dazu geführt, dass viele Scrum gleichsetzen mit agilen Methoden. Ja, Scrum baut auf den Grundwerten des agilen Manifests auf. Aber eigentlich ist Scrum (nur) ein gutes Framework zur Entwicklung komplexer Produkte. Es fängt da an, wo Budgets bewilligt, potenzielle Teammitglieder benannt und erste Anforderungen bereits gesammelt sind und hört da auf, wo es an die tägliche Arbeit geht. Bewusst werden in Scrum Methoden, Techniken und Notationen offen gehalten um sich so möglichst vielen Situationen und Vorbedingungen anpassen zu können.
Neben Scrum sind viele andere agile Methoden entstanden, wie XP, Lean Development, Design Thinking, Crystal, u.a. Wir haben bei vielen davon Anleihen genommen und sie zu req42 zusammengebaut – als eine pragmatische Sammlung von „Good Practices“.
Beachten Sie, dass wir das Wort „Best Practices“ vermeiden. „Best“ klingt danach, dass es jemanden gibt, der das absolut Beste kennt – und daran glauben wir nicht. „Good Practices“ sind Tipps und Ratschläge aus der Praxis: Dinge, die in Projekten und Produktentwicklungen funktioniert haben und wert sind, ausprobiert zu werden, ganz nach dem agilen Prinzip “Inspect & Adapt”. Sie werden sehen, dass wir – je nach Randbedingungen – unter Umständen sogar widersprüchliche „Good Practices“ empfehlen – jeweils der Situation angepasst und angemessen.
In unserem Flagship-Workshop „Mastering Agile Requirements“ und in unseren Impuls-Coachings zeigen wir Ihnen zahllose „Good Practices“, pragmatische Tipps und Tricks zum Umgang mit den Kern-Artefakten. Sie lernen, als Product-Owner Produkte so zu entwickeln, dass sie von Ihren Kunden und Nutzern geliebt werden.