将科学方法应用于敏捷开发

“如果一切都按计划进行，那唯一的原因就是你没有学到任何东西。” ——Kent Beck

实验是科学方法的基础，科学方法是一种系统地探索我们周围世界的方式。但实验不仅限于科学研究领域。它在商业世界中也占有核心地位。

我们大多数人现在都熟悉一种名为最小可行产品 (MVP)的商业方法。这个最小可行产品基本上只是一个实验。通过构建和发布 MVP，商业运营正在进行一种系统地探索市场的方式。

如果我们看看今天的市场领导者，我们会发现他们不再做项目了；他们唯一做的事情就是实验。客户发现和精益策略仅用于测试关于市场的假设。这种方法等同于测试驱动开发 (TDD)，这是我们非常熟悉的过程。在 TDD 中，我们首先编写假设（测试）。然后，我们使用该测试来指导我们的实施。最终，产品或服务开发与 TDD 没有什么不同——我们首先编写一个假设，然后该假设指导我们的实施，这可以作为假设的可衡量验证。

信息发现

在敏捷时代之前，需求收集是一项重要的活动，过去总是启动项目。一群主题专家 (SME) 会被分配到项目中，并负责收集需求。经过长时间的前期信息发现后，收集的需求会经过审查，如果获得同意，则会签署并冻结。不再允许更改！

那时，这似乎是一件完全合理的事情。一旦构建阶段开始，问题总是会出现。随着项目的进展，迟早会有新的信息出现。突然间，我们最初视为不容置疑的真理受到了新获得的信息和证据的挑战。

但关键在于门控阶段。请记住，一旦需求获得批准，它们就会被冻结——不再有更改，不允许范围蔓延——这意味着新获得的市场见解会被有意忽略。

嗯，这有点愚蠢的疏忽。新出现的证据可能对业务运营的健康至关重要。我们能承受忽视它吗？绝对不能！我们别无选择，只能拥抱变化。

在行业中发生多次重大失败之后，许多软件开发项目转向了敏捷方法。使用敏捷，信息发现是部分的。使用敏捷，我们从不声称我们已经收集了需求，现在准备实施它们。我们持续不断地发现信息并实施它。我们以微小的步骤进行，始终保持我们的努力是可中断和可指导的。

如何利用科学方法

科学方法是经验性的，包括以下步骤

步骤 1：进行并记录仔细的观察。

步骤 2：针对观察到的证据进行定向。

步骤 3：制定假设，包括用于假设评估的可衡量指标。

步骤 4：设计一个能够测试假设的实验。

步骤 5：进行实验（即，发布部分实施）。

步骤 6：收集运行实验产生的遥测数据。

步骤 7：评估实验结果。

步骤 8：接受或拒绝假设。

步骤 9：返回步骤 1。

如何制定假设

当从项目切换到实验时，传统的用户故事框架（作为__我想要__以便__）已被证明是不够的。传统的用户故事格式不会暴露评估结果所需的信号。相反，旧式的用户故事格式侧重于输出。

在没有首先制定假设的情况下进行实验的问题在于，在解释实验结果时存在引入偏差的风险。定义可衡量的信号，使我们能够证实我们的假设，必须在我们进行实验之前完成。这样，我们在解释实验结果时才能保持完全公正。我们不能被一厢情愿的想法所左右。

制定假设的最佳方法是使用以下格式

我们相信[此功能]将导致[此结果]。当我们[看到可衡量的信号]时，我们将有信心继续进行。

可工作的软件不是衡量进度的标准

基于输出的指标和概念（“完成”的定义、验收标准、燃尽图和速度）非常适合检测可工作的软件，但在检测可工作的软件是否增加价值方面却惨败。

只有当“完成”增加价值时，它才重要。不增加价值的可工作的软件不能被声明为“完成”。

被遗忘的一列

以技术为中心的项目将活动分解为四列

1. 想法 backlog
2. 分析
3. 进行中
4. 已交付

以上结构基于一个坚定的信念，即所有可工作的软件都是有价值的。现在的重点必须转向持续交付真正的价值，即为客户服务的东西。敏捷主义者重视结果（对客户的价值）而不是功能。

假设驱动开发的新分解看起来像这样

所有目光都必须停留在“已实现预期结果”列上。