Der Portfolio-Owner ist der Product Owner der Organisation. Er hat zusammen mit der Cluster-Product-Owner-Gruppe (CPOG) auf der Portfolio- bzw. Organisationsebene die Gesamtverantwortung für die Markt- und Geschäftsseite des Produktentwicklungsprozesses. (Eine allgemeine Beschreibung des Product-Owner-Rolle befindet sich hier …)
Kategorie: Market & Business
Cluster-Product-Owner (CPO)
Der Cluster-Product-Owner hat mit der Team-Product-Owner-Gruppe auf der Cluster- und System-Ebene die Verantwortung für die Markt- und Geschäftsseite innerhalb des Produktentwicklungsprozesses. (Eine allgemeine Beschreibung des Product-Owner-Rolle befindet sich hier …)
System-Inkrement
System-Inkremente sind Teil- oder Vollintegrationen von Systemversionen, die durch interne oder externe Tests, sowie durch Nutzer- und/oder Markttests verifiziert werden.
System-Inkremente werden häufig auf Cluster-Ebene erzeugt d.h. durch die Integration von Teilergebnisse der verschiedenen Teams eines Clusters.
Für das System-Inkrement hat P4 die Arten und Definitionen von Mustern aus dem Design Thinking Framework übernommen. Sie definieren damit auch die Reifegrade der Muster (Samples).
Der Reifegrad wird letztlich über die Art und Anzahl der Knowledge-Gaps definiert. Um Knowledge Gaps zu schließen werden Muster aufgebaut.
.
\r\n
Passende und weiterführende Artikel:
| Events | Rollen | Gruppen | Artefakte |
| Cluster-Planning | Cluster-Product-Owner | Team-Product-Owner-Gruppe | Cluster-Backlog |
Portfolio-Backlog, Portfolio-Cycle-Backlog und Portfolio-Kanban
Die oberste Ebene der Backlogs des P4-Frameworks, die Portfolio- und Organisationsebene, beschreibt Applikationen und Marktvarianten der Systeme und Produkte. Jede dieser Varianten wird durch einen Satz von System-Anforderungen (Feature Set) beschrieben.
Verantwortung von Markt und Business durch den Product Owner
Das P4-Framework gliedert seine Organisations- und Managementstruktur der Produktentwicklung in drei Bereiche:
- Markt und Business (hier weiter ausgeführt)
- Organisation, Infrastruktur und Prozesse
- Technologie und Architektur
Markt und Business
Die Product-Owner-Rollen der verschiedenen Ebenen tragen die Verantwortung für die Produkte und deren Märkte. Dabei kommunizieren sie mit den Stakeholdern dieses Bereichs: Benutzer, Kunden und der (meist interne) Vertrieb.
Die Rolle des Product-Owners
Product, Product Backlog und Product Owner sind im P4-Framework generische Begriffe, d.h. sie existieren ausschließlich in spezifischen Ausprägungen. So hängen sowohl die generischen Artefakte „Product“, „Product Backlog“ als auch die generische Rolle „Product-Owner“ von der Art des jeweiligen Teams und der Ebene innerhalb der Organisation ab.
Der Product-Owner ist dafür verantwortlich, den Wert des Produktes zu maximieren, das aus der Arbeit des Working-Teams entsteht. Wie dies geschieht, kann je nach Organisation, Cluster oder Team und Einzelpersonen stark variieren. Der Product-Owner ist die einzige Person, die für das Management des Product-Backlogs verantwortlich ist. Das Management des Product-Backlogs umfasst:
- Die Product-Backlog-Einträge klar zu formulieren;
- Die Reihenfolge der Einträge im Product-Backlog so anzuordnen, dass Ziele und Missionen optimal erreicht werden können;
- Den Wert der Arbeit zu optimieren, die das Working-Team durchführt;
- Sicherzustellen, dass das Product-Backlog sichtbar, transparent und für alle klar ist und zeigt, woran das Team als nächstes arbeiten wird;
- Sicherzustellen, dass das Working-Team die Product-Backlog-Einträge im erforderlichen Maße versteht; und
- Die Ergebnisse des Working-Teams zu begutachten und abzunehmen.
Der Product-Owner kann die oben genannten Arbeiten selbst durchführen oder sie durch das Working-Team oder einzelne Mitglieder durchführen lassen. Der Product-Owner bleibt jedoch immer rechenschaftspflichtig (accountable).
Der Product-Owner ist eine einzelne Person, kein Komitee. Er kann zwar die Wünsche eines Komitees im Product-Backlog wiedergeben, aber diejenigen, die einen Eintrag des Product-Backlogs in seiner Priorität verändern möchten, müssen sich an den Product-Owner wenden. Damit der Product-Owner erfolgreich sein kann, muss die gesamte Organisation seine Entscheidungen respektieren. Die Entscheidungen des Product-Owners sind in Inhalt und Reihenfolge des Product-Backlogs sichtbar. Niemand anderer darf dem Working-Team Anforderungen oder Arbeit zuordnen.
Die Product-Owner im P4-Framework
Im P4-Framework wird die generische Rolle des Product-Owners auf allen drei Ebenen konkretisiert und erweitert: Wichtig dabei ist, dass die Product-Owner auf jeder Ebene sich untereinander innerhalb der jeweiligen PO-Gruppe abstimmen und dabei die Prioritäten für ihre Teams aus dem übergeordneten Backlog ableiten. (Mehr zu dem Überlappungsprinzip)
- der Team-Product-Owner (TPO) als PO für ein einzelnes Team. Alle TPOs des selben Clusters bilden die Team-Product-Owner-Gruppe (TPOG) dieses Clusters
- der Cluster-Product-Owner (CPO) als PO für einen Cluster aus mehreren Teams. Alle CPOs bilden die Cluster-Product-Owner-Gruppe (CPOG) der Organisation
- der Portfolio-Owner (PFO) als PO für die gesamte Organisation, bestehend aus mehreren Clustern.
.
\r\n
Passende und weiterführende Artikel:
| Events | Rollen | Gruppen | Artefakte |
| Team-Planning
. . |
Team-System-Engineer
. . |
Team-Product-Owner-Gruppe
. |
Team-Backlog
. Nutzbares-Wissen & System-Inkrement . |
System-Anforderungen & Funktionen
Systeme werden auf der obersten Ebene durch System-Anforderungen und Funktionen (Features) beschrieben. Anforderungen beschreiben dabei ausschließlich Fähigkeiten oder Eigenschaften im „Problemraum“, sind also noch losgelöst von konkreten System-Lösungen. Der Lösungsraum wird aber bereits durch die Quality Attributes & Constraints eingeschränkt.
Schnittstellen zu Nachbarsystemen im Umfeld sowie deren Eigenschaften werden hier ebenfalls spezifiziert. Hierfür wird ein sogn. Kontext-Diagramm erstellt und verwendet.
Funktionale Systemanforderungen der Stakeholder werden häufig in Form von User Stories* geschrieben und später durch „Use Cases“ tiefer spezifiziert.
*) P4 führt in diesem Zusammenhang den Begriff „Stakeholder Stories“ ein, da sie für die Spezifikation von Anforderungen aller Stakeholder, nicht nur der Benutzer, geeignet sind.
**) Nicht-funktionale Anforderungen (NFR) werden in P4 nicht direkt in das System-Backlog geschrieben (siehe Quality Attributes & Constraints)
.
\r\n
Passende und weiterführende Artikel:
| Events | Rollen | Gruppen | Artefakte |
| Cluster-Planning | Cluster-Product-Owner
. |
Team-Product-Owner-Gruppe
. |
Inspizierbare-Ergebnisse
. Nutzbares-Wissen & System-Inkrement . |
Applikationen und Marktvarianten
Applikationen und Marktvarianten sind die integrierten, getesteten und freigegebenen Produkte der Organisation, die in den Zielmärkten an Kunden vertrieben werden können. Sie entsprechen der Anforderungen, die aus den Stakeholder-Needs in den „Feature-Sets“ als Gruppe spezifiziert wurden. Einzeln sind diese in den System-Anforderungen & Funktionen sowie den Qulitätsattributen und Einschränkungen (QA&C) definiert.
.
\r\n
Passende und weiterführende Artikel:
| Events | Rollen | Gruppen | Artefakte |
| Cluster-Planning
. |
Cluster-Product-Owner
. |
Team-Product-Owner-Gruppe
. |
Inspizierbare-Ergebnisse
. Nutzbares-Wissen & System-Inkrement . |
Cluster-Product-Owner-Gruppe (CPOG)
Die Cluster-Product-Owner-Gruppe (CPOG) mit dem Portfolio-Owner hat auf der Portfolio- bzw. Organisationsebene die Gesamtverantwortung für die Markt- und Geschäftsseite des Produktentstehungsprozesses der Organisation.
Team-Product-Owner-Gruppe (TPOG)
Die Team-Product-Owner-Gruppe besteht aus allen Team-Product-Owner eines Clusters und dem Cluster-Product-Owner. Sie hat auf der Cluster- und System-Ebene die Verantwortung für die Markt- und Geschäftsseite innerhalb des Produktentwicklungsprozesses.
Benutzer, Kunden und Vertrieb
Dies sind die primären Stakeholder der Produktentwicklung auf allen Ebenen (Organisation, Cluster und Team). Auf der Team-Ebene haben besonders die Applikations-Teams einen engen Kontakt zu Benutzern, Kunden und dem Vertrieb, da sie die ultimativen Anforderungen an die Produkte, Systeme und Applikationen geben, sowie diese bewerten.
Stakeholder werden zu den Reviews eingeladen (also Team-Reviews, Cluster-Review, Portfolio-Review), um dem entsprechenden Team Feedback zu geben.
Stakeholder können zu Refinement-Meetings zur Klärung von Anforderungen eingeladen werden.
.
\r\n
Passende und weiterführende Artikel:
| Events | Rollen | Gruppen | Artefakte |
| Team-Backlog-Refinement
. . |
Team-Product-Owner
. . |
Working-Team
. . |
Team-Backlog
. Nutzbares-Wissen & System-Inkrement . |