如何做好迭代回顾 1/4

迭代回顾(Retrospective)、二八原则、五个“为什么”(5 Why)、以数据说话、三点估算(PERT)等，大家都可能听过，在网上也能找到相关理论知识，但很多软件开发团队自以为了解，但其实是有误解。“如何做好迭代回顾”会利用一些实际团队问题说明应如何用好这些方法,分成以下四部分： 

1.回顾的成功要素与准备，包括：

• 根因分析是什么
• 应该针对那些数据分析
• 数据收集频率
• 应由哪些人来分析数据

2.根因分析的主要元素与误解

3.迭代回顾的常见问题与方法

4.利用缺陷排除率，针对如何把大量验收与系统测试缺陷尽早发现与解决，利用三点估算预测模型，把回顾从定性提升到定量

今次先分享第一部分

回顾的成功要素与准备

我们很注重产品的质量与客户满意度

有些高层都会说注重质量，但实际上只是应对客户投诉，属于“救火”，不能避免同类问题重现（附件“我们很注重产品的质量与客户满意度”是一例）。敏捷迭代回顾，因团队刚做完冲刺，对问题还有印象，大家讨论出的纠正措施也能立马在下一轮冲刺试用，所以迭代回顾是让团队持续改善的最好时机。

= = =

质量大师 Dr JURAN 强调，过程改进应从不满意当前质量水平开始。如果大家都觉得现在的质量水平(例如，验收测试缺陷数量)是正常的，那么任何质量改进计划都不会有好结果。
如能利用根因分析做好迭代回顾可以使改进从“救火”变成“预防”，回顾时分析必须基于数据，不然只是基于个人主观判断。为了达到最佳效果，必须挑选影响度最大的因素，使纠正措施更有针对性。所以收集到项目数据后，首先利用二八原则识别出哪类问题的影响最大。在软件开发中，如想提升团队生产率（降低工作量），应先探索哪类工作最耗费工时。

哪里最耗工作量

请你把过去一年的软件开发项目，按不同工种占项目总工作量的比例，从最多到最少排个序? 编码与代码设计 交付后的所有工作，包括维护、更新与缺陷修正 交付前的评审，静态扫描，测试与缺陷修正 项目管理与监控

可看本章附件中的“开发项目工作量（成本）分布”，看你的选择与‘典型’分布差多远。

软件开发项目最大的工作量通常是花在找出与修正缺陷上（开发里的‘测试与评审’，详见本章附件）， 根据专家Capers JONES 先生在2012年的研究，对于超过10,000功能点、计划使用25年的大型系统，接近一半的工作量都是与找出与修正缺陷相关。

= = =

接下来，我继续与总监分析，目前他们项目中的缺陷大部分还是到后期才发现，这导致了大量返工。如果能提前发现并解决这些缺陷，就可以大大降低研发成本(不仅仅是提升产品质量):
我问：通常，你们在项目的哪个过程中发现的缺陷数最多?
总监：系统测试阶段

（绝大部分公司都类似：发现缺陷最多的是在系统测试阶段，验收测试阶段其次）

我：用于测试与缺陷修复的返工的总工作量占整个开发项目多少？

总监面有难色，觉得他身为技术总监本应知道答案。 （其实很多技术领导都没有概念）

在白板上，我首先用项目工作量分布数据，说明‘找出与修正缺陷’占了最大的工作量，接着我缺陷与返工数据说明如果能把后面发现的缺陷，提前发现，可以节省多少工作量。我举例，如果能加强评审、扫描预先发现缺陷，用原型与客户交流减少需求引起的缺陷，能把最终遗留缺陷数从本来的227降到43（降低81%），但总工作量不升反而降，从898工时降到685，所以提升质量并不会增加工作量（成本），反而能降低，总监觉得不可思议，因为他已经习惯了越到后面阶段，发现的缺陷越多，觉得这是常态。 （如何利用缺陷排除率 (DRE)减少返工，从而降低质量成本的方法，会在后面“从定性到定量”里详细分析。以上估算，详见附录“估计缺陷前移能节省多少工作量”）

如果管理层了解如能尽早发现并排除缺陷是很好的改进方向，并重视，公司才有机会改进/提升。

有些偏业务的领导可能质疑客户不一定关注缺陷密度，只要达到可接受的水平，便可以。 我解释“在软件开发减少后面测试才发现的缺陷，不仅仅提升产品质量，更重要是能降低研发的总工作量，所以最终能帮助老板省钱。”（详见附件“公司高层不一定关注质量”）

数据收集

