Artefakte

Portfolio-Backlog-Item (PFBI)

Portfolio-Backlog-Items (PFBI) sind die einzelnen Elemente (Backlog-Items) des Portfolio-Backlogs und beschreiben Arbeiten für die ganze Organisation. Von der Größe her ist ein PFB zu Beginn nicht beschränkt. Es muss aber vor der Einplanung im Portfolio-Planning, d.h. vor dem Ziehen in das Portfolio-Cycle-Backlog, in mehrere, in einem Portfolio-Cycle leistbare Einzelelemente, aufgeteilt werden. Dies geschieht normalerweise in…

Portfolio-Backlog, Portfolio-Cycle-Backlog und Portfolio-Kanban

Die oberste Ebene der Backlogs des P4-Frameworks, die Portfolio- und Organisationsebene, beschreibt alle zu entwickelden Applikationen und Marktvarianten der Systeme und Produkte der gesamten Organisation. Jede dieser Varianten wird durch einen Satz von System-Anforderungen (Feature Set) beschrieben. Auf diese Weise sind die zu entwickelnden Applikationen, Systeme und Produkte (= Portfolio-Backlog-Elemente) sowohl bezüglich des Nutzens, als…

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…

Produktvision / Business Case

Die Produktvision beschreibt in kompakter Form … den bestimmungsgemäßen Gebrauch, für welche Anwender/Nutzer, in welchen Märkten das Produkt bestimmt ist, welche die grundlegenden Anforderungen und Normen sind, welche Hauptfunktionen das Produkt erfüllt, wie sich das Produkt in Anwendungskontext einfügt und welche Schnittstellen es zu umgebenden Systemen besitzt. Dazu gibt es verschiedene Arten von Vorlagen, die…

Qualitätsattribute & Einschränkungen

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…

Risikoeinfluss von K-Gaps und Entscheidungen

In jeder Produktentwicklung gibt es Design-Entscheidungen, die das ganze Konzept zum Fliegen bringen oder es unmöglich machen. Diese haben naturgemäß den größten (Risiko-)Einfluß und sollten damit auch zuerst getroffen werden. Der Entscheidungsbaum oder „Decision Tree“ beantwortet die Frage nach der Wichtigkeit und des Einflusses von Knowledge-Gaps, und damit die der Reihenfolge der Bearbeitung und Lösung…

Samples & Integrations (Backlog-Elementtyp)

Samples & Integrations repräsentieren alle Arbeiten, die für Aufbauten (egal, ob virtuell oder physisch), die Integration und die 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…

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…