如何实现假设驱动开发 | TW洞见

今日洞见

文章作者来自ThoughtWorks：Barry O'Reilly，图片来自网络。

感谢ThoughtWorks校对小组：钟源、Adam、何璐、姚琪琳，欢迎联系我们加入小组。

本文所有内容，包括文字、图片和音视频资料，版权均属ThoughtWorks公司所有，任何媒体、网站或个人未经本网协议授权不得转载、链接、转贴或以其他方式复制发布/发表。已经本网协议授权的媒体、网站，在使用时必须注明"内容来源：ThoughtWorks洞见"，并指定原文链接，违者本网将依法追究责任。

记得我们在高中上自然科学课的时候，老师会用一个框架来帮助我们学习即基于最有效证据的实验方法。老师鼓励我们对周遭的世界进行观察，然后试着提炼一种阐述或者假设，去解释我们所观察到的东西。然后进行核对实验，我们根据理论提出一种可在核对试验中验证的假设，然后通过实验得到一个结果，如果这个结果满足假设，那就证明我们的理论是正确的。

当然，我们还可以去设计更复杂的实验，来测试和验证各种假设，然后通过更多更深入的观察结果去不断地调整，改换甚至放弃你的假设。

实验是科学研究的基础，也是探索世界的系统性手段。虽然一些实验是在实验室里进行的，但是我们也可以在任何地点和时间进行实验，比如在软件开发领域。

这里我向大家介绍一种假设驱动的软件开发理论，它是我们在思考新的想法、产品和服务，甚至组织变革的基础上实践而来的。在软件开发中通过一系列不停的实验去测试我们的想法，然后找到各种理想结果，当然这个过程是迭代的，直到得到一个理想的结果或是证明当初的想法是不可行为止。

这里需要改变一下观念，我们应该把对某个问题提出的解决方案作为一种假设，特别是在新产品或服务的开发过程中；既然我们是以市场为导向的，那么我们就应该思考这种商业模式将如何运作，这样的产品代码将如何运行，以及目标客户将来会如何使用这样的产品。

这样一来, 我们不再是做项目，而是在做实验。客户挖掘和精益创业策略，专门用来验证关于客户的各种假设。质量保证是根据要求对系统做测试。这种做实验的方式也同样应用于测试驱动开发，我们先编写测试代码，然后用测试来验证代码是否正确，如果代码通过测试，则说明没问题。从根本上说，产品或服务开发是一个过程，通过不断地测试各种关于系统行为或者我们开发的对口市场的假设，去验证最初的方案是否可行。

做实验其实最重要的结果，是可量化的证据和从中得到的经验。

这些经验是通过做实验获得的信息。我们所期望发生的事情真的发生了吗？如果没有，那到底发生了什么，以及它如何启发我们下一步应该要做什么？

为了获得这些经验，我们需要用科学的方法来调查现象、获取新知识，并纠正和整合以前我们脑海中的知识。

随着软件开发行业愈发成熟，我们现在有机会利用先进的功能，如持续设计和交付(CDD)，最大限度地挖掘我们的潜力去快速地知道哪些可行哪些不可行。依靠信息发掘的实验方法，我们可以用已经定义好的产品或正在构建的服务，来快速测试解决方案。）因此，我们的目标是优化有效解决问题的效率，而不是不停地产出方案，成为一个功能和模块堆砌的工厂。

科学方法的步骤是：

• 观察
• 制定一个假设
• 设计一个实验来检验这一假设
• 如果实验成功，设定相关指标评估 （设定检验试验成功与否的相关评估指标）
• 进行实验
• 评估实验的结果
• 接受或拒绝假设
• 如果有必要，制定和测试一个新的假设

用做实验的方法来开发软件

我们要对产品和服务必须具备固定的需求这一观念提出挑战。如果团队正处于项目相对易于理解和把握的阶段，可以用已知的实践经验去得出结果，这时需求是有价值的。但如果正处于一个探索、复杂和不确定的阶段，你需要的是假设。

扔给开发团队一堆业务需求，看似加强了其对业务的认识，其实是有缺陷的。

业务部门能思考并且“认识到”什么是正确的。开发团队的目标则是要实现这些内容。但是当项目进行到一个不确定且复杂的阶段时，开发团队也应该及时加入到问题的讨论和方案的解决过程中来。如果团队的开发需求都从业务这里传递，便难以发掘整个团队的全部潜力、经验和能力。

假设框架

