Wie unterscheidet sich das Risikomanagement in der agilen Entwicklung vom Risikomanagement im Wasserfallmodell?

Wie andere bereits erwähnt haben, modifiziert Agile das Risikomanagement im Vergleich zu Waterfall. Zu einem gut geführten Projekt gehört auch die Betrachtung von Risiken außerhalb des Projektumfangs, und diese sollten mehr oder weniger gleich gehandhabt werden.

Es gibt Risikobereiche, die durch agile Methoden gemildert werden sollten.

• Markteinführungszeit / Planungsfehler: In einem Wasserfallprojekt kann es Monate oder Jahre dauern, bis Sie veröffentlichen. Mit Agile sollten Sie etwas haben, das alle paar Wochen veröffentlicht werden kann.
• Budgetrisiko: Wasserfallprojekte haben in der Regel ein erhebliches Budgetrisiko, da der Zeitrahmen für die Lieferung so lang ist und Schätzungen oft nicht genau sind. Während die Kosten eines agilen Projekts möglicherweise nicht besser geschätzt werden können, ist es einfacher, das Budget zu verwalten.
• Stornierungskosten: Wenn ein Wasserfallprojekt zu spät storniert wird, können ohne Produkt erhebliche Kosten anfallen. Die Wasserfallmethode kann die Feststellung, dass ein Projekt nicht praktikabel ist, erheblich verzögern. Ein abgebrochenes agiles Projekt sollte eine gewisse Funktionalität hervorbringen, wenn es längere Zeit gelaufen ist.
• Scope Creep: Wasserfallprojekte neigen dazu, auf Scope Creep-Probleme zu stoßen, wenn fehlende Anforderungen zum Projekt hinzugefügt werden, ohne andere Anforderungen zu entfernen. Agile Projekte sollten die fehlenden Anforderungen zum Backlog hinzufügen, Anforderungen mit geringerem Wert verschieben und unnötige Anforderungen streichen.
• Anforderungsfehler: Wasserfallprojekte spezifizieren die Anforderungen, lange bevor sie geliefert werden. Eine falsche Anforderung kann erhebliche Kosten verursachen, bevor sie entdeckt wird, und weitere Kosten für die Korrektur oder Entfernung der Anforderung. Agile konkretisiert die Anforderung, wenn sie implementiert wird, und bietet viel mehr Transparenz und einen kürzeren Zeitrahmen, um die Kosten zu erhöhen.
• Technologie-Risiko: Wasserfallprojekte können unbewiesene Technologie spezifizieren, und es kann mehrere Monate dauern, bis Probleme mit der Technologie entdeckt werden. Agile Projekte sollten den Zeitrahmen verkürzen, bevor Probleme bemerkt werden, und die Anpassung vereinfachen.
• Sicherheitsrisiko: Wasserfallprojekte stellen kein Produkt bereit, das bis weit in die Projekte hinein auf Sicherheit getestet werden kann. Agile Projekte produzierten alle paar Wochen testbare Produkte. Wenn Sicherheitsprobleme entdeckt werden, können diese möglicherweise frühzeitig in einem agilen Projekt angegangen werden. Bei Bedarf kann ein agiles Projekt seinen Prozess anpassen, um mit entdeckten Sicherheitsproblemen umzugehen.

EDIT: Ich habe das Risiko von vergoldeten Anforderungen übersehen. Es ist viel einfacher, ein agiles Projekt zu beenden, wenn eine ausreichende Funktionalität entwickelt wurde.

Sie haben Recht, wenn Sie sagen, dass Risikomanagement in agilen Projekten normalerweise nicht explizit angesprochen wird. Das heißt, die Prozessdesigner beabsichtigten, typische Projektrisiken durch die im Prozess skizzierten Praktiken anzugehen. Infolgedessen verwenden agile Teams traditionell keinen absichtlichen Risikomanagementansatz. Dies funktioniert für viele Teams und viele Projekte, aber ich habe festgestellt, dass das Ignorieren von Risiken eine große verpasste Chance ist und dazu neigt, die Projektkosten zu erhöhen, indem man aus Fehlern lernt. Darüber hinaus unterscheiden sich viele Projekte so weit vom „idealen“ Szenario für einen Prozess, dass es sich lohnt, dem impliziten Risikomanagement skeptisch gegenüberzustehen.

Es gibt einen großartigen Erfahrungsbericht, der auf der XP2008-Konferenz veröffentlicht wurde ( Explicit Risk Management in Agile Processes von Nelson, Taran und Hinojosa ), der den Erfolg eines Teams skizziert, das das kontinuierliche Risikomanagement-Paradigma des SEI (Software Engineering Institute) mit Extreme Programming integriert. Ein früheres XP-Team, in dem ich war, hatte ähnlichen Erfolg.

