Scrum

我居然没能在网上找到这个词的中文翻译（也许可以称为迭代开发？）。Scrum 是一种敏捷开发框架，并非简单的“迭代开发”就能完全概括。虽然迭代是 Scrum 的核心组成部分，但 Scrum 还包含许多其他重要的概念和实践。直接使用英文“Scrum”是比较常见的做法。

Scrum 的核心思想是将大型、复杂的项目分解成小的、可管理的迭代周期，称为“Sprint”。每个 Sprint 的长度通常为 1 到 4 周（最常见的是 2 周）。在每个 Sprint 中，团队完成一部分可交付的产品增量。你用 LabVIEW 举例，如果采用 Scrum，并非一定要每月发布一个版本，而是每个 Sprint 结束时交付一个可用的增量。这个增量可能是一个新功能、一个 bug 修复，或者对现有功能的改进。重要的是，每个 Sprint 结束时，产品都应该有所进步，并可以进行演示和评估。因此，一年 12 个 Sprint，并不意味着一定有 12 个对外发布的大版本，而是 12 次内部的迭代交付和评审。

Scrum 的流行，一定程度上受到了 Google 等公司的影响，但并非完全是“示范效应”。更重要的是，Scrum 能够更好地应对快速变化的需求和市场环境，提高软件开发的效率和质量。Google 的“永远的 Beta 版”策略，更接近于持续交付和精益创业的理念，与 Scrum 有相似之处，但并非完全等同。持续交付强调更频繁的发布，甚至每天多次发布，而 Scrum 则更侧重于 Sprint 内的迭代和增量交付。

你提到“软件的很多新功能都是程序员或者经理拍脑袋想出来的，它们或许并不符合用户的需求”，这正是 Scrum 想要解决的问题之一。Scrum 强调以用户为中心，通过频繁的沟通和反馈，确保开发团队始终在构建用户真正需要的产品。尽早将产品展示给用户，并根据用户反馈进行调整，是 Scrum 的核心原则之一，这有助于减少浪费和提高用户满意度。

Scrum 流程并非适用于所有领域，你的盖楼例子很好地说明了这一点。盖楼的工序之间有严格的依赖关系，无法像软件开发那样进行灵活的迭代。将挖坑、地基、墙体等工序强行拆分成按月交付的“增量”，显然是不切实际的。Scrum 更适合于需求变化频繁、复杂性高、需要快速反馈和调整的项目，例如软件开发、网站开发、市场营销等。而对于一些流程固定、工序依赖性强的项目，例如建筑工程、大规模生产制造等，传统的瀑布式开发方法可能更为合适。

实际上，并非所有采用了 Scrum 的公司都获得了成功，例如,引入 Scrum 之后的诺基亚。Google 的成功和诺基亚的失败或许表明，开发流程并非决定企业成败的唯一因素，甚至不是主要因素。企业的成功与否受到市场、战略、产品、管理等多种因素的综合影响。也有可能，Scrum 并非万能药，它只在某些领域才能发挥出最佳效果。任何方法论都有其适用范围和局限性。

回到我熟悉的 LabVIEW。LabVIEW 的主要应用领域仍然是工业测控。这个领域的用户与互联网用户的一个明显差别在于，工业领域的客户通常更加谨慎，对稳定性的要求远高于对新功能和快速迭代的追求。他们更倾向于经过充分验证和测试的成熟技术。LabVIEW 每年升级一次，居然还有很多用户抱怨说升级太快了。与之对比，某个拼音输入法的用户们天天在论坛上抱怨：“都几个星期了，怎么还不更新？”如果让 LabVIEW 的用户每个月更新一次，他们恐怕难以接受。我估计 LabVIEW 在这一点上是无法完全照搬 Google 的模式的。工业领域的用户需要的是长期稳定可靠的解决方案，频繁更新反而可能带来不必要的风险和兼容性问题。

对于不能频繁从外部客户那里收集反馈的软件来说，如果一定要采用 Scrum 流程，那就只能更多地依赖内部反馈，例如从产品经理、测试人员、甚至是高层管理那里获取反馈。每个 Sprint 交付一个内部版本，然后给他们评审，再基于反馈进行下一个 Sprint 的开发。但我个人认为，敏捷开发的核心精髓在于最终用户的快速反馈，这使得软件可以紧跟用户需求的变化。内部人员，无论是谁，他们的需求都必然与最终用户有所偏差，都无法完全代表最终用户。因此，仅仅依靠内部反馈的“敏捷”，效果会大打折扣。至于 Scrum 流程中的其他实践，例如每日站立会议、用户故事、燃尽图等，都只是辅助手段，形式大于内容。没有最终用户的深度参与，新的开发流程可能只是换汤不换药，并不能真正发挥敏捷的优势。这种情况下，可能需要对 Scrum 进行一定的调整和裁剪，使其更适应内部驱动的开发模式。例如，可以更侧重于内部的迭代评审和测试，以确保产品质量和内部需求的满足。