Wie man einen Zeitplan von Waterfall zu Agile in der Softwareentwicklung erstellt

Planen Sie das Minimum Viable Product (MVP) und die Meilensteine ​​der Geschäftsziele

Identifizieren Sie das Minimum Viable Product (MVP), das Sie für die Endbenutzer (oder eine Untergruppe von Endbenutzern) bereitstellen können, das geschäftlich sinnvoll ist. Wenn Sie mit dem Team zusammenarbeiten, können Sie eine Prognose (keine Zusage) darüber erhalten, wann dies erreicht werden kann. Nehmen wir an, dass dies 6 Monate dauern wird.

Denken Sie jedoch daran, dass Ihr Team keine Erfahrung mit agiler Entwicklung hat. Sie müssen dies also sehr konservativ prognostizieren. Meine Empfehlung ist, dass Sie ein Team bilden und mindestens 3 Sprints laufen sollten, bevor Sie eine vernünftige Vorstellung von der Geschwindigkeit bekommen, die für Prognosen verwendet werden kann.

Identifizieren Sie von dort aus die Meilensteine ​​​​des Geschäftsziels, die Sie erreichen möchten, bis Sie Ihre Version 1.0 der Software erreichen. Das kann zum Beispiel ein Quartalsziel sein.

Diese Geschäftsziele sind das, was Sie aus einer hochrangigen Managementperspektive planen, nicht funktionale Phasen.

Denken Sie jedoch daran, dass Sie Dinge über das Produkt von Stakeholdern lernen werden, die sich den Arbeitscode am Ende jedes Sprints ansehen, sowie von Endbenutzer-Feedback, nachdem Sie das MVP eingeführt haben. Auch das Entwicklungsteam wird mehr über die Technologie erfahren, je mehr sie daran arbeiten. Und bereiten Sie sich auf der Grundlage all dieses Feedbacks darauf vor, Ihre Geschäftsziele zu überarbeiten. Wenn Sie das Ende dieser zwei Jahre erreichen, sieht die Version 1.0 möglicherweise ganz anders aus, als Sie sie sich heute vorstellen. Aber es ist garantiert viel besser für den Zweck geeignet.

Sie nicht ist die einfache Antwort. Es gibt keine Phasen. Es wird bereits davon ausgegangen, dass das Projekt zwei Jahre dauert. Das ist falsch, Sie sollten nur anerkennen, dass Sie 2 Jahre Budget haben, um ein Projekt zu finanzieren.

Agile Scrum-Teams planen 5 Dinge: Standups, Planungen, Reviews, Retrospektiven und Iterationen. Sie könnten ein Scrum-Team mit 2-wöchigen Iterationen so planen, dass es über 2 Jahre etwa 50 Iterationen hat.

Realistischerweise ist Ihnen der Projektzeitplan unbekannt. Finanzieren Sie das Team, das an dem Projekt arbeiten wird. Angenommen, es handelt sich um ein Scrum-Team, ist der Product Owner, der direkt mit dem Kunden zusammenarbeitet, dafür verantwortlich, das Product Backlog zu generieren und zu priorisieren. Das Ergebnis ist eine anfängliche Produkt-Roadmap, die festlegt, in welcher Reihenfolge wertvolle Geschäftsfunktionen iterativ an den Kunden geliefert werden. Die anfängliche Roadmap sagt Ihnen nichts über die Dauer des Projekts.

Wie in einem anderen Beitrag erwähnt, finanzieren Sie den Betrieb des Teams für etwa 3 Iterationen, um eine anfängliche Geschwindigkeit zu erreichen. Mithilfe der Teamgeschwindigkeit ist es möglich, eine sehr grobe Prognose der Projektdauer zu erstellen, vorausgesetzt, der Rückstand ist vollständig abgebaut und alle Elemente sind grob geschätzt. Wenn in diesem Fall die Prognose +/- 6 Monate des 2-Jahres-Budgets beträgt, ist das ziemlich gesund. Wenn nicht, ist dies Ihr erster Hinweis darauf, dass es an der Zeit ist, mit Erwartungsmanagement oder Risikominderung zu beginnen. An diesem Punkt lernen agile Stakeholder auch, dass „Zeitpläne“ für agile Projekte lebendige Dokumente sind, die sich häufig ändern sollten.

Das ist also der "Zeitplan" des Projekts. Es sollte nun die Reihenfolge und das ungefähre Timing kommunizieren, in dem das Team glaubt, dass es einen Mehrwert liefern kann.

Dieser agile „Zeitplan“ ist keine Verpflichtung. Es handelt sich um eine Prognose, und der Kunde/Stakeholder sollte die Annahmen und Schwankungen in der Prognose verstehen.

Das Konzept eines Wasserfall-Projektzeitplans ist vorbei, da es unrealistisch ist zu glauben, dass ein 2-Jahres-Plan wie geplant in zwei Jahren verwirklicht wird.

Iterative Lieferung, kleinere Feedbackschleifen und der Aufbau von Kundenvertrauen ersetzen den Projektplan in wirklich agilen Teams.

„Aber halt! Meine zwei Jahre basieren auf einer festen Umfangs-/Budgetvereinbarung mit dem Kunden!“ Es ist an der Zeit, das Risiko zu erkennen, dass der Rest Ihrer Organisation immer noch in einer Wasserfall-Denkweise arbeitet und die Reibung zwischen den beiden Methoden wahrscheinlich zu mittelmäßigen Ergebnissen führt.

Damit agile Methoden wie Scrum den größtmöglichen Nutzen bringen, müssen sie in der gesamten Organisation übernommen werden, nicht nur auf der Ebene des Bereitstellungsteams.