Die Teams aller Cluster der Organisation, die Cluster-System-Engineer-Gruppe, die Cluster-Product-Owner-Gruppe und die Stakeholder müssen verstehen was es bedeutet, wenn ein Backlog-Eintrag oder ein Ergebnis als „Done“ bezeichnet wird. Obwohl sich die Cluster-DoDs erheblich von Cluster zu Cluster unterscheiden können, gibt es nur eine DoD auf Portfolio-Ebene für die gesamte Organisation.
Kategorie: Organisationsebene
Produkte, Applikationen und Marktvarianten
Das Portfolio-Backlog auf Organisationsebene, der oberste Ebene der Backlogs, enthält Systeme, Produkte und technische Produktvarianten, sowie Produktvarianten für spezielle Märkte. Jede dieser Produktvarianten wird durch einen Satz von System-Anforderungen (Feature Set) beschrieben. Auf diese Weise sind die Produktvarianten sowohl bezüglich des Nutzens, als auch bezüglich des zu investierenden Aufwands gegeneinander abschätzbar. Hierfür wird im P4-Framework das sogenannte Upswing-Gravity-Field verwendet.
Die Portfolio-Ebene ist nicht nötig für Organisationen, die nur ein einziges Produkt erstellen.
.
\r\n
Passende und weiterführende Artikel:
Events | Rollen | Gruppen | Artefakte |
Portfolio-Planung | Portfolio-Owner | . | Portfolio-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.
Organisationsebene
Die Organisationsebene repräsentiert die oberste Ebene in der Produktentwicklung, und damit alle Personen, Rollen und Gruppen. Sie wird auch als Portfolio-Ebene bezeichnet. Alle Arbeiten der Organisation sind im Portfolio-Backlog mit größtmöglicher Transparenz dargestellt.
Cluster-System-Engineer-Gruppe (CSEG)
Die Cluster-System-Engineer-Gruppe (CSEG) besteht aus den Cluster-System-Engineers aller Cluster der Organisation. Sie entspricht auf der Organisationsebene der Rolle des Working-Teams auf Team-Ebene.
Die Cluster-System-Engineer-Gruppe hat mit dem Portfolio Architect auf der Organisations- bzw. der Portfolio-Ebene die Verantwortung für die Technologie- und Architekturseite des Produktentstehungsprozesses.
Kadenz (Cadence) eines Jahres
Die Kadenz (englisch Cadence) ist eine zentral festgelegte Event-Planung für die Organisation. Sie ermöglicht es, ähnlich einem Stundenplan an einer Schule oder Universität, dass …
- alle Rollen innerhalb der Organisation an den für sie vorgesehenen Events teilnehmen können. (Keine überlappenden Einladungen)
- alle privaten Events der Teams und Gruppen gleichzeitig stattfinden, um möglichst viel freie Arbeitszeit innerhalb der Teams und Gruppen zu ermöglichen
Die Kadenz eines Jahres besteht im P4-Framework aus vier sogenannten Cycles, die jeweils ein Vierteljahr betragen. An Übergängen zwischen den Cycles finden verschiedene Organisations- und Cluster-Events statt, ähnlich dem Iterationswechsel in Scrum. Es ist empfehlenswert, den Cycle-Wechsel nicht auf kalendarische Viereljahresgrenzen zu legen, damit ein Wechsel z.B. nicht mit dem Jahreswechsel und die davor liegenden Weihnachtszeit kollidiert.
.
\r\n
Passende und weiterführende Artikel:
Events | Rollen | Gruppen | Artefakte |
Team-Planning
. . |
Team-Product-Owner
. . |
Working-Team
. . |
Team-Backlog
. 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 . |
Vermarktbare Systeme und Anwendungen
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 den 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.
.
Passende und weiterführende Artikel:
Events | Rollen | Gruppen | Artefakte |
Cluster-Planning
. |
Cluster-Product-Owner
. |
Team-Product-Owner-Gruppe
. |
Inspizierbare-Ergebnisse
. Nutzbares-Wissen & System-Inkrement . |
\r\n
Passende und weiterführende Artikel:
Events | Rollen & Gruppen | Artefakte |
Practice-Lead
Practice-Leads sind fachliche Coaches oder Trainer innerhalb der Organisation, die sich um eine Expertise oder technische Disziplin kümmern. Sie führen eine Community-of-Practice, bilden deren Mitglieder aus und kümmern sich um die Weiterentwicklung des Themas und der Mitarbeiter innerhalb der Organisation.
Beim Übergang von klassischen Organisationen können die ehemaligen Linienvorgesetzten zu Practice-Leads werden.
.
\r\n
Passende und weiterführende Artikel:
Events | Rollen | Gruppen | Artefakte |
Iteration
. |
Community of Practice
. . |
Practice Backlog |
Communities-of-Practice
Communities-of-Practice (CoP) sind Gruppen, die sich um spezielle Wissens- und Erfahrungsthemen kümmern. Alle Mitarbeiter haben die Möglichkeit, innerhalb ihrer „Practice-Zeit“ bzw. Ausbidungszeit in den selbstorganiserten CoPs zu arbeiten. Das P4-Framework sieht hierfür ca. 10% der Arbeitszeit vor.