使用敏捷方法重写软件

假设您必须使用敏捷方法重写整个应用程序，您将如何做？

我猜您可以根据当前系统的行为编写大量用户案例。然后以小的迭代形式实现它们。但这并不意味着我们具有UP FRONT的要求？

另外，什么时候开始发布？敏捷说我们应该早并且经常发布，但是在完全重写完成之前发布并没有多大意义。

将其分解为高级史诗。一次处理应用程序的每个功能区域。

将一个史诗分解为一组故事（可用的片段-可以改善应用程序的所有内容），并在没有现有应用程序的情况下按需进行管理，但有一个例外：如果可能，请进行整理，以便您可以在原始应用程序的一部分或旁边实现该功能。

当敏捷主义者说“提前且经常发布”时，这不一定意味着生产。如果要替换现有应用程序，则应使用暂存区进行频繁发布，并确保用户在此处进行系统测试。这仍将为他们留出空间来确定下一个工作的优先级，并确保您发布的所有产品都不会使产品贬值。

将一个组件发布到生产中后，请转移到下一个组件。

我们刚刚经历了这样的经历（我是Scrum产品所有者）。我们花了两年时间才找到可释放的东西。但是，敏捷为我们带来了很多好处。

首先：完全重写本质上并不敏捷。您应该考虑逐个重构现有产品。在另一个问题中已对此进行了讨论。因此，我们假设它必须是一个重写。

然后，实际上，您从一个包含现有产品所有相关用例的后备日志开始。但是请不要将其作为编写规范。那将是太多细节。它应该是完整的（否则您将无法进行发布计划）。而且它不应该太复杂（否则，您要预先编写规范）。这是我们的处理方法：

• 对旧产品的用户进行分类。确定仅需要一小部分旧产品并仍能从中获得有用信息的用户。他们定义了您的第一个史诗。

• 然后添加史诗，使其他类别的用户可以迁移到新产品。等等，直到您拥有涵盖所有用户的待办事项日志。

• 这些史诗极有可能需要进一步分裂。如果可能，请尝试拆分，以使每个部分仍然具有一定的价值。如果那不可行，那么至少要确保每个部分都可以演示。

• 当您有20至50个史诗时，请团队估算它们。

• 将最重要的史诗分成“用户故事”，团队认为这是在sprint中可行的。暂时不要对所有史诗都这样做。您将有足够的时间分配其余部分。

什么时候对外发布！那是一个商业决定。至少这种方法使您有机会提前发布到某些用户类别。如果管理层对这个看似永无止境的项目感到不安，那将很方便。

如果可以，请立即发布

关于何时开始发布代码的问题是一个很棒的问题。我认为有两个条件。首先，您具有“足够好的质量”，其次，您满足了MVP（最低可行产品）的要求。

罗马（和敏捷）不是一天建成的

也许您已经准备好与交钥匙型敏捷团队接手，在第一天就接手了。对于大多数组织而言，培训，重新装备以及通常的组建，建立，规范，执行团队的周期是工作和花费的工作。提前了解风险和成本，谨慎设定切合实际的期望，并保持警惕并准备提倡您的方法。

成为重用的引导程序

像融合能力一样，代码重用一直并将永远是解决我们的经济问题的未来解决方案。我的感觉是，开发人员经常说他们相信重用，但是只有在构建新框架之后才开始的重用，而不是在别人已经完成的事情上进行构建的那种重用。在有人愿意选择在别人的基础上建立基础之前，这将如何工作？充其量，这意味着团队领导层变动时，每隔几年要重写一次。

为什么要提早发行并经常发行？

提前发布，并且出于多种原因通常是一种口头禅。它使我们对产品应成为什么的讨论变得栩栩如生，它使我们真正成为了现实，并为我们提供了迭代/增量式更改的基础。发布的速度对于敏捷性几乎是不变的，区别在于谁接收发布（客户代理或最终用户）。在敏捷开发之前，维护费用估计占软件系统成本的60％。对于经理和其他人来说，这是一个很大的惊吓来源，有些人认为产品发布是软件必死的地方。对于他们来说，发布后的所有工作都是返工并需要付费以修复他们已经付费的产品。

预发行是不自然的

