软件开发中的实验驱动与审查协调实践

### 软件开发中的实验驱动与审查协调实践 #### 1. 实验驱动开发与A/B测试的重要性 在软件开发项目中，开发者常常花费数月甚至数年开发功能，却未确认是否达成预期业务成果。例如，某个功能是否实现预期效果，甚至是否被使用。若发现功能未达预期，修正可能会因新功能优先级而被搁置。Jez Humble指出，测试商业模式或产品想法最无效的方式是构建完整产品来验证需求是否存在。 在构建功能前，我们应严格自问“是否应该构建，为何构建”，并通过用户研究进行低成本、快速的实验，以验证功能能否实现预期结果。可运用假设驱动开发、客户获取漏斗和A/B测试等技术。 ##### 1.1 Intuit的假设驱动开发案例 Intuit专注于为小企业、消费者和会计专业人士提供商业和财务管理解决方案。创始人Scott Cook倡导创新文化，鼓励团队采用实验性方法进行产品开发。以TurboTax网站为例，2010年引入创新文化后，在税务季三个月内从每年约7次实验增加到165次实验，网站转化率提高了50%。 令人惊讶的是，TurboTax在流量高峰期进行生产实验。以往零售行业在假期会因担心收入受影响而冻结变更，但TurboTax通过快速安全的软件部署和发布，使在线用户实验和生产变更成为低风险活动。这表明实验在流量高峰期价值最高，若错过时机，公司可能会失去潜在和现有客户。 ##### 1.2 A/B测试的历史与应用 A/B测试源于直接响应营销，与大众营销或品牌营销相对。早期，直接响应营销通过邮寄明信片或传单进行实验，以确定哪种报价转化率最高。每次实验成本高、耗时长，但迭代测试若能显著提高转化率则回报丰厚。 如今，A/B测试广泛应用于活动筹款、互联网营销和精益创业方法等领域。英国政府也曾用其确定催缴逾期税款的最佳信件。 ##### 1.3 集成A/B测试到功能测试 现代UX实践中，常用的A/B测试是在网站上随机向访客展示页面的两个版本（A或B），通过统计分析两组用户的后续行为，确定处理（如功能、设计元素、背景颜色的更改）与结果（如转化率、平均订单大小）之间的因果关系。 例如，可通过修改“购买”按钮的文本或颜色来测试是否增加收入，或通过引入人工延迟来测试网站响应时间减慢是否减少收入。这种测试能为性能改进确定美元价值，有时也称为在线控制实验和拆分测试，还可进行多变量测试。 Dr. Ronny Kohavi观察到，评估旨在改善关键指标的实验时，只有约三分之一成功，这凸显了用户测试的重要性，而非仅依赖直觉和专家意见。 ##### 1.4 集成A/B测试到发布流程 快速迭代的A/B测试可通过按需快速轻松进行生产部署、使用功能开关，并向客户细分群体同时交付多个版本的代码来实现。这需要应用程序栈各层的有用生产遥测数据。 通过功能开关，可控制看到实验处理版本的用户百分比。例如，将一半客户设为处理组，展示“购物车中不可用商品的类似商品链接”，比较处理组和对照组（未提供优惠）的购买行为。 Etsy开源了实验框架Feature API，支持A/B测试和在线逐步推广，其他A/B测试产品包括Optimizely、Google Analytics等。 ##### 1.5 集成A/B测试到功能规划 有了支持A/B功能发布和测试的基础设施后，产品所有者应将每个功能视为假设，并通过生产发布与真实用户进行实验，以证明或反驳该假设。实验应在整体客户获取漏斗的背景下设计。 例如，可构建如下假设： - 我们相信增加预订页面上酒店图片的大小。 - 将导致客户参与度和转化率的提高。 - 当我们看到查看酒店图片后在48小时内预订的客户增加5%时，我们将有信心继续推进。 采用实验性方法进行产品开发，需要将工作分解为小单元，并验证每个单元是否实现预期结果。若未实现，则修改工作计划。 ##### 1.6 Yahoo! Answers的案例研究 2009年，Yahoo! Answers用户增长和收入停滞，用户参与度得分下降。与竞争对手相比，其发布周期长，反馈循环慢。后来，团队转向每周部署，甚至多次部署，实验新功能的能力大幅提升。 在接下来的十二个月里，实验取得了显著成果：月访问量增加72%，用户参与度提高三倍，团队收入翻倍。为持续成功，团队专注于优化以下关键指标： - 首次回答时间：用户问题多久能得到回答？ - 最佳回答时间：用户社区多久能选出最佳答案？ - 每个回答的点赞数：回答被用户社区点赞的次数？ - 每人每周的回答数：用户创建的回答数量？ - 二次搜索率：访客为获取答案再次搜索的频率（越低越好）。 这个案例表明，更快的周期时间能显著影响结果，快速迭代和集成反馈能让我们更快学习并产生更大影响。 #### 2. 创建审查和协调流程以提高工作质量 传统上，审查部署变更时，我们常依赖部署前的审查、检查和批准。但这些批准往往由远离工作的外部团队给出，难以做出明智决策，且获取批准的时间会延长变更前置时间。 ##### 2.1 GitHub的同行审查案例 GitHub的同行审查过程是一个突出的例子，展示了审查如何提高质量、确保部署安全，并融入日常工作流程。GitHub开创了拉取请求（pull request）流程，这是一种跨越开发和运维的流行同行审查形式。 Scott Chacon描述，拉取请求让工程师告知他人他们推送到GitHub仓库的更改。发送拉取请求后，相关方可以审查更改、讨论潜在修改，必要时还可推送后续提交。工程师提交拉取请求时，通常会根据需要请求“+1”“+2”等审查，或“@提及”希望获得审查的工程师。 GitHub Flow由以下五个步骤组成： 1. 工程师从主分支创建一个描述性命名的分支（如“new-oauth2-scopes”）来开展新工作。 2. 工程师在本地提交到该分支，并定期将工作推送到服务器上的同名分支。 3. 需要反馈或帮助，或认为分支准备好合并时，打开拉取请求。 4. 获得所需审查和批准后，将分支合并到主分支。 5. 代码更改合并并推送到主分支后，部署到生产环境。 这些实践使GitHub能够快速可靠地向市场交付高质量、安全的功能。例如，2012年进行了12,602次部署，特别是在8月23日，公司峰会后通过拉取请求流程实现了563次构建和175次成功部署。 ##### 2.2 变更批准流程的危险 Knight Capital的失败是近期著名的软件部署错误案例。15分钟的部署错误导致4.4亿美元的交易损失，工程团队无法停用生产服务，公司最终被迫出售。 John Allspaw指出，此类事件通常有两种反事实叙述：一是变更控制失败，二是测试失败。但在低信任和命令控制文化的环境中，变更和测试控制措施可能产生与预期相反的效果。 传统变更控制可能导致意外结果，如延长前置时间、减少部署过程反馈的强度和即时性。常见的控制措施包括在变更请求表单中添加更多问题、增加授权层级或利益相关者、要求更长的变更批准前置时间。这些措施会增加部署过程的摩擦，降低成功生产结果的可能性，并减少工作反馈速度。 丰田生产系统的核心信念之一是“最接近问题的人通常最了解问题”。在DevOps价值流这种复杂动态的工作中，让远离工作的人进行批准步骤可能降低成功的可能性。 研究表明，精英组织能快速