Organisatorische Ebenen – P4-Dev Framework V2

Cycle-Wechsel in der Inter-Cycle-Week

18. August 201915. Mai 2020 Oliver Schönfeld

Der Cycle stellt eine Art große Iteration auf Cluster-Ebene dar, man könnte ihn auch als „Cluster-Iteration“ bezeichnen. Meist wird der Cycle auch für die Portfolio-Ebene der gesamten Organisation verwendet. Der Zyklus besteht aus mehreren Iterationen, einem Vorspann, bestehend aus Cluster-Planning und einem Nachspann, bestehend aus Cluster-Review und Cluster-Retrospektive. Da diese Events eine nicht zu vernachlässigende Zeit benötigen, sieht das P4-Framework dafür eine komplette Woche pro Vierteljahr vor, die als Interzykluswoche bezeichnet wird. Durch diesen Ansatz kommen die Iterations-Events, die ja immer am gleichen Wochentag stattfinden, nicht durcheinander.

Die Interzykluswoche befindet sich exakt zwischen den Iterationen zweier Zyklen und beginnt am Tag nach den Team-Retrospektiven, nicht etwa am folgenden Montag. Sie beendet den vorangegangen Zyklus durch ein gemeinsam im Cluster abgehaltenes Cluster-Review und eine Cluster-Retrospective (sowie einem Portfolio-Review und einer Organisations-Retrospective, falls die Organisationebene ebenfalls in Cycles arbeitet) und startet den nächsten Cycle durch ein Cluster-Planning (mit einem ggf. vorherigen Portfolio-Planning). Das folgende Bild illustriert dies:

Legende:

CPL=Cluster-Planning, CRef=Cluster-Backlog-Refinement, CRv=Cluster-Review, CRt=Cluster-Retrospective.

\r\n

Passende und weiterführende Artikel:

Events

Rollen

Gruppen

Artefakte

Team-Planning

Team-Sync

Team-Backlog-Refinement

Cluster-Backlog-Refinement

Cluster-Review

Cluster-Retrospective

Organisations-Retrospektive

Team-Product-Owner

Team-System-Engineer

Team-Scrum-Master

Cluster-Product-Owner

Cluster-System-Engineer

Cluster-Scrum-Master

Portfolio-Owner

Portfolio-Architekt

Organisations-Scrum-Master

Working-Team

Community-of-Practice

Team-Product-Owner-Gruppe

Team-System-Engineer-Gruppe

Team-Scrum-Master-Gruppe

Managementkreis des Clusters

Cluster-Product-Owner-Gruppe

Cluster-System-Engineer-Gruppe

Cluster-Scrum-Master-Gruppe

Managementkreis der Organisation

Team-Backlog

Inspizierbare-Ergebnisse

Team-DoD

Team-Improvement-Backlog

Cluster-Backlog

Nutzbares-Wissen & System-Inkrement

Cluster-DoD

Cluster-Improvement-Backlog

Portfolio-Backlog

Systeme & Applikationen

System-Plattformen & Varianten

Organisations-DoD

Organisations-Improvement-Backlog

Team-Tasks

13. August 201914. Mai 2020 Oliver Schönfeld

Team-Tasks sind Aufgaben und Aktionen, die ein Working-Team plant und durchführt, um Team-Ziele zu erreichen. Team-Tasks sind Teil des Iteration-Backlog und werden in der Regel erst im Team-Planning erfasst und geplant.

\r\n

Passende und weiterführende Artikel:

Events

Rollen

Gruppen

Artefakte

Team-Planning

Team-Sync

Team-Backlog-Refinement

Team-Product-Owner-Gruppe

Team-System-Engineer-Gruppe

Team-Backlog

Inspizierbare-Ergebnisse

Team-DoD

Team-Improvement-Backlog

Team-Ziele

13. August 201914. Mai 2020 Oliver Schönfeld

Team-Ziele sind die meistgenutzten Elemente des Team-Backlogs. Sie beschreiben Ziele und (Zwischen-)Ergebnisse des Teams bezüglich eines Features, eines Moduls oder einer Dienstleistung, je nach Art und Verantwortung des Teams.

Allgemein ausgedrückt: Durch die Arbeit des Working-Teams werden Team-Ziele in inspizierbare Ergebnisse verwandelt.

Samples & Integrations (Backlog-Elementtyp)

13. August 201914. Mai 2020 Oliver Schönfeld

Samples & Integrations repräsentieren alle Arbeiten, die für Aufbauten (egal, ob virtuell oder physisch) und deren Tests anfallen. Dies können Konzepte, Simulationen, prototypische Teilaufbauten, virtuelle Prototypen, rapid Prototypes, bis hin zu Vorserienmustern sein, die ggf. in Anwenderstudien getestet werden. Samples & Integrations werden erzeugt, um durch Lernen Wissenslücken zu schließen. Daher werden die Samples stets bewusst so geplant, dass sie mit minimalem Zeitaufwand erzeugt und getestet werden können, damit Wissenslücken in nutzbares Wissen verwandelt werden. Samples, die keine Wissenslücken schließen, werden nicht gebaut!

\r\n

Passende und weiterführende Artikel:

Wissenslücken (Knowledge Gaps)

13. August 201914. Mai 2020 Oliver Schönfeld

