Stakeholder-Needs

Stakeholder sind alle von einem System betroffenen Personen und Personengruppen, sowie alle direkt am Produkt Interessierte oder Beteiligte. Stakeholder werden auf allen Ebenen in die Reviews eingeladen und können optional in Backlog-Refinement-Meetings eingeladen werden, um ihre Anforderungen zu erläutern.

Um Stakeholder zu identifizieren verwendet das P4-Framework zwei unterschiedliche Lebenszyklen als gedankliche Leitfäden. Dies sind

  • der Produktlebenszyplus (von der Idee bis zum Ende der Produktpflege) und
  • der Einzelstücklebenszyklus (vom Einkauf des Rohmaterials bis zum Recycling)

Für jedes Produkt oder System lassen sich an diesen die unterschiedlichen Stakeholder (=Intressengruppen) identifizieren.

Produktlebenszyklus

Einzelstücklebenszyklus

Im P4-Framework werden drei Gruppen von Stakeholder unterschieden, die den drei Bereichen zugeordnet werden

Stakeholder-Needs

Stakeholder-Needs sind die Bedürfnisse der im ersten Schritt identifizierten Stakeholder. Sie repräsentieren keine eigentlichen Backlog-Item-Typen, ermöglichen es aber, dass der Nutzen von neuen oder geänderten Anforderungen klarer wird. Sie stellen die oberste Ebene von Anforderungen dar und sollten ständig aktualisiert vorliegen (nicht erst, wenn neue Produktentwicklungen gestartet werden). Dies ist in der Regel leicht möglich, da sich Stakeholder-Needs nur relativ langsam ändern.

.

\r\n


Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Cluster-Planning

Cluster-Sync

Cluster-Backlog-Refinement

Cluster-Review

.

Portfolio-Planung

Organisations-Sync

Portfolio-Refinement

Portfolio-Review

.

Cluster-Product-Owner

Cluster-System-Engineer

.

Portfolio-Owner

Portfolio-Architekt

Team-Product-Owner-Gruppe

Team-System-Engineer-Gruppe

Managementkreis des Clusters

.

Cluster-Product-Owner-Gruppe

Cluster-System-Engineer-Gruppe

Managementkreis der Organisation

Inspizierbare-Ergebnisse

Team-DoD

.

Cluster-Backlog

Nutzbares-Wissen & System-Inkrement

Cluster-DoD

.

Portfolio-Backlog

Systeme & Applikationen

System-Plattformen & Varianten

Organisations-DoD

Lieferanten, Supply Chain & Produktion

Lieferanten sind wichtige externe Stakeholder der Produktentstehung auf allen Ebenen (Organisation, Cluster und Team), sowie Supply-Chain und Produktion wichtige interne Stakeholder sind. Auf der Team-Ebene haben besonders die Modul-Teams einen engen Kontakt zu Lieferanten, da sie wichtige Randbedingungen zur Technologie geben.

Stakeholder werden zu den Reviews eingeladen um den entsprechenden Organisationseinheiten Feedback zu geben. Dies können Team-Reviews der Teams, Cluster-Reviews der Cluster oder Portfolio-Reviews sein.

Stakeholder können, zur Klärung von Anforderungen, zu Refinement-Meetings eingeladen werden. Dies können Team-Backlog-Refinements, Cluster-Backlog-Refinements oder Portfolio-Refinements sein.

.

\r\n


Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Team-Backlog-Refinement

Team-Review

.

Cluster-Backlog-Refinement

Cluster-Review

.

Portfolio-Refinement

Portfolio-Review

Team-Product-Owner

Team-System-Engineer

.

Cluster-Product-Owner

Cluster-System-Engineer

.

Portfolio-Owner

Portfolio-Architekt

Working-Team

Community-of-Practice

.

Team-Product-Owner-Gruppe

Team-System-Engineer-Gruppe

Managementkreis des Clusters

.

Cluster-Product-Owner-Gruppe

Cluster-System-Engineer-Gruppe

Managementkreis der Organisation

Team-Backlog

Inspizierbare-Ergebnisse

Team-DoD

.

Cluster-Backlog

Nutzbares-Wissen & System-Inkrement

Cluster-DoD

.

Portfolio-Backlog

Systeme & Applikationen

System-Plattformen & Varianten

Organisations-DoD

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-Review

.

Cluster-Backlog-Refinement

Cluster-Review

.

Portfolio-Refinement

Portfolio-Review

Team-Product-Owner

Team-System-Engineer

.

Cluster-Product-Owner

Cluster-System-Engineer

.

Portfolio-Owner

Portfolio-Architekt

Working-Team

Community-of-Practice

.

Team-Product-Owner-Gruppe

Team-System-Engineer-Gruppe

Managementkreis des Clusters

.

Cluster-Product-Owner-Gruppe

Cluster-System-Engineer-Gruppe

Managementkreis der Organisation

Team-Backlog

Inspizierbare-Ergebnisse

Team-DoD

.

Cluster-Backlog

Nutzbares-Wissen & System-Inkrement

Cluster-DoD

.

Portfolio-Backlog

Systeme & Applikationen

System-Plattformen & Varianten

Organisations-DoD

Das Team und die Team-Ebene

Das Team ist das Basiselement einer agil arbeitenden Organisation und bildet die Heimat von Mitarbeitern.

Die meisten Arbeiten finden in stabilen und langlebigen Teams statt. Durch die Stabilität bzw. „Langlebigkeit“ sind die Teams bei Problemen auch dann verfügbar, wenn momentan gerade nicht an einer Überarbeitung der Applikation/Systemvariante gearbeitet wird (also, wenn klassisch aufgestellte Projekt-Teams nicht mehr bestehen).

P4 übernimmt die Grundstruktur eines Teams aus Scrum. Es besteht aus Team-Product-Owner, Team-Scrum-Master und dem Working-Team, die zusammen für die Stakeholder arbeiten. Durch das Prinzip der Gewaltenteilung ergeben sich klar umrissene Verantwortungsbereiche, die sich im Team ergänzen.

Der Team-Product-Owner ist dafür verantwortlich, den Wert des Produktes zu maximieren, der aus der Arbeit des Working-Teams entsteht. Wie dies geschieht, kann je nach Organisation, und Working-Team, sowie den darin arbeitenden Experten, stark variieren. Der Team Product-Owner ist die einzige Person, die für das Management des Team-Backlogs verantwortlich ist.

Das Working-Team  besteht aus drei bis neun Mitgliedern und dem System-Engineer, die in jeder Iteration fertige und inspizierbare Ergebnisse erarbeiten und am Ende der Iteration im Team-Review vorstellen, idealerweise ein potenziell auslieferbares System oder Teilsystem.

Der Team-Scrum-Master ist ein „Servant-Manager“ und ist dafür verantwortlich, die Team-Arbeit entsprechend den Scrum- und P4-Regeln zu fördern und zu unterstützen, indem sie allen Beteiligten helfen, die Werte und  Praktiken zu verstehen.

Weiterlesen