Artefakte
Samples & Integrations (Backlog-Elementtyp)
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…
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…
Stakeholder-Story
Die Stakeholder-Story stellt im P4-Framework die Erweiterung der User-Story auf alle Stakeholder dar. Damit können und sollen Bedürfnisse und Anforderungen aller Stakeholder an das Produkt formuliert werden. Diese sind viel mehr als nur die Nutzer, gerade im Umfeld der physischen Produktentwicklung. Stakeholder-Stories lassen sich ebenfalls in der Organisations- und Prozessentwicklung einsetzen, also z.B. wenn es…
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…
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 meist von den Applikationsteams des Clustes erzeugt d.h. durch die Integration von Teilergebnissen der verschiedenen Teams eines Clusters (Modul- und Plattformteams, sowie Feature-Teams). Für das System-Inkrement hat P4 die Arten und Definitionen von…
Systemkonzepte und -fähigkeiten, Lösungsoptionen
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…
TAPIR Decision Guideline – Leitfaden zur Entscheidungsfindung
Die „TAPIR Decision Guideline“ ist ein effektiver Leitfaden zur Entscheidungsfindung in einer Gruppe oder einem Team. Die hier beschriebenen Schritte sollten strukturiert in den genannten Reihenfolge von einem Moderator durchgeführt werden (z.B. einem Servant-Manager oder Scrum-Master). Triage & Time: Eine schnelle Einschätzung der Kritikalität und der Entscheidungszeit. Fragen: Wieviel Zeit haben wir für eine gründliche…
Team-Backlog-Item (TBI)
Team-Backlog-Items (TBI) sind die einzelnen Elemente (Backlog-Items) eines Team-Backlogs und beschreiben Arbeiten für ein einzelnes Team. Von der Größe her ist ein TBI zu Beginn nicht beschränkt. Es muss aber vor der Einplanung im Team-Planning, d.h. vor dem Ziehen in das Team-Iterations-Backlog, in mehrere, in einer einzelnen Iterationen leistbare Einzelelemente, aufgeteilt werden. Dies geschieht normalerweise…
Team-Backlog
Team-Backlog Jedes Team hat für seinen Verantwortungsbereich und seine Aufgaben genau ein Backlog. Die darin enthaltenen Elemente (Team-Backlog-Items) bestehen in der feinsten Granularitätsstufe aus Team-Zielen für das Team. Das Team-Backlog wird vom Team-Product-Owner verantwortet und priorisiert. Ein großer Teil des Team-Backlogs wird durch die Team-Product-Owner-Gruppe und die Team-System-Engineer-Gruppe aus dem Cluster-Backlog, bzw. den System-Backlogs durch Verfeinerung…