So gelangen Sie zu einem Projektplan für die Migration einer Legacy-Webanwendung zu einer ReactJS-basierten Anwendung

Ich muss einen Projektplan für die Migration einer Legacy-Webanwendung zu einer ReactJS-basierten Anwendung erstellen.

Die alte Webanwendung ist in Vanilla JS, HTML, CSS geschrieben und es gibt ungefähr 4000 HTML-Dateien mit NodeJS als Backend (also eine ziemlich große Anwendung).

Die Migration einer so großen Anwendung auf einen neuen Technologie-Stack erfordert eine gewisse Planung, um Engpässe zu einem späteren Zeitpunkt in der Projektausführungsphase zu vermeiden.

Einige Herausforderungen bei dieser Migration werden auch darin bestehen, die Stakeholder von den Vorteilen der Migration zu überzeugen + es wird auch eine Lernkurve für das technische (Entwickler-) Personal geben.

Da der Migrationsaufwand möglicherweise einige Zeit in Anspruch nimmt, müssen wir in der Zwischenzeit auch die vorhandene Legacy-Anwendung weiter unterstützen. Daher muss die Agilität für die vorhandene Anwendung parallel zu den neuen Migrationsbemühungen fortgesetzt werden.

Alle Ideen / Referenzen / Einblicke hier werden bei der Planung eines so komplexen Projekts sehr geschätzt.

Was ich schon recherchiert habe:

  • Bei Google gesucht (aber keine passende Anleitung für ein Migrationsprojekt gefunden). Alle Referenzen weisen auf eine neue Projektplanung hin, die auf eine „from-the-scratch“-Entwicklung abzielt.
Wenn Sie die Vorteile noch nicht kennen, ist es möglich, dass es nicht genug gibt und die Entwickler es einfach wollen, weil „Reagieren ist das, was jetzt programmiert werden muss“. Wenn Sie eine Website betreiben, die in der Google-Suche erscheinen muss, gibt es eine Gottveränderung, bei der niemand ausreichend informiert ist, um dies sicher zu tun
@NewAlexandria das ist hier nicht der Fall. Wir (Engineering- und Produktteams) sind uns der Vorteile der Migration bewusst. Die Herausforderung besteht darin, das Projekt gut organisiert zu planen.

Antworten (4)

Da der Migrationsaufwand möglicherweise einige Zeit in Anspruch nimmt, müssen wir in der Zwischenzeit auch die vorhandene Legacy-Anwendung weiter unterstützen.

Ich entnehme dieser Aussage, dass die Neuentwicklung parallel zur bestehenden Anwendung erfolgen wird, anstatt einzelne Komponenten zu ersetzen. Meine Antwort wird dies widerspiegeln.

Verwenden Sie das, was Sie jetzt haben, als Leitfaden

Das vorhandene System kann analysiert werden, um eine Funktionsliste für die neue Anwendung zu erstellen. Es ist auch nützlich, über den relativen Wert der Funktionen im bestehenden System nachzudenken. Was ist zum Beispiel das wichtigste Merkmal? Welche Features sind nice to have und die Nutzer könnten (vielleicht nur vorübergehend) darauf verzichten?

Verwandeln Sie diese Analyse nun in einen priorisierten Arbeitsrückstand. Die wichtigsten obligatorischen Features werden ganz oben im Backlog stehen.

Zweitens sollten Sie erwägen, eine Reihe von (idealerweise automatisierten) Regressionstests für die wichtigsten Merkmale zu erstellen. Diese Tests können gegen das vorhandene System ausgeführt werden und zeigen, dass sie funktionieren. Die Tests sollen auf der UI-Ebene ausgeführt werden und können daher gegen das Altsystem oder das Ersatzsystem ausgeführt werden.

Diese Regressionstests helfen dem Entwicklungsteam, zuversichtlich zu arbeiten, während es die Lernkurve der neuen Technologie fortschreitet.

Bauen Sie die Unterstützung der Stakeholder auf, indem Sie schrittweise liefern

Die Stakeholder werden oft nervös, wenn die neue Entwicklung Ressourcen verschlingt, ohne Ergebnisse zu zeigen. Da Sie eine priorisierte Liste von Funktionen haben, versuchen Sie, funktionierende Software in regelmäßigen Schritten bereitzustellen . Beispielsweise enthält die erste Arbeitsversion möglicherweise nur die 5 wichtigsten Funktionen der Anwendung.

Arbeiten Sie mit nur einem Rückstand

Es ist eine gute Idee, die Arbeit an der neuen Anwendung mit allen Arbeiten zu kombinieren, die erforderlich sind, um das vorhandene Legacy-System zu warten.

Haben Sie nur einen Rückstand und priorisieren Sie Wartungsaufgaben neben neuen Entwicklungselementen. Es kann sein, dass einige Wartungsaufgaben nicht so dringend sind und gegenüber neuen Entwicklungsaufgaben priorisiert werden können. So könnte Ihr Rückstand aussehen:

Legacy-Fehler Nr. 7 behoben

Erstellen Sie einen Quartalsbericht aus dem Altsystem

Funktion Nr. 2 auf neuem System

Funktion Nr. 8 auf neuem System

Legacy-Fehler Nr. 12 behoben

