Verwenden von Scrum für die Migration von Kunden auf bereits aktive Produkte

Lohnt es sich, bei einem Client-Migrationsprojekt von einem Legacy-System zu einem bereits live geschalteten System und mit anderen Clients (einer White-Label-Software) in 2-Wochen-Sprints zu arbeiten, und zwar im Scrum-Stil?

Es scheint mir etwas vergeblich zu versuchen, Aufgaben in 2-Wochen-Sprints unterzubringen, da sich niemand beschweren wird, ob sie geliefert werden oder nicht (da der Client bereits mit einer Legacy-Software live ist). Die einzige Auswirkung besteht darin, das Migrationsdatum (das von einem Projektmanager festgelegt wurde) auf ein früheres oder späteres Datum zu verschieben, das alle 2 Wochen überprüft wird.

Ich denke, ein Kanban-Stil ist angemessener, da die Arbeitsbelastung bekannt ist (keine Überraschungen oder zu erkundende Bereiche) und es so lange dauern wird, bis die Software geliefert wird. Es gibt keine zusätzliche Funktionalität, wie es bei inkrementellen Releases in Scrum der Fall wäre, da sich der Client immer noch auf dem Legacy-System befindet. Kann jemand Gründe für oder gegen die Verwendung von Scrum für die Migration von Kunden von Legacy-Produkten zu neuen Live-Produkten nennen?

Hochgestimmt. Sehr interessante Frage.
In einer Welt der ständigen Systemmigration bin ich überrascht, dass dieses Thema nicht genug diskutiert wurde!

Antworten (2)

Als Agile-Evangelist kann ich nicht glauben, dass ich das gleich schreibe, aber ich frage mich, ob Agile selbst wirklich für Sie benötigt wird. Aus meiner Sicht ist der Hauptzweck von Agile der Umgang mit sich ändernden Anforderungen. Wenn Sie im Voraus wissen, dass alle Ihre Anforderungen statisch sind, dann macht es ... nicht viel Sinn.

Für Scrum könnte dies sicherlich übertrieben sein. Wie würde der Product Owner Storys erstellen/priorisieren? Wie würden Sie Geschichten planen? Wie erhalten Sie am Ende jedes Sprints ein versandfähiges Produkt? Wie würden Sie Stories in jedem Sprint demonstrieren? Wem würden Sie sie vorführen? Wenn Sie nicht alle diese Fragen beantworten können, ziehen Sie die Möglichkeit in Betracht, dass Scrum unnötigen Overhead bedeutet.

Natürlich möchten Sie vielleicht trotzdem auf Kanban setzen, anstatt ganz auf Agile zu verzichten. Die Work-In-Progress-Grenzen würden auch bei sich ändernden Anforderungen noch Vorteile bringen. Wenn Ihr Team an Agile gewöhnt ist, können Sie genauso gut dabei bleiben; Kanban ist ziemlich einfach, mit sehr wenig Overhead.

Vielen Dank für Ihre Kommentare, sie sind sehr gültig. Um Ihre Fragen zu beantworten: Der PO erhält eine Übergabe von den BAs, die die Geschäftsanforderungen mit dem zu migrierenden Kunden abgesegnet haben, dh welche Elemente der Software er möchte. Dann übergeben sie an den PO, der Epics und Stories erstellt und den Rückstand festlegt. Wir haben am Ende des Sprints kein versandfähiges Produkt, wir haben lediglich eine Ergänzung, aber das Ganze ist nicht live. Wir demonstrieren den Steakholdern, dh BA und unserer internen Abteilung, die das Produkt letztendlich verwendet, immer noch Geschichten.
Außerdem erfolgt die Priorisierung auf der Grundlage von „Welche Funktionalität müssen wir aktivieren, damit die nächste Funktionalität funktioniert?“. Beispielsweise müssen Sie die API-Konnektivität aktivieren, um den Dienst dann aufzurufen. Beide existieren, sie müssen nur für jeden Client konfiguriert werden.
Der Zweck von Agile besteht darin, mit sich ändernden Umständen umzugehen – nicht nur mit sich ändernden Anforderungen. Was ist, wenn Entwickler krank sind? Was ist, wenn eine bestimmte Geschichte oder Aufgabe komplizierter wird als ursprünglich gedacht? Und selbst bei einer solchen Migration werden sich einige Annahmen und sogar Anforderungen irgendwann zwangsläufig ändern.

Es ist sicherlich sinnvoll, den Scrum-Ansatz zu verwenden.

Der Product Owner priorisiert den Rückstand basierend darauf, welche Funktionen des Systems am wertvollsten sind.

Die Lieferung würde häufig und in einem funktionierenden System erfolgen (obwohl nicht alle Funktionen bis zum Ende fertiggestellt sind).

Der Wert, den Sie daraus erhalten, ist:

  • Transparenz des Fortschritts. Wenn das Team funktionierende Funktionen liefert, gewinnt der Kunde an Vertrauen.
  • Die Möglichkeit, dem Kunden einen Zeitplan zu geben, der aktualisiert wird, um mit dem in der realen Welt erzielten Fortschritt übereinzustimmen.
  • Die Möglichkeit, kontinuierliche Tests in einer Produktionsumgebung durchzuführen (einschließlich Benutzerakzeptanztests, um sicherzustellen, dass das neue System mit dem Altsystem übereinstimmt). Helfen, das Risiko der Lieferung zu verringern, indem vermieden wird, dass das Testen bis zum Ende des Projekts verschoben wird.
  • Alle anderen Vorteile von Scrum: das selbstorganisierende Team, Retrospektiven, Kadenz etc.
  • Die Feature-Priorisierung verschiebt die am wenigsten wertvollen Features an das Ende des Projekts, wodurch es weniger kritisch wird.
Vielleicht war ich nicht klar genug: Die Kernsoftware ist live (mit anderen Clients). Der zu migrierende bestehende Client lebt nicht von dieser Software, sondern von Altlasten. Wenn das Migrationsprojekt abgeschlossen ist, wird der Kunde mit dem neuen Produkt live gehen. Bis jetzt bauen wir also Iterationen und halten sie in einer QA-Umgebung. Der Kunde sind unsere internen Teams, die es letztendlich verwenden werden. Wir demonstrieren sie nicht einmal, weil die Dinge sehr technisch sind und sie sie nicht verstehen können. Auch gibt es keine Dinge des Systems mehr/weniger wertvoll zu priorisieren, es gibt ein bekanntes MVP.
Dann müssen Sie sie auf die neue Software bringen und diese Software empirisch an ihre Bedürfnisse anpassen.
Verwenden von Scrum für die Migration von Kunden auf bereits aktive Produkte
AntwortenHierDatenschutz-Bestimmungen1y, 0v