敏捷过程中的前端迁移

Question

在我们的组织中，我们计划将单页应用程序(带有复杂的后端)迁移到另一种前端技术(从角度到响应)。我们希望通过逐步迁移(一页一页)和频繁部署的方式，以敏捷的心态进行操作。

然而，我们在程序上遇到了一些难题，我们希望得到社区的一些建议或反馈。以下是我试图在这里总结的一些制约因素：

• UX :从一个角度的页面漫游到一个React页面会降低用户体验:而不是单一的应用程序体验(其中头和侧边栏不重新加载)，用户将页面体验为一个完整的重新加载。
• 技术上:我们可以通过将一个角度的页面封装到一个React页面中来解决这个问题，但是它会给会话管理、js/css超载带来很多风险。角度应用程序还与后端紧密耦合，迁移的目标之一是将其解耦。
• 方法:在交付前进行9个月的重新设计会给我们带来很大的风险，因为用户的反馈很少。我们热衷于频繁的交付和反馈周期，这对我们非常有效。
• 新特点:我们还必须提供新功能，以尊重我们的约定。最初，我们希望将页面迁移与新功能连接起来，并使用新功能路线图解决迁移路线图。

渐进式迁移过程在方法上是合理的，但在技术上是有风险的，并且在过渡阶段降低了UX。我们可能会考虑生活在这些限制中，但我们希望收集一些反馈。我希望这个问题也适合这个网站。你以前经历过这种情况吗？谢谢！！

Answer 1

以下是我在过去看到过的这一工作：

首先，不要把它看作是一个升降式的项目。一般来说，“迁移”项目是有问题的，因为您在迁移项目的90+%中做了两个错误的假设。

1)你知道所有需要做的工作，以及它是如何发挥作用的。你几乎从来没做过。多年来，人们一直在挤压功能，忘记了在最初的设计中所做的决定。我从未从事过一个由于“发现”复杂性而没有膨胀的迁移项目。

2)今天用户的需求与原来用户的需求是相同的。如果这是真的，就没有很好的迁移理由。许多需求将是相同或相似的，但我们总是感到惊讶的是，有多少没有。

相反，把它看作是一个新的应用程序，您有丰富的经验。寻找可以交付现有、改进和新功能的用户段或问题区域，这些功能将快速提供大量的价值。例如，也许一个会计部门必须生成一份报告，而由于法律的变化，他们需要十几项工作才能以他们需要的方式获得他们需要的信息。该团队可能会容忍登录到两个不同系统的相对较小的不便，以便他们能够更快地生成该报告。

根据我的经验，改变这种思维方式会让团队创造性地思考如何解决你提到的许多制约因素。