1.3 五天太久，还能压缩吗
两年以后，投入巨资，耗时两年的一个特性发布终于RTM了。测试组织也适时提出了BCO发布可否从5天压缩到4天这样的挑战，最终的目标是配合集成团队实现每周两次的组织级构建，这是一个典型的持续改进的需求。通过在该特性发布上积累的数据，可以对其进行回顾，评价一下团队的表现，发现问题，进而明确改进的方向。
1.3.1 BCO版本发布用时分布
这是大家首先想到的需要分析的数据。如图1.3所示，在该特性发布的100多个Build中，有70%是在5天以内完成的。可以轻轻松松完成的Build极其少见，只有5%的Build在两天之内被搞定。
完成时间在4～6天所占比例总共有77%。当然，这个统计的背景就是平均每周这个团队工作在3个不同的发布上。
一开始团队的讨论和关注的焦点还是那些问题频出、超时严重的Build。这个统计结果出来以后，几乎所有人都同意。如果要去挑战或者实现4天的发布周期，最直接的方式就是将4、5、6天的数据向左平移1天。这说明需要重点关注和分析的是正常发布过程中是否还有可以改善的地方。
通过查看发布时间为4～6天的Build列表中每个Build的缺陷数，发现大量（大于20）的Build存在类似的问题。虽然缺陷数目较少（3个以下），但是，发布时间都在4～6天。这为后续进行的根因分析给出了有效的问题切入点。
1.3.2 缺陷压力测试
接下来出场的是版本发布用时与缺陷的关系。首先，根据图1.3所示的统计，平均的BCO版本用时是5.2天。图1.4所示的统计结果也显示，平均每个版本上有6.1个缺陷，而没有缺陷的版本数则占了大概5%，这和图1.3所示中两天内发布版本所占的百分比是相对应的。
如果把缺陷数量当作一个压力测试，那么第一个阈值出现在7个缺陷这个节点。在此之前，团队可以完全在5.2天之内完成一个版本的BCO发布。随着缺陷数的继续增加，团队承受的压力也越来越大，但是，也还是在相对可控的范围之内。一旦达到14个以上，整个平均发布的时间就有一个大幅的跃升，基本上就达到了发布时间不可控、版本质量崩溃的情况。
当然，这不是故事的全部。BCO是整个组织的“哨兵”，那有没有谁可以来做BCO的“哨兵”呢？而不是在高压下埋头工作5天，然后挣扎3天搞定一个Build或者最后不得不丢弃它。这样的结果既影响了整个组织的进度，也降低了团队的士气。
于是，就有人去统计安装缺陷的情况，结果非常让人吃惊。首先，有超过70%的版本是无法一次安装成功的。而安装缺陷对于BCO发布的影响是巨大的，因为它在测试推进的主干线路上。只要安装缺陷数超过 1 个，这个版本就会 100%出现延期。而如果数字增加到5和6，两条高耸的数据线就出现了。这和全部缺陷统计时的14、15天时间发布上的情形是类似的。感谢安装团队，没有出现更多的缺陷。看到图1.4有的团队成员直接就提出，以后超过5个安装缺陷，直接将版本丢弃。
图 1.3 和图 1.4 只是一个举例，其他如针对缺陷/模块分布的帕累托图分析等方法也是非常有意义的。通过这样的一个过程，整个团队基本统一了思路，明确了后续需要改进的地方。然后有针对性地进行改进，如更好地沟通、及时地排错、预防性在构建过程中增加安装步骤等。有意思的是，作为一个工作基本自动化的团队，所选定的流程改进的对象并没有太多关于自动化工具的，更多的问题点在于流程、沟通等有关人的问题上。工具或许能有效优化或者解决一些问题，不过在进行根因分析或者持续改进时，请更多地考虑产生问题或者改进问题的外部因素，也就是跨团队与跨部门的沟通问题，以及技术对于业务支持的可能性。这些都与软件工程师日常最为熟悉的软件、工具或者代码没有直接的联系，但是，这又是整个组织良好运作的基础。无论你是否意识到，整个公司并不是围绕着代码或者测试用例进行运作的，业务才是商业世界的主宰。