10、软件开发速度维度：从传统到数据驱动的变革

软件开发速度维度：从传统到数据驱动的变革

1. 连续部署的挑战与思考

连续部署解决了许多传统开发相关的问题，不同的步骤显著缩短了反馈循环，尤其是在质量保证方面。然而，主要问题在于，即使产品按照规格运行，我们也没有数据表明它是否能最佳地满足客户需求。收集的数据往往侧重于系统性能和操作问题，大多数公司对系统哪些部分被客户使用，哪些功能只是纸上谈兵缺乏了解。

在大多数组织中，即使采用了连续部署，新功能的开发仍由产品管理驱动，并由研发组织执行。一旦产品管理确定某个功能的需求并进行优先级排序，无论如何都会开发该功能，这就导致了所谓的“开环”问题。产品经理根据对客户需求的理解来确定新功能的优先级，但在功能开发完成后，他们从不验证功能的预期商业价值是否真正实现，因为没有反馈循环，也就没有学习和改进。

简而言之，到连续部署这一步，重点在于把产品做对，现在我们需要将重点转移到做对的产品上。

2. 连续部署的实例

有一家公司在与主要客户的晚餐交流中，产品管理和研发负责人介绍了公司的持续集成工作、软件质量的提升以及即将发布的产品功能。客户提出希望提前获得新版本，因为新功能对其竞争地位至关重要。公司相关负责人同意调查如何帮助客户。

第二天早上，研发团队和测试组织得知客户请求后，制定了帮助客户的计划，并向客户说明风险和限制。客户同意在一家工厂进行有限试验，以解决质量问题并评估新功能的价值。

这个简单的请求显著缩短了新功能推向市场的时间，研发团队更加关注客户价值和质量，产品管理也有了快速重新确定功能优先级的途径。当然，连续部署并非万能，公司仍面临各种问题，如现场质量问题、人员负担过重等，说服其他客户采用连续部署在某些市场也很