Ziehen Sie eine gestaffelte Umstellung in Betracht

Versuchen Sie nach Möglichkeit, eine Umstellung im Big-Bang- Stil auf das neue System zu vermeiden. Können Sie die neue Anwendung parallel zum Altsystem betreiben? Könnte es als Betaversion mit einer Teilmenge Ihrer Benutzer ausgeführt werden?

Wenn Sie die neue Anwendung inkrementell bereitstellen und parallel ausführen, können Sie das mit der Umstellung verbundene Risiko erheblich reduzieren.

Ein paar Dinge zu beachten:

Organisieren Sie nach Fähigkeiten, nicht nach Features

X-Benutzer können Y tun. Mit diesem Ansatz können Sie Benutzeranforderungen schnell erfüllen und validieren. Dies ist auch eine großartige Möglichkeit, die Benutzererfahrung zu verbessern, ohne zusätzliche Kosten zu verursachen. Es wird Ihnen auch helfen, die Neuerstellung von Dingen zu vermeiden, die nicht verwendet werden.

Planen Sie um Benutzersegmente herum

Es ist schwierig für Benutzer, weiterhin zwei Systeme zu verwenden. Wenn Sie sich auf Benutzersegmente konzentrieren, können Sie einige Benutzer früher im Projekt kürzen. Das kommt bei den Beteiligten super an!

Priorisieren

"Lass es alles tun, was der letzte getan hat." Ist die häufigste und nutzloseste Phrase in diesen Projekten. Wenn ich in der Vergangenheit an diesen Projekten gearbeitet habe, hat es sich manchmal sogar gelohnt, eine Protokollierung aufzubauen, um zu sehen, welche Funktionen tatsächlich verwendet werden.

Wir planen etwas Ähnliches in meiner Organisation.

Schritt 1 besteht darin, Ihre gesamte Geschäftslogik von Ihrer Schnittstellen-/Anzeigelogik zu trennen. Sie können dies in Ihrer aktuellen Anwendung tun, bevor Sie mit der neuen beginnen. Diese Vorgehensweise hat einige Vorteile:

  1. Es ist sowieso eine gute Idee. Auch wenn Sie nicht mit dem größeren Projekt fortfahren, profitieren Sie vom Refactoring.
  2. Wenn Sie das neue Projekt starten, teilen Sie einen großen Teil des Codes zwischen der aktuellen und der neuen Codebasis, was die parallele Entwicklung erleichtert.
  3. Dadurch wird die Zeit verkürzt, in der Sie zwei Anwendungen pflegen müssen.

Schritt 2 besteht darin, einen eigenständigen Abschnitt Ihrer Anwendung für die Migration auszuwählen. Wir haben den Administratorbereich unserer Anwendung ausgewählt, da er keine gemeinsamen Bildschirme oder Funktionen mit dem Rest der Anwendung teilt. Sobald Sie einen kleinen Teil Ihrer Anwendung erfolgreich migriert haben, können Sie den Code für die alte Version löschen und die nächste zu migrierende Sache auswählen.

Ich habe einige Erfahrung mit Migrationen . Was ich vorschlagen kann ist folgendes.

Erstellen Sie ZUERST und allererst einen produktorientierten Projektstrukturplan. Tun Sie dies nicht alleine, tun Sie es mit der Unterstützung des Teams.

Über den PSP würde ich in der ersten Ebene meines PSP Folgendes eingeben:

  • Website: So können Sie die bereitzustellenden Funktionen weiter zerlegen (Frontend, Backoffice, Backend usw.)
  • Governance: Meine Anwendungen können sich auf Ihre Governance auswirken, Sie müssen diese wahrscheinlich aktualisieren und die neuen Governance- und Geschäftsprozesse bereitstellen
  • Berichterstattung: Da Sie möglicherweise Auswirkungen auf die Datenschicht haben oder neue Berichtsanforderungen auftreten können
  • Lernzyklus: Wenn neue Fähigkeiten/Fähigkeiten benötigt werden, müssen Sie wahrscheinlich einige Schulungen und Coachings organisieren

ZWEITENS: Erstellen Sie Ihre Planung Unabhängig davon, ob Ihr Projekt agil ist oder nicht, befolge ich die folgenden Schritte, um meine Planungen zu erstellen:

  • Verwenden Sie den Projektstrukturplan , den Sie gerade erstellt haben, um den Zeitplan zu skizzieren

  • Fragen Sie Ihr Team, was getan werden muss, um das zu liefern, was im Projektstrukturplan steht

  • Identifizieren Sie mit Ihrem Team, in welcher Reihenfolge sie die Aktivitäten vorschlagen

  • Erfahren Sie, was das Team braucht, um an den Aufgaben zu arbeiten und das zu liefern, was in Ihrem Aufgabenbereich liegt

  • Holen Sie sich erste Einschätzungen zu Aufwand und Dauer ein

  • Konsolidieren Sie alle Informationen im Projektmanagement-Tool, mit dem Sie den Projektplan verwalten

Näheres dazu erfahren Sie in meinem Beitrag „ So erstellen Sie einen Projektplan , in dem Sie auch Informationen zur Erstellung eines produktorientierten PSP finden.

Ich hoffe das hilft dir.

Tschüss, Falke