更换工作系统时敏捷如何工作？

在理想的敏捷世界中，您可以快速构建所需终端系统的一个小而有用的子集，并将其提供给用户。他们很兴奋，因为它很有用，他们开始使用它并提供反馈。然后，您可以计算出要添加的内容，然后进行构建，然后重复进行，直到用完时间。

我最近有几个项目，涉及更换某种工作系统。上面的模型根本不起作用：在您构建了一个包含现有系统几乎所有功能的系统之前，用户完全没有兴趣。他们不会使用它。

当“最小的有用子集”是“全部”时，如何应用敏捷？

敏捷的解决方案可能不是一次全部替换，而是逐步进行替换。

逐步逐步引入新系统，以保持旧系统的某些部分运行。旧系统并不是一口气关闭，而是逐渐消失了。新部件提供了新功能或其他好处，因此用户很高兴使用它们。由于您始终拥有100％的工作系统，因此风险也较小。

• 从Martin Fowler阅读更多内容。
• Michael Feather的“有效处理遗留代码”中的策略可能会有用

与其重新编写现有系统（如前所述，在新系统与现有功能匹配之前将花费很多精力），不如考虑采用扼杀的方法。基本上，您可以在现有应用程序之上使用新方法来实现新功能。最终，当您解决旧系统的缺点以解决新功能时，新代码将完全取代旧代码。

与旧应用程序的“重新启动”相比，这需要更多的准确性和精力。但是您获得投资回报的时间更短。同样，在整个过程中，您可以放置​​钩子，以使“新”系统更容易被下一个“新”系统勒死。

将少量增量释放到世界上可能适用于未开发的项目，但是即使那样，少量功能也可能不太有用。

Scrum主张在每次冲刺之后，该产品都是“可能可运输的”。它不必装运，但必须具有可运输产品的质量。

如果您确实想为用户提供该应用程序的增量版本，则可以将其分类为Alpha，Beta，然后发布候选版本，同时仍然使用实际的Production应用程序。

如果您合并了用户的反馈，则可能会发现添加了新功能而删除了旧功能。

我为大型国家有线电视网络进行了大量的业务应用程序替换工作。新系统的开发是使用SCRUM完成的，这是一个大约18-24个月的开发项目，用于重新实现几乎所有主要子系统。已经快十岁了

在开发开始之前，有一个大约6个月的计划阶段，但也被称为SCRUM。在这里，产品负责人在对现有系统进行分析并采访客户之后，在这里写了高级商店和史诗。

进入关键维护模式后，现有系统非常稳定。仅显示止动器问题已修复，所有记录仅出于历史目的，并确保相同的问题不会出现在新系统中。

新系统按照敏捷过程中的描述进行了开发，在大多数情况下都非常流畅。当替换系统达到功能要求时，它并没有投入生产，而是进入了并行生产试验。非关键工作人员的子集开始使用两个系统，以验证新系统的行为是否与旧系统相同。当然修复了旧错误。

当新系统完成几乎100％的新功能时，将其推广用于一般的并行生产运行，该过程持续了几个月。

一旦客户认为满足了他们的需求，便会备份，关闭旧系统并坐下来。我认为他们已经重新调整了旧系统硬件的用途，因为在切换后他们再也不需要恢复到旧系统。

我仍然认为敏捷在这种情况下会增加很多价值。

只是您有一个非常明确的最终目标，即“替换当前系统”。

敏捷的技术和流程仍然可以使您更有效地到达那里。

例如：

您仍然可以迭代且小规模地在系统上交付。

与关键人员交流后，您仍然可以使用敏捷技术来确定工作的优先级。

您仍然可以使用敏捷来基于观察到的速度进行计划。

您仍然可以使用诸如传播知识，TDD，简洁编码之类的敏捷技术和理念来提高项目的质量和内部设计。

如果您的人员对项目真正“不感兴趣”，并且直到他们有完美的替代者才开始参与该项目，那么无论您使用瀑布式，敏捷式还是其他任何方法，都将面临更大的问题。

它的工作原理相同，但是这种方法将很难出售给现有用户。他们可能不需要新系统，也不想定期进行测试。他们想等待尽可能长的时间，然后最后进行测试。大多数用户都会在某种程度上感觉到这种方式，但这取决于负责任的人员对其进行培训。在他们看来，您正在使用现有的应用程序，因此您应该知道该怎么做，为什么要打扰他们呢？

让他们了解您不想这样做，因为您认为这很有趣，并且会使用瀑布式过程感到孤独。从长远来看，它将成为一个更好的应用程序。

一个关键卖点可能是在构建他们一直想要的新应用程序的过程中实施一次更改，但永远无法在旧系统中实现。

如果我有一辆生锈的旧车，需要开车去上班，然后去经销商处购买新车。我想要的型号已经无货，因此他们必须从工厂订购，并且尚需时日。

然后，经销商出于真诚而决定为您提供汽车发动机缸体，直到您订购的汽车驶入为止。您应该如何使用汽车发动机？当然，我可以连接一些组件来对其进行测试并使其正常工作，但这确实无济于事，我明天才能在那辆旧生锈的汽车上工作。

诚然，制造汽车和构建定制软件之间有很大的不同，但是为了争辩，让我们忽略它。故事的重点不要困惑，即客户已经拥有足够好的软件来完成工作的时候，发现增量更改毫无用处。目前已经满足了他们的需求。

这并不是说敏捷不是此处流程的重要组成部分，因为它确实允许向客户不断反馈有关项目状态的信息。他们可以确保在取得重大里程碑和可交付成果之前取得进展。他们可以及早发现潜在的问题和问题，以免因无法修复而造成的损失太大。

也许作为汽车客户，您只是想看看并评估发动机，以确保您确实能够实现预期的目标。糟糕，我实际上想要的是6缸发动机而不是4缸发动机！我没早告诉你吗 没问题，让我们将更改更改为出厂订单。

向客户表明，使用新版本的软件（而不是替代软件）对他们最大的利益，而是对其进行评估，并确保他们对每一步都满意。