PSP und agiles Vorgehen

Nein, der WBS ist nicht veraltet, obsolet, veraltet oder nutzlos.

Der WBS ist nur eine Zerlegung dessen, WAS Sie liefern möchten.

Der Aufbau eines WBS ist keine einmalige Aufgabe, sondern ein interaktiver und iterativer Prozess .

Eine bewährte Methode im Projektmanagement ist die Erstellung eines produktorientierten WBS , den Sie später verwenden, um Ihre Planung zu strukturieren.

In meinem Artikel „ Wie erstelle ich einen produktorientierten PSP “ gehe ich diesen Prozess anhand eines Beispiels für ein Empfehlungssystem durch.

In Agile sprechen wir von User Story Map , das ist eine Ansicht der User Storys, die nach EPICs und Features organisiert sind.

Ist die User Story Map dieselbe wie die PSP?

Nein, diese Tools sind nicht dasselbe , aber sie können zusammen verwendet werden, da sie sich aus meiner Sicht ergänzen .

Aus meiner Erfahrung ist der WBS besser für die Kommunikation mit Stakeholdern außerhalb des Teams und die User Story Map mit dem Team .

Wenn Sie wissen möchten, wie Sie Ihren WBS in eine User Story Map verwandeln können, möchten Sie wahrscheinlich einen Blick in meinen Artikel „ Vom WBS zur User Story Map “ werfen .

Ich hoffe das hilft.

Gruß Falke

Ich stimme zu, dass sich die strenge Definition eines PSP und seiner Verwendung am besten für die Verwendung in den Wasserfallmethoden eignet ... jedoch können, wie oben erwähnt, einige seiner Prinzipien auf die Verwaltung des Scrum- oder Agile-Backlog-Konzepts angewendet werden. Im agilen. Sie unterteilen die Arbeit im Wesentlichen in Epics, Features, User Stories ... was eng mit Project, Deliverable, Work Package auf dem PSP übereinstimmt. Mir persönlich gefällt das Konzept, einen PSP für eine Phase der agilen Arbeit aufzubauen, um das Backlog zu erstellen. Ich treffe mich gerne im Raum und nutze die Postnotizen, um mir einen Überblick über die kommende Arbeit zu verschaffen.

Sie können die Geschäftsziele Ihrer Kunden -> auf Epics, Epics -> auf User Stories oder Features aufteilen. Und denken Sie darüber nach wie über WBS. Aber es gibt einige wichtige Dinge zu beachten:

1. Sie können früh im Projekt einen Rückstand von Epics und Features erstellen, aber es ist besser, den Rolling-Wave -Ansatz zu verwenden, wenn Sie eine detaillierte Zerlegung für die ersten 2-4 Wochen der Arbeit erstellen, halbdetailliert für die nächsten 2-4 Wochen und nur auf hoher Ebene ( Epic-Liste) für den Rest des Projekts. Und dann Detailarbeit, wenn Sie sich dem nächsten Stück Backlog nähern.
2. Epics sind keine Ergebnisse – sie können während Ihres gesamten Projekts wachsen (mit den erforderlichen Vereinfachungen anderer Epics, wenn Sie einen Festpreisvertrag abgeschlossen haben). Epics sind eher darauf ausgerichtet , einige Funktionen zu verbessern oder bestimmte Ziele zu erreichen, nicht einen bestimmten Teil der Arbeit, der abgeschlossen werden soll.
3. Funktionen sind keine Aufgaben – dh Sie sollten die Funktionalität nach geschäftlichen und nicht nach technischen Begriffen aufteilen. Hauptkriterium und Nutzen davon – Ihr Kunde sollte in der Lage sein, Funktionen selbstständig zu priorisieren.

Je nachdem, wie Sie Ihren PSP aufbauen, ist das möglich, aber traditionell werden PSPs in Aufgaben unterteilt. Dies setzt voraus, dass ich alle (oder zumindest die meisten) Arbeiten kenne, die im Voraus erledigt werden müssen. Dieser Ansatz ist unmöglich, wenn komplexe Probleme gelöst werden müssen, bei denen ich etwas arbeiten muss, um herauszufinden, welche anderen Arbeiten erledigt werden müssen. Da Scrum speziell für diese Art von Arbeit entwickelt wurde (die meisten Produktentwicklungen sind tatsächlich diese Art von Arbeit), verwendet Scrum ein emergentes Backlog.

Als ich Scrum lernte, betrachtete ich den Rückstand als eine Art PSP. Es gibt ein paar Gründe, warum dieser Vergleich ungenau ist, aber für mich hat er als Übergangsansatz funktioniert. Nur, anstatt die zu erledigende Arbeit aufzuschlüsseln, habe ich aufgeschlüsselt, was ich mit dem Produkt machen wollte.

Ich stimme mit dem überein, was [ich denke ...] Mike Rowe sagt: Die beiden Konzepte können zusammen verwendet werden, und das tun sie sehr oft.

Wenn wir zum Beispiel sagen, dass *"Sie die Arbeit im Wesentlichen in Epics aufteilen, (etc.) ...", dann gibt es denselben Ausdruck wieder, nur in einem anderen Kontext. Wir haben noch Arbeit, und wir bauen sie immer noch ab. (Aber der Umfang und die Grenzen und Ziele unserer Aufschlüsselungsbemühungen sind jetzt anders … und vielleicht „mehrfach und parallel“.)

Im Kontext dieser Projekte finde ich es immer noch wertvoll, PSP-Konzepte auf zwei verschiedenen Ebenen anzuwenden:

1. In der Anfangsphase des Projekts, wenn wir versuchen, eine übergreifende Erwartung dafür zu entwickeln oder zumindest vorherzusagen oder zu prognostizieren. Aber dann erlauben wir den selbstgesteuerten Aktivitäten des Teams, die Details zu entdecken, während das Projekt regelmäßig gegen diesen anfänglichen Zusammenbruch aufgehalten wird (und der Zusammenbruch überarbeitet wird).

2. Im Mikromaßstab kann sich das Bewusstsein für WBS-Prinzipien als effektiver erweisen, um die kurzfristigen nächsten Aktivitäten des Teams zu ordnen, als es ein „einfacher Konsens“ sein könnte.

WBS-Konzepte sind auch äußerst wertvoll bei der Bestimmung, wie die anfängliche Projektaufteilung aussehen sollte, in einem großen Aufwand, der mehrere [Scrum/Agile/What-have-you]-Teams involvieren kann. Meiner Meinung nach ist es äußerst wichtig, dass jedem Team ein gut durchdachter Umfang und Grenzen gesetzt werden und dass die erwarteten Wechselwirkungen zwischen den verschiedenen "Teamboxen" so gut verstanden werden, wie dies zu diesem Zeitpunkt vernünftigerweise möglich ist. (Und dass wir es dann von Zeit zu Zeit überarbeiten und neue Überarbeitungen veröffentlichen.)

„Traditionelle [Wasserfall] WBS“ ist sozusagen zusammengebrochen, weil wir nicht die gesamte Zukunft vorhersagen können, bevor wir beginnen. Als Antwort darauf wurden iterative Methoden (Scrum, Agile usw.) entwickelt, in der Erkenntnis, dass „wir das nicht müssen“. Aber ich würde argumentieren, dass sie sicherlich keine der guten Ideen von WBS verworfen haben. Sie haben gerade damit begonnen, sie zu unterschiedlichen Zeiten, auf unterschiedlichen Ebenen und sowohl mit kurzfristigen als auch mit langfristigen Zielen anzuwenden. Wir denken, dass wir damit das Badewasser verbessert haben, aber wir haben dabei nicht das Baby ausgeschüttet.