“如何能收集到修复缺陷相关工时数据？因没有度量，便无法谈改进。我们现在只有系统测试缺陷数据，与测试工作量数据。”这是很多研发经理想解决的问题。
收集软件开发数据不容易，但如果没有收集到可信的数据，便无从分析与改进。
是否可以靠组织级加强这方面相关的度量与监控？我们先看看一家过万人的大公司（主要提供金融软件产品），公司一直都很强调量化管理，收集各种项目的系数，度量并分析。

自动化统计分析

质量部经理：我们每次都跑全量，公司引入低码平台，主要针对需求设计阶段做好质量保证， 所以我们很注重量化质量管理，能否通过自动化来统计分析？ 如何通过量化或工具方式实现自动评审？

我：为什么要自动化？

经理：从去年开始我们事业部，对应高层要求，开始大力推动度量分析， 发现员工就会造数据， 结果导致失真， 度量哪里就造哪里， 所以还是想通过工具代替人工方式，除了能提升效率，也能帮助判断数据是否合理。
现在我们主管对度量很反感，觉得每次要分析度量数据就有人造数据。

我：度量本来是件好事。

经理：是的，就是大家知道算法原理就开始造假。 因为我们搞了红黑榜， 但很多人头脑都很聪明，会想办法，但用于不合适的地方。

我们有很多数据统计分析，比如看测试用例与需求的比例。 其实客户发现的缺陷比例也降低了，但因为我们这行对质量特别注重，产品经过多年的逐步演化，过程很复杂，导致软件缺陷的修复很耗时，客户不太满意。 而且公司要求交付的频率要比以前高了很多，我们团队做这些分析都忙不过来，所以需要员工设自动化工具等加快速度才可以。
让我给你看看我们大数据分析。。。

我：等等，但我们首要解决如何能收集到真正的数据，不然数据分析没有意义。

客户：好的，有什么建议?

我：还记得我们上次交流，要让团队自主，不能单靠标准过程并用指标监控执行情况？

我：请问你们是采用左面还是右面的方法做过程改进？
经理：好像我们现在度量分析是采用你图里左面的方法。

我：是的。总体分析还有另一不足:各个项目特性不一样，你们现在总体分析几十个项目数据， 很可能找不到真正根因，因每个项目的问题（根本原因）可能不同。 比如，同样是一个测试用例比例数，你们的范围就很宽 - 从最低的0.3到最高的超过200！但你们取平均值5.1 来做分析。
收集数据也是问题，因收集几十个项目数据是挺花精力，而且要很长时间完成数据收集。

经理：完全同意，我们收集一轮，并分析汇总，便要用3-5周，所以想自动化。

我：但不同项目各有特性， 这些辛辛苦苦做出来的分析报告其实不仅仅是给高层（或者项目经理）， 要每个团队成员都看到才有意义 。（度量分析要反馈回数据提供者，他们才有动力继续收集数据）要把那些分析好的报告再跟每一个团队成员解释上要花多大精力？

度量的主要目的是从数据分析找出根因做改进而不是仅仅为了监控

如果把数据分析下放到团队自己搞，便灵活多了，不仅可以节省沟通成本。也正因为他们有参与收集和分析讨论，他们会更有动力改善。 所以你们几位经理应该重新定位自己为内部老师，辅导团队怎么做好数据分析，效果会更好。

经理：让团队自己讨论便可以得到改进吗？不需要我们？

我： 如果团队有能力，应该放手让他们自己利用收集数据，分析并做改进。你们应重新定位为团队的教练，辅导他们如何收集与分析数据。千万不要误以为这工作比以前自己做分析轻松，其实你们须要更熟悉，才能真正辅导好团队。但因你们之前有经验，所以辅导团队应不会太难。更大的挑战反而是要管理层了解并赞同敏捷开发需要团队自主的思路。

数据收集频率

几个月后，质量经理问：“请教你有没有讨论客户满意度与产品研发/质量/过程改进之间关联的文章？我想从研发改进或质量改进的角度，如何正向推导出帮助提升客户满意度的方法。”

（公司一直都很注重每年做客户满意度调查，高层也会参考满意度系数作为KPI之一，定绩效，决策公司资源投放等。）

