Gibt es eine Anleitung für agiles Refactoring innerhalb eines großen Wasserfallprojekts?

Ich agiere als Projektunterstützung für ein großes multinationales Unternehmen, das Agile gerne annehmen möchte – obwohl es eigentlich nur Scrum ist, auf das sie sich beziehen.

Die ERP-Migration ist ein traditioneller Wasserfall, aber sie möchten Agile verwenden, wahrscheinlich für das Refactoring.

Können Sie Fallstudien, Whitepaper oder Best Practices für Agile innerhalb von Waterfall empfehlen?

Agilität ist kein Framework, sondern eine Reihe von Prinzipien. Einzelheiten finden Sie unter agilemanifesto.org . In der Zwischenzeit ist Ihre gepostete Frage zu allgemein und wird wahrscheinlich ohne Bearbeitung geschlossen. Bitte verbessern Sie es, indem Sie einige konkrete Details über Ihre Situation hinzufügen, was Sie erreichen möchten und was Sie bereits versucht haben.
Können Sie klarstellen, was Sie mit "sie wollen, dass Agile verwendet wird, wahrscheinlich für das Refactoring" meinen? Ich wusste nicht, dass Refactoring speziell auf Agile beschränkt ist.
Agile innerhalb des Wasserfalls funktioniert nicht. Es ist, als würde man versuchen, eine Orange in eine Kartoffel zu stecken. Es passt nicht, funktioniert nicht und macht keinen Sinn.
Ich habe das Mantra „Agile ist kein Framework, es ist eine Reihe von Prinzipien“ schon einmal gehört. Agile wird jedoch weithin als Framework bezeichnet, das jetzt die Wikipedia-Seite umfasst. Ich denke nicht, dass vorschreibende Etiketten "es ist kein Framework" hilfreich sind.

Antworten (1)

Ihre Frage könnte am besten wie folgt formuliert werden: "Ist es möglich, die Scrum-Methodik innerhalb einer multinationalen Wasserfall-ERP-Migration zu implementieren?"

Meine Antwort auf diese Frage wäre ein klares Ja, basierend auf unserer Erfahrung in der Leitung von Projekten, in denen wir genau das getan haben (sowohl bevor die Prinzipien, aus denen Agile besteht, kanonisiert wurden, als auch danach). Der Schlüssel liegt darin, Scrum funktional und nicht wörtlich zu betrachten und die Konzepte auf ein Verständnis von Folgendem zu übertragen:

  • was Sie versuchen, in jedem "Zeitabschnitt" des Wasserfallprojekts zu erreichen;
  • wer sind die Kunden für diesen Zeitabschnitt; und
  • welche Arbeitselemente in diesem Zeitabschnitt iteriert werden können oder sollten.

In diesem Fall entspricht "Zeitscheibe" dem Zeitraum, der einem Sprint für Ihr Projekt am nächsten kommt. Ich versuche, das Wort Sprint zu vermeiden, da es im Wasserfall-Kontext gegensätzlich klingt .

Siehe http://www.ibm.com/developerworks/websphere/techjournal/0907_hines/09d07_hines.html und http://www.slideshare.net/srayhan/scrum-at-a-waterfall-organization . Beide stammen aus einer Google-Suche, und ich habe sie nur gescannt, um zu sehen, ob die Projekte und Ergebnisse mit dieser Diskussion zusammenhängen. Ich würde vorschlagen, keinen Links zu folgen, die auf den Weg von Agile vs. Waterfall führen; sie werden in diesem Fall wahrscheinlich ablenken.

Wenn Sie einige Ihrer für die nächsten Monate geplanten Projektaktivitäten mitteilen möchten, kann ich (und vielleicht andere) genauer sein. Es gibt keinen Grund, die Diskussion auf Refactoring zu beschränken, und Sie würden auch nicht den größten Nutzen daraus ziehen.

Michael - sehr geschätzt. Ich werde in naher Zukunft mit einigen Projektdetails zurückkehren.