肯特·贝克（Kent Beck）写道，预发布对于软件产品而言是不自然的状态。这肯定是一个不方便的时间，因为那是您没有客户并且您为产品付款而不是产品为您付款的时间。

不要批评以前的团队

虽然这可能会使接管重写工作的开发人员成为项目的英雄和救星，但我认为批评前团队的成就是有代价的。

• 首先，如果您让人们对上一个团队下定决心，那么您将有更多的时间和精力来执行您的实际任务。
• 如果您需要与以前的团队成员，开发人员以及产品经理，项目经理或客户等利益相关者一起工作，将会很尴尬。
• 如果您能使它正常运行，您可能会发现自己（或者更糟的是，因为以前的团队所做的事情而获得）荣誉。
• 平均而言，以前的球队可能是平均水平。平均而言，您可能是平均水平。您需要比以前的团队更多的工作，因为除了项目之外，您还需要采用新的方法。
• 如果旧团队是可怕的，除非您也可怕，否则您最终会因比可怕更好而得到赞誉。如果它们比可怕的要好，而您并没有明显好，说它们可怕的话可能会引起令人不快的比较。
• 如果旧团队比您想象的要好，并且由于组织破裂或问题定义不明确或非常困难而陷入麻烦，那么如果您没有大幅提高期望，情况会更好。
• 如果他们期望得到什么，但是您做得更好，那对您来说就是胜利。
• 避免批评既是很好的举止，又表明你有阶级。

@Chuck的评论和对Netscape的引用促使他们在本质上说不要重写，并且有效的回答反驳了他的OP并没有问他是否应该这样做。-真正敏捷的软件开发周期可避免重写。重写几乎总是打破敏捷背后的许多原则。使用当前软件作为基线，这些敏捷原则（来自Agile Manifesto）无法通过重写来满足。

• 尽早持续交付有价值的软件。-根据他们已有的资产来衡量，客户将不会获得早期价值
• 频繁交付工作软件 -数周至数月-该项目有多大，您可以诚实地说客户很快就会得到对他们有用的任何东西。
• 工作软件是进度的主要衡量标准 -与基准相比，工作不会急着发生
• 敏捷过程促进可持续发展。-考虑到客户的工作基准，将需要提供改进的功能。这不太可能以可持续的速度进行
• 简单性-最大化未完成工作量的艺术-是必不可少的。这真的说明了一切...

“假设您必须使用敏捷方法重写整个应用程序，您将如何做？”

这个问题基于错误的前提-可以认为重写是敏捷的。

考虑是否可以一次释放一个重写的应用程序，并将其与旧的应用程序并排生产。

特别是对于Web应用程序，将应用程序的单个部分移动到新平台上并使负载均衡器将请求路由到适当的系统可能相当容易。然后写下故事，使您可以将第一页投入生产，并以敏捷的方式交付这些故事。

桌面应用程序可能更复杂，但通常是可能的。

您正在寻找接缝-在旧系统可能将其职责由新系统接管的地方，而无需完全重写。

也许有一些独立的业务逻辑可以移入新的Web服务或框架，并且可以使用旧应用程序而不是其旧代码进行修改。只需在接缝处切掉大块，直到剩下的一切都可以一口处理。

如果找不到任何接缝，则可能确实需要寻找其他一些答案中建议的大爆炸方法。但是在到达目的地之前要做好长途跋涉的准备，尤其是如果您希望继续并行开发旧系统...

敏捷说我们应该早并且经常发布，但是在完全重写完成之前发布并没有多大意义。

实际上，恕我直言，这是关键点-越早在生产中获得部分重写的应用程序（理想情况下替换旧系统的功能），项目成功的机会就越大。如果您认为这没有多大意义，请多加考虑-几乎总是有可能释放零件。

这可能意味着有人必须在旧应用程序中进行某些更改，例如，在重写未完成时添加一些新接口以与重写的应用程序进行交互。但是以我的经验来看，这种额外的工作总能收回成本。

一旦新应用程序的第一部分投入生产，敏捷的迭代方法将变得显而易见。需求将改变，您的用户故事将改变或获得新的优先级，希望您能一步一步地替换旧系统的越来越多的功能。