我：我没有你这类分析文章，但有写过客户案例分享：香港公司，他们在广州有开发中心专门为香港的客户做软件维护工作，他们项目采用 SCRUM 敏捷开发，两周冲刺，他们每次做完迭代后，客户都会填写满意度调查，然后分析数据。(这分享文章的部分内容，详见附件：“分析迭代客户满意度调查数据”）
经理：我刚看过你发的案例，挺好的，但我想要的不是想依据分析每次迭代的客户满意度让团队做过程改进，想更宏观。我们每年有独立部门做客户满意度调查，已经连续了十年，高层也会依据调查的结果判断是否继续让事业部投放资源，也影响到员工绩效等等，所以部门都注意，但后面越来越发现那些数据的作用不大，因为各事业部都清楚客户满意度调查分数很重要，高层也关注，所以都会在调查之前拜访客户，做好准备，确保结果不会太差。
我：你们做了这么多年，自己应最清楚问题所在，你觉得现在的做法有什么不足？
经理：因为客户满意度调查是每年随机抽样一些客户来做，因为是抽样，我们是每年年底做一次，有些时候可能项目在头半年四五月已经结束了。到年底时，客户对很多几个月前的情况都忘记了。
我：是的，为什么不在发布后立马就做？
经理：这工作是由独立部门做，因工作量比较大，他们都每年独立策划安排。其实我们也有在项目发布后做调查，但维度没有年度维度这么宽。只是一些简单的高中低客户打分，由前线人员直接去做。
我：为什么不能安排你们的客户满意度调查也是按项目的结束时间去收集，不是就更及时吗？
经理：主要是他们的人力有限，资源有限。
我：这个不太说得通，我没有说你每次发布后做调查便需要增加工作量，你们还是可以按随机抽样，但及时性就好多了，不会等到几个月后才调查。你们为什么每年年底做调查并更新标杆？
经理：还有另一个原因，高管很注意客户满意度调查的结果，会用来判断部门的绩效和对事业部的资源投放，所以调查需要与公司每年年底预算同步。
我：标杆（基线）的更新不应每年更新一次，而是应按实时变化，如果有显著变化便应更新。还有一个问题，你刚才不是说因为你们那些客户满意度调查的结果会用来判断部门的绩效和对事业部的资源投放，所以肯定业务部会非常注重，想尽办法能得出好结果，比如预先拜访等等。其实这个会污染了数据本身的正确性，也是影响了数据的可信度，零数据变得不客观。
经理：好的，我会依据你的建议，明天讨论如何改革客户满意度调查时，提出建议。

结束语

• 为了确保质量应该用精益的概念。每一小步确认限制级，确保达标。然后与客户确认，而不是
• 很多改善只是“救火”，没有针对根本原因，问题还是会重现
• 如果要从“救火”的管理思路变成基于根本原因找出预防措施的思路，就需要管理者‘放手’，让团队自己收集数据，自己分析与制定纠正措施。
• 利用二八原则识别出哪类问题的影响最大，让根因分析后的纠正措施能达到最佳效果
• 收集数据很重要：缺乏数据的根因分析只依赖个人主观想法
• 大部分软件开发的数据都需要依赖团员收集（不能依靠系统自动生成）
• 让团队自己分析数据，做改进，他们才有动力在每次迭代冲刺回顾时收集数据
• 除了收集团队内数据，也要收集客户的意见，才能全面看清问题
• 如果把数据与绩效相关联，很可能会“污染”数据，影响数据的准确性
• 数据有显著变化时，便应更新基线，作为标杆参考，让团队知道水平在进步还是退步
• 先定一个总体的几个月计划。按总计划监控任务是否延误？因为后者会把团队的关注点都放到按时交付去，无法确保最终的产品达到高质量要求。

• 迭代回顾让团队可以每走一小步，回顾有那些不足，分析根因，下一步做改善。如果要从“救火”的管理思路变成基于根本原因找出预防措施的思路，就需要管理者‘放手’，让团队自己收集数据，自己分析与制定纠正措施。

附件

开发项目工作量（成本）分布

参考Capers JONES先生 2012 的例子，汇总成以下比例：

测试与评审一般占开发工作量的30%

测试与评审一般占总质量成本（包括发布后维护与改缺陷工作）的66%

把所有工作量都加起来，测试与评审还是占最大(26%) , 编码第二 (22%)

注意：‘测试与评审‘包括所有与缺陷相关的成本，包括单元测试、静态扫描、 评审与相关的缺陷修正， 而编码只包括设计与编写代码部分。 例如，有些人会觉得比例应该是： 开发30%，测试和bug修改25%，需求和设计20%，项目管理和沟通20%，文档5% 但如果按上面的定义，开发部分很可能已包括单元测试、静态扫描与改正缺陷工作， 如把这些都归到测试评审里会变回类似上图的比例。

公司高层不一定关注质量

Q&A 问：在传统 IT的 公司，无论是 缺陷(Bug) 率还是其他质量指标对业务的影响的相关性都不容易度量，只有重大事件才会让公司在客户面前失去信任，所以高层不会真正的重视质量。 答：理解，但软件BUG的暴露越往后，返工的工作量就越高，而且是几何级数的增加（例如在单元测试或评审发现都可以1人时内解决；系统测试通常要花起码20人时，客户使用后才发现便更高）。但在很多IT公司，大部分缺陷都是在系统测试、甚至到验收测试才发现。如果能把软件缺陷的发现前移，把通过系统测试、验收测试发现的缺陷减半，便可以大量降低质量成本，提升开发生产率。所以我建议上面北京公司的质量总监利用缺陷数估算返工的工作量来引起老板重视。（而不是仅仅说降低缺陷率） 问：有些业务客户可能不一定关注缺陷密度。举例：有些互联网公司关注系统的高可用性（按电信标准的99.99%可用），因为高可用性会给业务上带来稳定的广告展现机会，也就是广告的库存。他们也关注上线后低异退率（如，上线后异退率：3/万，异退是各种复杂原因的异常退出），异退会对用户流失产生正相关的影响。 答：系统的可用性，异退率等指标，也是可以连续收集到的（如，每天、每周），同样可以用上面深圳企业的方法，画控制图，预警过程有没有异常变动，如有异常便要启动根因分析，找到过程异常的根因，避免等到客户投诉才救火。

分析迭代客户满意度调查数据

案例背景

香港公司在广州的离岸软件开发中心，专门为香港的客户，如政府部门，做软件维护工作。从2019年，项目已经开始采用 SCRUM 敏捷开发，每两周冲刺，他们每次做完迭代后，客户都会填写满意度调查，然后分析数据。

迭代数据

每次迭代团队都会收集以下数据：

• 客户满意度调查（Cust Sat survey）
• 需求变更请求次数（Requirements and Change Requests）
• 系统测试缺陷数（Test defects）

数据分析

• Overall满意度（整体指标）与7~8个因素相关，而与其中的Deliverable Quality相关系数达到0.90，Deliverable Time 0.688左右,其他的相关性都较低。

• 测试缺陷数和以下客户行为相关性如下：插入任务 0.51，需求模糊 0.66，初期没有需求问题 -0.45，需求不稳定引起返工 0.82。（详见下图）

（为什么初期需求模糊反而是-0.45：等需求明确，写成文档，导致后期才能给明确需求，反而比早期给个模糊需求好，因更可能引起返工。）

若能写好需求，减少插入任务和变更，可以提升质量（降低测试缺陷数）。

改进措施

• 固化Clarification流程。当前是较为随机，由开发人员发起（统计数据中每个迭代0~2次），后面优化Clarification 过程，要求每次迭代都必须做需求Clarification，形式也更正式，明确甲乙方那些岗位必须参与，什么角色，确认新过程有效后，更把过程固化下来。
• 把需求Clarification 要具备的重点写成检查单，增加检查向，如：
  • 需求是否完整明确
  • 是否按简化功能点方法写清行为、实体
  • 场景是否明确
  • 能否有对应明确测试用例（是否可测试）
• 请甲方尽量减少插入任务和变更。

改进效果

除了客户满意度得到提升外，冲刺生产率也提升，例如：
生产率之前四分位数是 (1.07, 1.13, 1.16) ，采取控制插入任务，减少变更，做好Clarification等措施后，有明显改善，变为 (1.04, 1.05 , 1.08) 。
（注： 它们生产率 = 人天/功能点数 ， 所以生产率系数是越低越好）

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = 

附录

估计缺陷前移能节省多少工作量

有些人会认为尽早发现并解决缺陷 对质量肯定好，但会耗费工作量，增加项目成本，老板不一定愿意。 其实是反过来，如能在前面预先发现并修正缺陷， 便能减小后面测试和修改缺陷的工作量， 最终只会减少总项目工作量。

比较以上两种策略的质量成本(COQ)就能看出：

• 增加测试前扫描与审查，并加大测试效率，不仅减少最终缺陷数到54（对比227），也降低总质量成本（总人时）

假设：每项任务的固定成本都是25人时；测试前的缺陷修复：每缺陷用 0.5人时；测试缺陷修复，上面计算假定每缺陷用1人时，详见下表： 每缺陷修正工时 扫描/评审 0.5 单元/功能测试 1 系统/性能测试 1 验收测试 1 通常测试里的缺陷修复每缺陷不只一人时，例如，在验收阶段时可能要用20人时；我通常会打开这XLS 表，填上客户的估计值。从上表看到，即使用最少的1人时来算，还是不亏。

因为缺陷已经提前被排除系统测试的缺陷减少，测试阶段的工作量减少大于前面扫描评审上的投入。

可以进一步利用COQ概念，增加早期预防缺陷措施，如用原型与客户交流，做好需求调研，进一步减少缺陷，和成本。 例如，使用原型与场景与客户挖掘需求，可进一步把缺陷降到43，也降低总质量成本：

注：你可能会质疑使用原型方法不只25人时，但即使加大到100人时，还是不亏。因它能预防缺陷，整体缺陷数下降20%，使总质量成本下降超过100人时。