实现新的编译器后端时，Scrum是否有意义？

我有一种需要移植到新平台的现有语言。我可能会通过更改现有编译器的后端进行尝试。

重写后端需要大量的工作。在不违反INVEST标准的情况下，我看不到将其分解为明智的故事的方法。

我看不到每个故事如何可以面议-它们都是正常工作的编译器所必需的。这些故事都具有同等优先权，无论我按什么顺序发表它们都无所谓。我需要全部做。

我正在实施的软件中某些部分的优先级比其他部分低，我可以看到我们可以逐步提供该部分。但是，必须具备一个重要的核心。

我计划尝试遵循Scrum，但是我只是在进行议案吗？

有针对此类项目的推荐做法吗？

请记住，创建敏捷流程的主要原因是为了应对不断变化的需求。如果需求是一成不变的（真正固定的需求很少见，但我会在这里告诉您！），那么处理不断变化的需求的一些最佳做法（例如，可谈判的故事）就变得无关紧要。也就是说，遵循Scrum工作流程在计划和提供可交付成果方面仍然具有很多潜在价值。即使您的交付物在一段时间内不能构成完全可用的产品，仍然有一些事情可以向客户（和团队！）展示进度。

考虑所有这些“必须具备”的故事都包含一个史诗：“能够在X平台上进行编译”。在这种情况下，需要在向用户交付任何值之前完成整个史诗，但是在大型项目开始时通常就是这种情况。从一个故事开始，以编译最简单的程序，然后创建更多故事，以支持越来越多的语言功能。

最重要的是，不要太着迷于试图迫使每种情况都适合高度通用的方法。敏捷应该为您工作，而不是相反！

当然，Scrum是有用的。这种方法可以为您做两件事：

1. 它使您的项目适应变化和
2. 它使您可以跟踪进度，并了解何时完成

因此，使用它有一些价值。

我认为您的某些先决条件不正确，这就是您迷路的地方。

我看不到每个故事如何可以谈判-它们都是工作编译器所必需的

这不是真的。您可以支持该语言的子集，但仍可以使用在某些条件下可以运行的编译器。肯定不如完整的编译器有价值，但仍然有价值。

此外，您会误解“可协商”的含义：它不一定意味着“可选”，并且没有要求故事在INVEST中是可选的。一个故事是一个有价值的目标，而谈判则是关于如何实现该目标的谈判。当然，除了实现每种语言功能的后端之外，还有更多的方法。有需要谈判的地方。

这些故事都具有同等优先权，无论我按什么顺序发表它们都无所谓。

这是不正确的，正如您在下面说的那样，有些故事不是“必须具备”的，因此肯定有些价值较小。但是，即使在“必须具备”类别中：某些语言功能比其他语言功能更基础，而且可以测量。

衡量这种情况的一种方法是“如果在预定义的测试套件中，我们可以在现有代码库上编译多少行代码”或“可以通过多少次测试”。

还有其他选择。如果你编译一个类C语言，严格来说你只需要if和goto循环有一个（勉强）函数式语言，你可以实现while，for并repeat为宏。假设编写一个预编译器很容易，那么您可以有一个便宜的权宜之计（嘿，我们正在谈判吗？:-)

关于适应性，支持语言是一组相当静态的要求，但是语言也会发生变化，并且您对需求的了解也会发生变化。您需要实施所有内容吗？有没有您不需要专门用于目标的东西？敏捷的基本租户之一是拥有不完整知识的知识，您可以利用它吗？

总之，要更直接地回答您的问题：当您的需求不变时，您是否需要敏捷流程？当然不！它们可用吗？可能是！他们值得你花时间吗？可能不是-但是您的要求不变吗？根据我过去的经验，“不可更改的需求” =>“懒惰的产品所有者”-不是规则，但值得牢记。

TL; DR

所有项目管理控件都会增加开销。不要增加不必要的开销。

Scrum在这里是错误的锤子（别钉子）

Scrum是一个项目管理框架，而不是适合于单个开发人员的一组开发实践。除非您执行项目管理，否则Scrum可能是错误的选择。

另外，当您说：

这些故事都具有同等优先权，无论我按什么顺序发表它们都无所谓。我需要全部做。

您暗示了几件事：

1. 除非所有故事都已100％完成，否则该项目的价值为零。
2. 这些故事并不相互依赖。

如果这两个陈述都是正确的，那么使用旨在按值或依存顺序对工作进行优先级排序的框架或实践就没有任何意义。

建议的替代品

任何开发项目都可能会从一些敏捷实践中受益。特别是，根据您的具体情况，我建议：

1. 确保您所有的故事都有一个“完成的定义”，其中包括单元测试和验收测试。
2. 经常整合和重构；在项目结束时不要让自己承担巨大的集成任务。

此外，即使除非所有故事都完成，否则即使您的产品真正具有零价值，我也会花一些时间将这些故事归类为可以视为已完成的里程碑的主题。能够说“我已经完成foo功能”通常比说“我已经完成23/117个随机故事”更有用。YMMV。

我了解您的担心，但我相信使用Scrum仍然对您有价值。

诚然，用户故事比面向消费者的应用程序更固定。因此，scrum的这一方面将提供较少的价值。

我认为您将从迭代和频繁发布中获得价值。在每个sprint末尾都有一个可能发布的产品会迫使您保持较高的代码质量和较低的技术债务。这也是尽早发现缺陷的好方法。

我认为您也将从了解自己的速度中受益。经过几次冲刺，您可以看到团队完成每个冲刺需要付出多少努力。这为您提供了一个客观的指标来帮助您确定发货日期。

首先，请记住，敏捷是形容词。在每次冲刺结束时，您都应该举行一次回顾性会议，然后根据需要调整流程。如果Scrum流程中有一部分不适用于编译器开发，请删除它。如果还有其他使您受益的过程元素，请添加它。在我看来，敏捷最重要的部分是要了解您的流程，并针对您的特定情况不断进行改进。

（请注意，我从未在编译器项目上做过混乱；我的建议是一丁点儿。）

是的，只要您还记得Scrum不是要遵循的一组严格规则，它就可以做到。您可以将其调整为您的项目。冲刺，站立式训练，每周打乱仍然有用，以促进团队成员之间更好的沟通，并确保项目按预期的方向继续进行。

所有故事似乎都具有同等的优先级，但是您需要考虑实施它们的相对困难。您不希望在项目结束前保留最困难的物品。您将希望尽快开始研究它们。