假设驱动的开发思维收获了特性标志的核心价值：生产中的实验。

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

回顾过去

在进入假设驱动开发之前，让我们快速回顾一下如何使用瀑布、敏捷、部署环和特性标志交付价值。

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

在这里，我们有一个release X和八个特性，它们都被部署并向耐心等待的用户公开。我们一直在提供价值，但典型的发布周期为6个月到2年，随着世界的继续发展，这些功能的价值也在下降。当有时间计划和较低的期望来应对更紧迫的需求时，它就足够有效了。

敏捷的引入使我们能够创建和响应变化，这样我们就可以不断地交付工作软件、感知、学习和响应。

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

使用部署环和/或特性标志，我们可以将发布部署和特性公开分离，直到单个用户，以控制特性的爆炸半径。我们可以进行实验；逐步暴露、测试、启用和隐藏功能；微调版本，并持续以学习和反馈为中心。

当我们向上一个工作流添加功能标志时，我们可以将功能切换为打开（启用和公开）或关闭（隐藏）。

这里，特性2、4和8的特性标志是关闭的，这将导致用户暴露在较少的特性中。所有功能都已部署，但尚未公开。在部署到生产环境之后，我们可以微调每个版本的特性（值）。

基于环的部署限制了对用户的影响（blast），同时我们通过观察逐步部署和评估一个或多个功能。环允许我们逐步部署功能，并有多个版本（v1、v1.1和v1.2）并行运行。

在canary和早期采用者环中公开特性使我们能够评估特性，而不必冒完全或完全没有大爆炸部署的风险。

功能标志使发布部署和功能公开分离。您可以“翻转标志”以显示新功能，通过重置标志执行紧急回滚，使用规则隐藏功能，并允许用户切换预览功能。

当您组合部署环和功能标志时，可以通过环逐步部署发布，并使用功能标志来微调部署的发布。

有关功能标志、部署环和相关主题的讨论，请参见部署新版本：功能标志或环、功能标志的成本以及打破人员、流程和产品之间的隔墙。

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

假设驱动的发展是建立在一系列实验的基础上，在一个复杂的问题领域里，我们有未知的未知因素来验证或反驳一个假设。我们想找到可行的想法，否则很快就会失败。与开发一个整体解决方案和执行一个大爆炸版本不同，我们迭代假设，评估特性如何执行，最重要的是，客户如何使用它们以及是否使用它们。

Template: We believe {customer/business segment} wants {product/feature/service} because {value proposition}.

Example: We believe that users want to be able to select different themes because it will result in improved user satisfaction. We expect 50% or more users to select a non-default theme and to see a 5% increase in user engagement.

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

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

让我们再来看看我们的示例版本，它有八个假设的特性。

当我们部署每个功能时，我们可以观察用户的行为和反馈，并证明或反驳推动部署的假设。如您所见，对于特性2和特性6的实验失败了，这使我们能够快速失败并将它们从解决方案中删除。我们不想携带没有价值或没有取悦我们的用户的废物！特性3的实验是不确定的，因此我们对特性进行了调整，重复了实验，并在版本X.2中执行了A/B测试。根据观察结果，我们将变体特性3.2确定为赢家，并在版本X.3中重新部署。我们只公开通过实验的特性，让用户满意。

假设驱动的发展照亮了渐进式曝光

当我们将假设驱动的开发与渐进式曝光策略相结合时，我们可以垂直分割我们的解决方案，逐步实现我们的长期愿景。在每个切片中，我们逐步公开实验，启用让用户高兴的功能，并隐藏那些没有进行剪切的功能。

但还有更多。当我们接受假设驱动的开发时，我们可以了解技术如何协同工作，以及我们的客户需要和想要什么。我们还补充了测试驱动开发（TDD）原则。TDD鼓励我们先写测试（假设），然后确认我们的特征是正确的（实验），并成功或失败的测试（评估）。正如《敏捷宣言》的原则1、3和7所述，这一切都是关于质量和让用户满意的：

• 我们的首要任务是通过早期和持续的价值交付来满足客户。
• 经常交付软件，从几周到几个月，优先选择较短的时间范围。
• 工作软件是衡量进步的主要标准。

更重要的是，我们引入了一种新的思维方式，它打破了开发、业务和操作之间的隔阂，在一系列迭代实验中查看、设计、开发、交付和观察我们的解决方案，采用了基于科学分析、用户行为和生产反馈的功能。我们可以通过在生产中的观察和学习，将我们的解决方案分为薄片，这是其他工程学科（如航空航天或土木工程）梦寐以求的奢侈品。

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

但还有更多。在精益原则的基础上，我们必须在对反馈进行测量和检查之后，进行调整或坚持。使用特征切换和假设驱动的开发，我们可以同时获得两个世界的最佳结果，以及使用A | B测试对反馈（如喜欢/不喜欢和价值/浪费）做出决策的能力。

记得：

假设驱动的发展：

是关于一系列实验来证实或反驳一个假设。识别价值！

提供可测量的结论，并使持续学习成为可能。

使关键干系人的持续反馈用户了解未知的未知！

使我们能够理解我们逐渐暴露价值的不断发展的环境。

渐进式曝光：

不是隐藏非生产就绪代码的借口。始终保持船舶质量！

是关于在生产中通过环部署功能的发布。限制爆炸半径！

关于启用或禁用生产中的功能。微调释放值！

依靠断路器保护基础设施免受渐进暴露的影响。观察，感觉，行动！

关于渐进式暴露策略和假设驱动的发展，你学到了什么？我们期待您的坦率反馈。

原文：https://opensource.com/article/19/6/why-hypothesis-driven-development-devops

本文：http://jiagoushi.pro/node/1016

讨论：请加入知识星球或者微信圈子【首席架构师圈】