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 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:
| Events | Rollen | Gruppen | Artefakte |
| Cluster-Planning | Cluster-Product-Owner
. |
Team-Product-Owner-Gruppe
. |
Inspizierbare-Ergebnisse
. Nutzbares-Wissen & System-Inkrement . |
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 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:
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:
| Events | Rollen | Gruppen | Artefakte |
| Cluster-Planning | Cluster-Product-Owner
. |
Team-Product-Owner-Gruppe
. |
Inspizierbare-Ergebnisse
. Nutzbares-Wissen & System-Inkrement . |
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:
| Events | Rollen | Gruppen | Artefakte |
| Cluster-Planning | Cluster-Product-Owner
. |
Team-Product-Owner-Gruppe
. |
Inspizierbare-Ergebnisse
. Nutzbares-Wissen & System-Inkrement . |
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 . |
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
Für jedes Produkt oder System lassen sich an diesen die unterschiedlichen Stakeholder (=Intressengruppen) identifizieren.
Im P4-Framework werden drei Gruppen von Stakeholder unterschieden, die den drei Bereichen zugeordnet werden
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-Product-Owner
. |
Team-Product-Owner-Gruppe
. |
Inspizierbare-Ergebnisse
. Nutzbares-Wissen & System-Inkrement . |
Qualitätsattribute sind nicht-funktionale Anforderungen, die die Funktionen und Features eines Systems mehr oder weniger einschränken. Dabei handelt es sich meist um Wie-Fragen, also: wie schnell, wie groß, wie schwer, wie teuer, wie lange haltbar, wie robust, wie sicher? Diese Anforderungen müssen häufig gegeneinander ausbalancieren werden. Dazu werden häufig minimal zu erreichende und Wunschwerte angegeben. P4 verlangt außerdem, dass diese in eine eindeutige Reihenfolge gebracht werden (in Form eines QA/C-Backlogs), um bei Konflikten leichter entscheiden zu können.
Constraints sind Einschränkungen, die eingehalten werden müssen. Sie entsprechen Qualitätsattributen, die nur einen Minimalwert haben. Die Quellen von Constraints sind häufig regulatorische oder gesetzliche Anforderungen, sowie Normen und Standards. Durch deren stark einschränkende Wirkung stehen die Constraints im QA/C-Backlog meist an oberster Stelle.
(siehe auch FURPS und ISO/IEC 9126)
.
\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 . |
„Das Backlog ist die einzige Quelle der Arbeiten.“ Die allgemeine Beschreibung eines Backlogs und seiner Eigenschaften ist hier zu finden.
Backlog-Einträge bzw. Backlog-Items sind die Einzelbausteine von Backlogs. Sie werden innerhalb der Backlogs eindeutig nach Rang geordnet, also eindeutig priorisiert. Je weiter oben ein Backlog-Eintrag steht, desto wichtiger ist er und desto früher wird er bearbeitet.
Alle Backlog-Einträge haben folgende Eigenschaften und Attribute:
In der Software-Entwicklung hat sich das Spezifizieren von Backlog-Items im Format von User-Stories etabliert. Hierbei wird eine Benutzer-Anforderung in Form eines Satzes beschrieben (Wer möchte Was, Warum). P4 bevorzugt hier den Begriff der Stakeholder-Story, da die Benutzer des Systems nur einen Teil der Anforderer darstellen.
Zur weiteren Ausarbeitung werden häufig Use-Cases genutzt, die in verschiedene Szenarien aufgeteilt werden können.
Mittels Prosa-Anforderungen können einzelne Komponenten, Schnittstelle und deren Fähigkeiten und Eigenschaften beschrieben werden.
Zur Bearbeitung einer Story durch ein Team, muss diese so klein sein, dass sie in eine Iteration passt. Größere Stories sind per Definition Epics, wobei Epics wiederum in mehrere Stories geteilt werden müssen.
Jede Backlog-Item-Ebene stellt in der Summe ihrer Einträge, den Gesamtaufwand der Produktentwicklung bzw. einer auslieferbaren System-, Markt- oder Applikationsvariante dar.
Dies ist auch die Idee von Epics, Stories und Tasks, die viele Teams bei der Verwendung von Scrum nutzen. Die Summe des Aufwands in allen Epics entspricht der Summe des Aufwands in allen Stories. Dies basiert auf der (theoretischen) Annahme, dass eine Story fertig ist, wenn alle Tasks fertig sind und ein Epic fertig ist, wenn alle enthaltenen Stories fertig sind. Genauso verhält es sich mit dem Gesamtaufwand.
Wenn ein Applikationsteam oder die Cluster-System-Engineer-Gruppe in der Lage ist, alle Backlog-Einträge auf Basis der System-Anforderungen & Funktionen mit den limitiernden Quality Attributes & Constraints, zu schätzen, ist der Gesamtaufwand einer Applikation komplett geschätzt. Da dies meist nicht einfach möglich ist, müssen die Anforderungen weiter auf die Lösungsebene der Systemkonzepte, Architektur und Fähigkeiten herunter gebrochen werden. Auch auf dieser Ebene wird es meist nicht möglich sein, alle Konzeptelemente genau genug zu schätzen, da noch viele Unbekannte und Unsicherheiten (in P4: Wissenslücken) bezüglich der Machbarkeit und der Art der Umsetzung bestehen.
Das Konzept der Wissenslücken basiert auf der Annahme, dass nach dem Schließen aller Wissenslücken die Produktentwicklung erfolgreich beendet ist. Die Summe der Aufwände zum Schließen aller Wissenslücken entspricht also ebenfalls dem Gesamtaufwand der Produktentwicklung. Die Schätzung auf dieser Ebene möglich zu machen erfordert allerdings eine gewisse Zeit, bis die Organisation gelernt hat, dies mit einer genügenden Genauigkeit zu tun.
Normalerweise schätzen Organisationen ihre Aufwände auf Basis der Samples & Integrations, da hierbei die Aufwände zum Schließen der Wissenslücken, deren Randbedingungen und Annahmen wesentlich konkreter definiert sind und die Backlog-Einträge bis auf die Ebene der aufzubauenden Simulationen, Muster und Prototypen verfeinert sind. Wichtig hierbei ist, dass das inkrementelle und ggf. mehrfache Erzeugen und Integrieren von Mustern ausreichend berücksichtigt wird und je nach Innovationsgrad und dem Risikograd der Wissenslücken, mehrere „Prove-of-concepts“ bzw. Wegwerfprototypen nötig werden können.
Ein noch weiteres Herunterbrechen ist auf der Arbeitsebene dann nötig, wenn Samples & Integrations von mehreren Teams realisiert werden. Hierfür werden die Backlog-Einträge gemäß der beteiligten Teams in Team-Ziele aufgeteilt und jedes Team schätzt die bei ihm anfallenden Aufwände. Diese können retrospektiv tatsächlichen Aufwänden zugeordnet werden und damit die relativen Schätzungen normiert oder geeicht werden.
Auf jeder Ebene der Backlog-Typen wird die Produktentwicklung also komplett beschrieben und geschätzt. Bei Nutzung von relativen Punkten zur Abschätzung, wird also auf jeder Ebene eine eigene „Währung“ verwendet. Die Währungen können ineinander umgerechnet werden, wenn nach einiger Zeit Daten vorliegen, die aufzeigen, welche Arbeitsgeschwindigkeit die Organisation auf den verschiedenen Ebenen entwickelt (Velocity).
.
\r\n
Passende und weiterführende Artikel:
| Events | Rollen | Gruppen | Artefakte |
| Team-Planning
. . |
Team-Product-Owner
. . |
Working-Team
. . |
Team-Backlog
. . |