在实现需求的过程中，我们要兼顾效率和质量。
效率包括需求吞吐量和需求响应时长，前者是产出的数量，后者是产出所需时长。
质量包括问题出现量和问题修复时长，前者也是数量，后者也是时长。
效率和质量，数量和时长，它们之间的排列组合构成了四个象限，如图1所示。

图1四个象限
当然，除了图1展现的内容，我们还需要关注可持续性。
可以认为，图1的第三个维度是时长维度，随着时间的推移，软件的规模和复杂性都在不断上升， 可不要让这四个象限逐渐失控。
下面我们逐个分析四个象限，讨论软件交付相关的事情该怎样做，以实现在四个象限的优化。

01
提高需求吞吐量
需求吞吐量是指在投入的人力物力一定的情况下，在一定时间 内能够实现的软件需求的数量。
提高需求吞吐量，就是要高效、要多“出活”。在软件交付过程中，自动化是提高效率的重要方法。
所有重复性的操作（如 构建、部署等）都应该是自动化的。基于明确规则和算法的测试（如代码扫描） 及不断重复执行的测试（如回归测试）也应该是自动化的。
此外，我们不仅要把单一的任务变成自动化的，而且要使用流水线把各个任务串联起来，让它们依次自动执行，实现流程的自动化。
做事的效率，一方面是流程中一个环节又一个环节的执行效率；另一方面是当遇到问题或发现问题后，解决问题、修复缺陷的效率。
对于前者，自动化是提高效率的重要手段。对于后者，及早发现以便及早修复是提高效率的重要策略。越早修复，需要花费的人力和时间就越少，效率就越高。
当然，要想早修复，就 要早发现，就要更频繁地构建、部署、测试。这就又需要自动化的支持，以降低 频繁构建、部署、测试的成本。
以上两点是最重要的两个思路，当然还有其他一些方法，《高质效交付：软件集成、测试与发布精进之道》一书后面章节会详细介绍。

02
缩短需求响应时长
如前文所述，需求响应时长是指一个需求从交给开发团队到最终发布上线的总时长，这期间会发生与软件编写相关的各种活动，以及与软件交付相关的各种活动。
在软件交付范围内，如何缩短需求响应时长？
缩短等待时间，特别是缩短在关键路径上的等待时间，可以缩短需求响应时长。
协作导致等待。当不同的角色协作时，他们往往会相互等待，如图2所示。
例如，在代码评审时，甲编写完代码后，等待乙评审；乙评审出一堆问题后， 等待甲修复和回复；甲修复和回复后，等待乙确认……再如，开发人员完成代码改动后，等待测试人员测试；测试人员测试出问题后，等待开发人员修复；开发人员修复后，再等待测试人员确认……

图2 协作导致等待
怎样减少这类等待呢？
第一个思路是，代码编写者在送交代码评审、测试之前，先自己多做测试，以减少问题的数量。
第二个思路是，让不同角色在一个团队中长期共同工作，随时相互支持。
反之，如果测试团队同时向多个开发团队提供服务，多个开发团队之间争用测试人员，那就会带来很多协调成本，人员安排 也难以根据实际情况随时调整。
除了协作导致等待，批量也导致等待：要凑齐一个批次再一起进行下一项工 作，如图3所示。

图3 批量导致等待
这可以通过减小一个批次所包含改动的量来改善。例如，不要积攒很多改动再集成，不要积攒很多开发完的功能再测试，不要积攒很多测试完的功能再发布。这是持续集成、持续交付的基本思路。
软件交付过程在需求响应时长方面最重要最直观的指标是，当一个特性（如一个用户故事或一个线上缺陷的修复）开发完成后，多久可以发布上线。
最理想的情况是，编写完代码后瞬间就发布上线了。当然这只是理想情况，毕竟构建、部署、测试等还是需要时间的。
我们要追求的是，让一个特性从开发完成到发布上线的时长尽量短些。

03
减少问题出现量
我们已经分析了效率相关的两个象限，下面分析质量相关的两个象限。
再次强调，我们这里说的质量都是结果质量，也就是最终发布给广大用户，让用户感受到的质量。
质量相关的第一个象限是问题出现量。
如何减少问题出现量呢？
在软件编写过程中，如果开发人员能力比较强，工作比较认真，那么其埋下的问题自然就少。
如果软件架构设计得好，技术栈先进且适合业务场景，那么软件自然就不容易出问题。这些都对，但是不在软件交付过程的关注范围，我们按下不表。
软件交付过程能做的事情是通过各种测试找出这些问题，然后把它们消除掉， 于是就减少了在生产环境中出现问题的量。
当然，并不是要把所有问题都找出来，为了完美而投入无限多的测试资源和无限长的测试时间。
要通过软件交付过程达到多高的质量目标，是由特定业务场景等因素决定的。我们通过有效率的测试和随后的缺陷修复，达到这样的质量目标。

04
缩短问题修复时长
四个象限中的最后一个象限是问题修复时长，这是指线上问题的修复时长， 包括故障的修复时长和线上缺陷的修复时长。
我们要尽量缩短这个修复时长。
我们要早点发现问题。
我们在发布后要做一些测试，哪怕只是使用鼠标简单点一点也好。
当然，如果我们自动化地测试一下核心业务流程，那就更好了。
此外，要加强运维监控，当出现异常时自动报警。舆情同样要监控，以便当有用户抱怨时，我们能早点听到。
当发现问题时，我们要及时通知合适的人，以便早点开始行动。例如，在发生故障的时候，我们应该按照故障处理流程立即动员相关人员进行会诊和排查。
我们要尽快处理好问题。对紧急程度不同的问题，我们应该有不同的处理方法。
当出现最紧急的情况，如严重问题的时候，我们需要“立即”解决问题。我们通常应该立即回滚生产环境中刚部署的版本，回滚到上一个发布版本。这样做最快，尽管这样做会把刚上线的新功能一起回滚掉。
当出现次紧急的情况时，我们要紧急发布一个新版本，该版本只包括为某个线上缺陷或问题所做的代码改动，不包括其他新功能，以便尽快发布。
对于紧急程度再低一些的情况，我们应当在项目排期时给予它们较高的优先级，争取下一个正常发布版本就包括对它的修复。
以上四节分别分析了在四个象限中软件交付过程可以做哪些方面的改进。不论你打算做什么样的改进，最终一定要落实到对某个或多个象限的正向影响，这样的改进才是一个真正的改进。这四节粗略给出了一些改进软件交付过程的思路，《高质效交付：软件集成、测试与发布精进之道》一书后面章节将展开介绍它们。

本文节选自《高质效交付：软件集成、测试与发布精进之道》一书，更多关于高质效交付的内容可阅读本书。