Bei der Integration von Risikomanagementpraktiken in agile Teams habe ich festgestellt, dass einige wichtige Dinge zu beachten sind (einige davon sind in dem zitierten Dokument zusammengefasst):

• Denken Sie daran, dass agile Teams demokratisch und selbstorganisierend sind. Es sollte eine ernannte „Risikomanager“-Rolle geben, aber die Verantwortung für die Identifizierung und Priorisierung von Risiken liegt beim Team. Der Risikomanager ist wirklich nur ein Ermöglicher und Vermittler.
• Halten Sie das Risikoregister öffentlich. Wikis eignen sich dafür ebenso gut wie andere Medien.
• Konzentrieren Sie sich auf Praktiken, die maximalen Wert bieten. Meiner Erfahrung nach ist die Verwendung von Multi-Voting zur Priorisierung von Risiken genauso effektiv wie die Rangfolge nach Exposition , nimmt viel weniger Zeit in Anspruch und ist eine integrative Aktivität (gut für agile Teams).
• Verwenden Sie den Mini-Small-Team-Risikobewertungs-Workshop anstelle des vollständigen Workshops des SEI. Die Mini-Version dauert einen Tag oder weniger, während die Vollversion etwa 5 Tage benötigt. Wenn Ihr Team sich mit Risikomanagement auskennt, können Sie sogar leichtere Workshops durchführen und trotzdem effektiv bleiben.

Das aktuelle Denken in der Agile-Community ist, dass Risikomanagement wichtig ist . Die meisten agilen Vordenker haben sich alle Mühe gegeben, über die Bedeutung des Risikomanagements in Bezug auf Agilität zu sprechen. Allerdings habe ich nicht viel Arbeit gesehen, die geleistet wurde, um Risikomanagement für agile Praktiker zugänglicher zu machen, und es gibt immer noch eine Fülle populärer Literatur, die das Thema völlig ignoriert.

bedeutet das, dass es während des Lebenszyklus eines agilen Projekts keine Risikoplanung gibt?

Wenn Leute sagen, dass es implizit verwaltet wird, meinen sie damit hoffentlich, dass es während des gesamten Projekts kontinuierlich verwaltet wird. Dies geschieht durch die Diskussion von Risiken bei der Sprintplanung, Retrospektiven usw. Der Scrum Master spielt auch eine wichtige Rolle bei der Beseitigung von Risiken/Hindernissen.

Um mit Scrum als Beispiel fortzufahren, es schreibt nicht explizit vor, wie Risiken gehandhabt werden. Scrum ist jedoch ein Framework und keine ausgewachsene Projektmanagement-Methodik: Sie müssen definieren, wie Sie Risiken je nach Bedarf managen. Tatsächlich ist es nicht ungewöhnlich, dass Product Owner und Teams Listen mit Risiken führen, die kontinuierlich bewertet werden.

Ich bin kein Agile-Experte – aber ich denke, zwei der Dinge, die dazu führen können, dass es so aussieht, als würde keine Risikoplanung durchgeführt, sind die Sprache und wie es in der Praxis gemacht wird.

In Bezug auf die Sprache sehe ich, dass sich die meisten agilen Praktiker und Referenzen eher auf „Hindernisse“ als auf Risiken beziehen. Eigentlich das Gleiche, aber es kann die Illusion entstehen, dass das Risikomanagement nicht durchgeführt wird, wenn in Wirklichkeit jeden Tag über Hindernisse/Risiken diskutiert wird.

Auf der Praxisseite – in einem typischen (Wasserfall-)Projektszenario werden Sie im Voraus eine Risikoplanung durchführen, hauptsächlich weil Sie ein Projekt mit längerer Dauer haben und die gesamte Spanne des Projekts auf Potenzial prüfen Risiken. Sie könnten also versuchen, Risiken zu identifizieren, die 6-8 Monate im Voraus liegen könnten. Darüber hinaus haben Sie es möglicherweise mit externen Anbietern (in der Herstellung befindliche Teile oder Lieferungen) zu tun, die eine andere Art von Risiko mit sich bringen und ein wenig später sind. Sie führen also „Risiko“-Identifikation, -Planung und -Management durch.

In einem agilen Umfeld ist diese spezielle Art des Risikomanagements aufgrund der verwendeten Prozesse nicht immer notwendig. In einem 2-4-wöchigen Sprint haben Sie einen kürzeren Zeitrahmen, auf den Sie achten müssen. Wenn Sie eine Art Scrum-Variation durchführen, haben Sie möglicherweise auch tägliche Stand-up-Meetings, bei denen Risiken täglich besprochen werden können / werden. In einem größeren Projekttyp werden diese möglicherweise nur während der wöchentlichen Statusbesprechungen überprüft/aktualisiert.