Produktentwicklungen beginnen heute sehr selten „auf der grünen Wiese“. Je nach Kompetenz der Organisation, sind gewisse Dinge bereits bekannt und können wiederverwendet werden. Alle unbekannten Dinge bezeichnet das P4-Framework als „Knowledge-Gaps“. Die Idee dahinter ist, dass eine Produktentwicklung als beendet betrachtet werden kann, wenn alle Knowledge-Gaps in nutzbares Wissen und Design-Entscheidungen verwandelt wurden.

(Anmerkung für Prozessexperten: Knowledge-Gaps stellen ein neues Konzept dar. Sie verbinden die Idee der „Hypothesen“ aus Lean-Startup mit dem „Knowledge-based“ Development von LPPD, dem Risiko-Management klassischer Prozesse und dem risiko-basierten Vorgehen aus dem Unified Process.)

Die Gap-Map

Die Gap-Map zeigt auf dem Hintergrund einer geeigneten Darstellung des „System-under-Development“ und seines Kontexts, die dazugehörenden Knowledge-Gaps als rotes Post-it. Grüne Post-its visualisieren Elemente und Schnittstellen, die nicht geändert werden oder im Laufe des Vorhabens bereits durch Gelerntes entschieden wurden.

Folgende Dinge können über die Gap-Map abgelesen werden:

Bereiche, mit einer Häufung von Knowledge-Gaps bedürfen einer höheren Aufmerksamkeit
Die Summe aller gewichteten Knowledge-Gaps ergeben den (Rest-)Aufwand der Produktentwicklung! Die Gewichtung bzw. Aufwandsschätzung wird von dem durchführenden, interdisziplinären Team vorgenommen, z.B. mittels Planning Poker.
Knowledge-Gaps sind Backlog-Elemente auf einer hohen Flughöhe und werden durch Herunterbrechen (Refinement) in kleinere, ausführbare Elemente zerlegt. Damit stellen Knowledge-Gaps den inhaltlichen Plan der Produktentwicklung dar.
Knowledge-Gaps ermöglichen ein einfaches Risiko-Management, da sie die produktbezogenen Unsicherheiten darstellen. (Achtung: Organisatorisches Risikomanagement ist zusätzlich notwendig)
Wenn alle roten Post-its in grüne Post-its verwandelt wurden ist die Produktentwicklung beendet

Durch die Einfachheit und Übersichtlichkeit stellt eine Gap-Map ein hervorragend geeignetes Kommunikationsmittel zwischen dem Team und dem Management dar.

\r\n

Passende und weiterführende Artikel:

System-Konzepte, -Architekturen und -Fähigkeiten

13. August 201911. Mai 2020 Oliver Schönfeld

Systemkonzepte beschreiben mögliche Lösungen für System- bzw. Produktvarianten (Applikationen = Feature-Sets) und deren Anforderungen. Systemkonzepte realisieren dabei die System-Anforderungen innerhalb der Einschränkungen (Contraints) und balancieren die Qualitätsanforderungen (Quality Attributes) aus. Das P4-Framework sieht im System-Backlog explizit mehrere Systemkonzepte als Lösungsoptionen für die Umsetzung von Systemanforderungen vor. Dies bedeutet, dass möglicherweise mehrere Lösungen für ein Problem identifiziert und weiterentwickelt werden (Divergenz im Lösungsraum). Ziel der Produktentwicklung ist es, nur so viele unterschiedliche Systemkonzepte zu entwickeln (parallel oder nacheinander), bis einige Konzepte disqualifiziert und sich idealerweise ein klarer Favorit herausstellt. Je nach Innovationsgrad der Entwicklung können dies anfangs sehr viele Konzepte sein, oder es ergeben sich sogar neue Konzepte während der Produktentwicklung.

In der heutigen Produktentwicklung hat sich das Konzept der Wiederverwendung und das Denken in Baukästen, Produktlinien und Plattformen stark durchgesetzt. Dies wird im P4-Framework durch den Architekturaspekt dieser Ebene abgebildet. Die Anforderungen an die Plattform sind in den „Quality Attributes & Constraints“ enthalten (z.B. Modularität, Wiederverwendbarkeit, Märkte und Anwendungen).

Die Verantwortung des Cluster-System-Engineers ist auch die Aufteilung von sogenannten Fähigkeiten (Capabilities) auf Module, die in komplexeren Systemen als Dienste (Services) beschrieben werden. Der Grundgedanke dabei ist, dass bestimmte Module Fähigkeiten zur Verfügung stellen, die von anderen Modulen genutzt werden können.

\r\n

Passende und weiterführende Artikel:

System-Anforderungen & Funktionen

13. August 201916. Mai 2020 Oliver Schönfeld

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:

Applikationen und Marktvarianten

11. August 201911. Mai 2020 Oliver Schönfeld

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:

Vermarktbare Systeme und Anwendungen

11. August 201914. Mai 2020 Oliver Schönfeld

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:

\r\n

Passende und weiterführende Artikel:

Events	Rollen & Gruppen	Artefakte

Practice-Lead

11. August 201911. Mai 2020 Oliver Schönfeld

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

Cycle

Cadence

Community of Practice

Management-Kreis des Clusters

Management-Kreis der Organisation

Practice Backlog