2.4　软件交付过程追求的目标

本书聚焦于软件交付过程，也就是刨除了前面的设计、编码，以及后面的运维、运营后，中间这段从改动代码到软件发布上线的过程。这个过程要追求的目标是什么呢？

更高的产能，也就是在单位时间内能生产多少新特性，交付过程对它有一定的影响，但相比于对响应速度的影响，交付过程对产能的影响一般不是特别大。粗略地讲，在代码编写和交付这两个环节中，谁的产能低，谁就是瓶颈，谁就决定了从改动代码到软件发布上线全过程的产能。通常代码编写的产能低，是瓶颈。而如果瓶颈都跑到了软件交付这一环节，就会出现这样的现象：越来越多已经开发好的功能积压在一起，等待集成测试和发布。这样的交付过程就太差了。为此需要改进流程和工具以提高效率，也可能需要调整人力资源在代码编写和交付过程中的分配。

在讨论产能时还有一个因素要考虑：资源聚焦。在开发团队（包括开发、测试等角色）总人数不变的情况下，如果通过改进流程和工具，提高了每个人在交付过程中的工作效率，减少了在交付过程中人力资源的投入，就可以把更多的人力资源分配到代码编写中，于是让整体产能更高。比如用开发人员自测试来部分代替测试人员的工作，就能明显减少开发人员与测试人员之间的沟通交互，降低沟通成本，同时可以尽早发现问题，很快定位和修复，提高效率。于是，开发人员占比就可以更高，开发人员投入到代码编写活动中的时间也可以更多。

更快的响应速度，跟软件交付过程很有关系。最理想的情况应该是写完代码就发布上线。中间既没有等待构建的时间，也没有等待部署、测试、代码评审、上线审批和上线时间窗口的时间……于是，一个特性从需求到发布的总体响应时间大大缩短。

当然这只是理想情况。我们要追求的是，让这类时间尽量短。更严谨一些的表达是，对用户有意义的一小块儿完整的代码改动，也就是一个特性，从开始开发算起，其中在写代码之外还需要耗费的时间，反映在关键路径上要尽量短。这是我们要追求的目标。

形象一点儿，一个试探市场反应的MVP，如果写代码需要三天，上线却要等三个月，那不得把产品经理急死了。但是通过改进，做到一天后就上线了，这对于响应速度的提升是非常显著的。

适当的质量，这一条也跟交付过程强相关。软件交付过程的主要精力就是花在保证质量上。质量不是越高越好，在软件交付过程中不能因为一味地追求质量而无限延长测试时间，而是要通过软件交付过程达到一定的质量要求。但究竟质量要求有多高，这是由特定业务决定的。

合理的成本——同理，这一条也适用。比如，对于持续集成服务器等硬件，配置好一些有利于提高软件交付的速度，但这也肯定不是无上限的。

尽管软件交付过程要追求的一般目标也是“多、快、好、省”，但对它们的关注程度是不同的。关键是要快，快点儿达到业务所需要的质量，让一个特性开发完很快就能上线。

[1]定义侧也被称为产品探索（Product Discovery），实现侧也被称为产品交付（Product Delivery）。请参考Marty Cagan演讲中的相关内容（链接1）。

[2]参见《SRE：Google运维解密》一书。