传统的用户故事框架专注于我们想要构建什么和为谁构建，以使用户能够从中得到一些特定的好处。

作为…<角色>

我想要……<目标/愿望>

以便……<获得好处>

行为驱动开发(BDD)和特征注入(FI)通过支持软件项目中开发、测试、非技术人员之间的沟通协作，来改善原有框架。

为了…<得到好处>

作为...<角色>

我想要……<目标/愿望>

当把工作视为一个实验时，传统的故事框架是不够的。正如在在高中科学实验中，我们需要确定用什么样的步骤来达到预设的目标。然后，需要设定一些期望观察到的具体指标（或信号），去证明我们的假设是有效的。这些需要在进行测试之前设定好，以减少对结果的解释偏差。

如果观察到的信号表明假设是正确的，那么我们可以更加确信已经走在正确的道路上，并可以调整用户故事框架来反映这一点。

因此，以支持假设驱动开发(HDD)的用户故事结构将是：

我们相信 <这个能力>

我们将开发什么功能来检验我们的假设？通过定义我们正在开发的产品或服务的“测试”能力，我们便能确定我们想要验证的某个功能和假设。

将导致<这个结果>

我们实验的预期结果是什么？我们通过构建“测试”能力期望的具体结果是什么？

如果能<看到一个可测量的信号>，就意味着我们取得了成功

什么信号表明，我们已经建立的能力是有效的？我们将测量哪些关键指标（定性或定量）来提供证据表明，实验已经成功，并给我们足够的信心以进入下一阶段。

用于衡量统计学重要性的阈值将取决于你对正在操作的业务和上下文的理解。不是每个公司都有像亚马逊、谷歌那样规模的用户样本，能在短期内跑出统计上显著的实验数据。因此，组织需要定义一些限制和控制等，来确定证据可接受的阈值，这将有利于团队更顺利地推进到下一步。

例如，你正在建造一艘火箭飞船，那么你会希望表明实验统计学意义的阈值较高。如果是在2个不同的用户注册流程之间选择一个能帮助增加用户注册量的流程，你可能会乐于容忍一个较低的阈值。

最后一步是清晰明显地提出关于我们假设的各种设想，为团队建立一个反馈回路，以提供进一步的输入，讨论和了解我们测试的各种情况。从技术和商业角度看，他们是否有效？

当瞄准MVP用户时，所做的假设便可以为你从产品和服务的视角提供一种测试机制。这些假设可以验证产品或服务中最不确定的领域，当然，从中也可以获取更重要的信息以及提升自己的信心。

假设驱动开发用户故事的例子：

商业故事

我们认为，增加酒店的预订页面上的图像大小

将会提升客户的参与度和转换率

如果客户量增加了5%，并且这些客户浏览了酒店图片并在48小时之内预定了酒店，就意味着我们取得了成功。

当我们使用实验方法从事软件开发时，必须要有有效的监测和评估工具，来衡量我们的努力所带来的的影响，并给团队提供一个反馈回路。否则，我们就是在盲目地去寻求努力的结果。

在敏捷软件开发中，我们将能工作的软件作为衡量进展的主要手段。

通过整合持续交付(CD)和假设驱动开发(HDD)，现在我们可以定义衡量进展的主要手段为可工作的软件，和经验证的知识。

理想情况下，不应该说我们搞定了，除非已经测量到了正在提交的产品的数据值，而应该是我们已经收集到了足够的数据可以验证我们的假设了。

比如，如何收集数据做A/B测试，来验证一个假设和衡量客户行为的变化。可供选择的测试方法可以有：客户调查、构建纸上原型、用户和/或游击测试。

Lastminute.com是一家曾经和我们合作过的采用假设驱动开发的公司。该团队制定了一个假设，即预定酒店的客户只会支付在他们预定的时间内价格最高的房间。汤姆-克莱因，Sabre Holdings的首席执行官及总裁，分享了他们如何在一周内提高400%的转换率的故事。

结论

结合实践，假设驱动开发(HDD)和持续交付(CD)加速了试验和增强了验证知识的机制。这让我们有机会加快创新的速度，同时不断地降低成本，以便领先于竞争对手。理想的情况下，我们可以到达一种理想的状态：细微的改变就能够确定产品和服务各种变化之间的因果关系，以及它们对关键指标的影响。

Kent Beck说，“测试驱动开发(TDD)让你有充足的理由在思考方案之前去思考各种问题”。假设推动开发(HDD)却给了你很好的机会，在提出解决方案之前，去检验对问题的看法。