为什么假设驱动开发是 DevOps 的关键

Donovan Brown 对 DevOps 的定义是 “人、流程和产品的结合，以实现向客户持续交付价值。” 它强调了持续交付价值的重要性。让我们讨论一下实验是如何成为现代开发实践的核心的。

回顾过去

在深入探讨假设驱动开发之前，让我们快速回顾一下我们如何使用瀑布模型、敏捷开发、部署环和功能标志来交付价值。

在瀑布模型时代，我们拥有可预测的和流程驱动的交付。然而，我们只在开发生命周期的末尾交付价值，而且经常在后期失败，因为解决方案偏离了最初的需求，或者我们的杀手级功能在我们最终发布时已经过时了。

在这里，我们有一个 X 版本和八个功能，它们都被部署并暴露给耐心等待的用户。我们不断地交付价值——但是，由于典型的发布节奏为六个月到两年，随着世界继续前进，功能的价值会下降。当有时间计划并且对响应更迫切的需求的期望较低时，它工作得还不错。

敏捷开发的引入使我们能够创建和响应变化，从而我们可以持续交付可工作的软件，感知、学习和响应。

现在，我们有三个版本：X.1、X.2 和 X.3。在 X.1 版本发布后，我们根据反馈改进了功能 3，并在 X.3 版本中重新部署了它。这是一个更频繁地交付功能、专注于可工作的软件和响应用户反馈的简单示例。我们正在持续交付的道路上，专注于我们的关键利益相关者：我们的用户。

使用部署环和/或功能标志，我们可以将发布部署和功能暴露解耦，细化到单个用户，以控制功能的暴露范围——爆炸半径。我们可以进行实验；逐步暴露、测试、启用和隐藏功能；微调版本，并根据学习和反馈不断调整方向。

当我们将功能标志添加到以前的工作流程中时，我们可以切换功能为 ON（启用和暴露）或 OFF（隐藏）。

在这里，功能 2、4 和 8 的功能标志为 OFF，这导致用户接触到的功能更少。所有功能都已部署，但尚未暴露（目前）。我们可以在部署到生产环境后微调每个版本的特性（价值）。

基于环的部署在用户上逐渐部署和评估一个或多个功能时，限制了对用户的影响（爆炸）。环允许我们逐步部署功能，并并行运行多个版本（v1、v1.1 和 v1.2）。

在金丝雀环和早期采用者环中暴露功能使我们能够在没有全有或全无的大爆炸式部署风险的情况下评估功能。

功能标志将发布部署和功能暴露解耦。您“拨动标志”以暴露新功能，通过重置标志执行紧急回滚，使用规则隐藏功能，并允许用户切换预览功能。

当您结合部署环和功能标志时，您可以逐步通过环部署版本，并使用功能标志来微调已部署的版本。

请参阅 部署新版本：功能标志或环、功能标志的成本是什么，以及 打破人、流程和产品之间的壁垒，以了解有关功能标志、部署环和相关主题的讨论。

将假设驱动开发添加到组合中

假设驱动开发基于一系列实验，以在 复杂问题领域 中验证或证伪假设，我们在其中有未知的未知。我们想要找到可行的想法或快速失败。与其开发一个庞大的解决方案并执行大爆炸式发布，不如迭代假设，评估功能的表现，最重要的是，客户如何以及是否使用它们。

模板： 我们相信 {客户/业务部门} 想要 {产品/功能/服务} 因为 {价值主张}。

示例： 我们相信 用户想要能够选择不同的主题因为这将提高用户满意度。我们预计 50% 或更多的用户会选择非默认主题，并且用户参与度会提高 5%。

每个实验都必须基于假设，具有可衡量的结论，并有助于功能和整体产品学习。对于每个实验，请考虑以下步骤

• 观察您的用户
• 定义一个假设和一个评估假设的实验
• 定义明确的成功标准（例如，用户参与度提高 5%）
• 运行实验
• 评估结果并接受或拒绝假设
• 重复

让我们再次看一下我们的示例版本，其中包含八个假设功能。

当我们部署每个功能时，我们可以观察用户行为和反馈，并证明或证伪推动部署的假设。正如您所看到的，功能 2 和 6 的实验失败了，这使我们能够快速失败并将它们从解决方案中删除。我们不希望携带不交付价值或不让用户满意的浪费！ 功能 3 的实验尚无定论，因此我们调整了功能，重复实验，并在 X.2 版本中执行 A/B 测试。根据观察，我们将变体功能 3.2 确定为获胜者，并在 X.3 版本中重新部署。我们只暴露通过实验并让用户满意的功能。

假设驱动开发点亮了渐进式暴露

当我们将假设驱动开发与渐进式暴露策略相结合时，我们可以垂直切分我们的解决方案，逐步实现我们的长期愿景。对于每个切片，我们逐步暴露实验，启用让用户满意的功能，并隐藏那些未通过的功能。

但这还不是全部。当我们拥抱假设驱动开发时，我们可以了解技术如何协同工作，或者不协同工作，以及我们的客户需要什么和想要什么。我们还补充了测试驱动开发 (TDD) 原则。TDD 鼓励我们首先编写测试（假设），然后确认我们的功能是正确的（实验），并成功或失败测试（评估）。一切都与质量和让用户满意有关，正如 敏捷宣言 的原则 1、3 和 7 中概述的那样

• 我们最高的优先级是通过尽早和持续地交付有价值的软件来满足客户。
• 经常交付软件，从几周到几个月，最好是更短的时间尺度。
• 可工作的软件是衡量进度的主要指标。

更重要的是，我们引入了一种新的思维模式，打破了开发、业务和运营之间的壁垒，以迭代实验的方式查看、设计、开发、交付和观察我们的解决方案，根据科学分析、用户行为和生产环境中的反馈采用功能。我们可以通过在生产环境中的观察和学习，以薄片的方式发展我们的解决方案，这是航空航天或土木工程等其他工程学科只能梦想的奢望。

好消息是，假设驱动开发支持经验过程理论及其三大支柱：透明性、检查和适应性。

但这还不是全部。基于精益原则，我们必须在衡量和检查反馈后进行调整或坚持。将功能切换与假设驱动开发结合使用，我们可以获得两全其美的效果，以及使用 A|B 测试来根据反馈（例如喜欢/不喜欢和价值/浪费）做出决策的能力。

记住

假设驱动开发

• 是关于一系列实验，以确认或证伪假设。识别价值！
• 交付可衡量的结论，并实现持续学习。
• 使关键利益相关者（用户）能够持续反馈，以了解未知的未知！
• 使我们能够了解不断发展的环境，我们在其中逐步暴露价值。

渐进式暴露

• 不是隐藏未准备好生产的代码的借口。始终交付高质量的产品！
• 是关于通过环在生产环境中部署版本的功能。限制爆炸半径！
• 是关于在生产环境中启用或禁用功能。微调版本价值！
• 依赖断路器来保护基础设施免受渐进式暴露的影响。观察、感知、行动！

您对渐进式暴露策略和假设驱动开发有什么了解？我们期待您坦诚的反馈。