今天培训的对象是老客户，但与3年前不同，这次从公司前台处走到总监办公室足足花了2分钟。沿途要经过他们的三个开发大厅：每个大厅坐着70到80人。规模与3年前相比，大了很多，新员工绝大部分是做项目开发测试等技术工作。总员工数量从不到200人到超过600，且还在陆续增加，所以虽然两年前才搬到这个3000平米的新办公室，现在也基本上坐满了。
我说：公司发展很快，跟三年前完全不一样了。
总监：是的，CEO特别支持公司的发展，在这方面做了很多投资。以前我还能喊出每个员工的名字，现在新人太多，很多都脸生。例如，只见这几百人每天在电脑前工作，但每个人的质量与生产率等差异却看不出来。为了管理好这么多人员，不得不依靠系统。
公司背景
多年来，这家公司一直做医疗IT解决方案,门槛很高,不仅要懂IT，也要懂行业知识。医院，或医疗机构，都对质量有要求。
工作压力也很大 —— 去年业务扩展很快，除了要增加软件产品数量以外，也非常注意客户满意度。总监觉得客户满意度主要由两个因素组成:
-
客户要的功能能否及时反应
-
能否提供他们确实要的东西
针对第二点，公司用系统记录了所有客户的问题，统计这些客户反馈的缺陷。要求过程改进小组，按月统计客户反馈的缺陷，看是如何逐步到得到改进、不断完善。公司也关心总研发成本。
以降低质量成本为目标
问：你们的业务改进目标是什么？
答：研发成本要降低。
问：具体是降到多少呢？
答：高层没说，只是说目标要降低100万。
我问：为什么定100万这个数？
总监答：其实我心里也没有底，但大老板很坚定要控制研发成本。必须要做，没有办法。但你不是说过容易达到的目标不是好目标，所以我们就定“减少一百万”要求过程改进小组自己想办法。如果最终没有想到更好方法，唯有减少测试工作，降低成本。
问：从需求到最后验收， 您觉得那个过程的缺陷返工量最大？
答：应该是越后越大
问：是的，而且返工工作量不仅仅按比例增加，是按倍数增加
例如，依据一些美国IT公司的统计:
| 缺陷发现与修复工作量 （人时） | ||
|---|---|---|
| 评审 | 系统测试 | 用户使用 |
| 0.3 - 1 | 2 - 20 | 33 |
但很多研发团队只依赖测试来保证质量,导致大部分缺陷都要等到系统测试甚至客户验收时才被发现。
| 如何通过提高评审效率来降低质量成本 (Economics of Software Quality) 质量成本由三部分组成: 失效(Failure)成本 把缺陷修复好的成本，包括在客户现场被发现的缺陷。 评测(Appraisal)成本 包括各类测试，如系统测试，集成测试，单元测试等，所花的工时 预防(Prevention)成本 包括技术评审 （注：有些人把评审归为评测成本，这里按 Mr.Juran 定义，归属于预防成本） 加大预防（评审）的力度，可大大减少失效成本（如测试和验收工作量） 例如，开发10万行代码（包含新增和变更）： 场景1:评审效率只有50%:
|
从以上例子看到，提高评审效率不仅能把交付给客户的缺陷减半 ， 更重要的是能够降低质量成本的失效成本，为了提高评审效率，工作量可能会略有增加，评测成本基本不变 。把代码评审效率从50% 提升到75% 便能节省 1,462 人天 [=（ 28.5-16.9）/8] （假定1人天=8小时），节省超过40%。注意：场景1与2 过程中评审或测试排除数基本不变，同样大概 9.9K，只是场景2 把2.5K测试缺陷推前在评审发现，但因修复系统测试缺陷要10人时，但修复评审缺陷只需0.5人时。不同公司的缺陷修复工作量可能不同，但只要后面系统测试缺陷修复的工作量比评审的工作量大，那么把缺陷从后面的测试前移到评审发现，便能大大减少返工的工作量。
评审通常包括需求、设计、代码 评审，另外可以增加架构评审，原型评审。例如，如需求评审有客户参与，效率/效果都会更好。
总监开心地说：对了，我们开发好像一直都没有太注意评审， 觉得浪费时间，也没有评审出多少缺陷。听你的例子，只是把评审效率从50%提高到75%便可以降低四成成本，如我们能从0%升到50%应该也能节省不少，我觉得降低一百万这目标应该有希望了。我马上要求质量部发布评审规范与过程，并要求每一个团队都必须按这个去做。
问：这个例子中的质量成本（主要是失效成本）降低了四成，虽然未包括开发本身成本，但确实也省了不少。但请注意改变人的习惯很艰难，不能单靠发布流程。必须先从个人习惯入手。你估计导致质量成本增加的主要原因是什么？
总监答：很多原因，例如前面需求没做好导致设计编码有误。
我说：去年一家我们辅导的公司，每次做完迭代冲刺后，都会叫上所有组员，包括产品经理、测试开发一起看看本次迭代的问题，讨论一下那几十个缺陷是源自哪方面？是否因为需求没做好？还是开发编码本身的问题？针对当次回顾复盘反馈最多的问题，并讨论它的根因后，在下一个迭代中采取一些针对性的改进措施，希望下一个迭代能减少对应的系统测试问题。
例如，有一次回顾时候就发现有一个功能升级模板，因为产品经理没有把握好客户的实际要求，导致我们那次迭代做出来这个功能不满足客户要求。虽然有做需求评审，但大家未能发现这需求问题。过程改进组就更新了需求评审检查单，增加一项，希望以后会减少同样的问题。另外，我们发现除了需求以外，还有很多是因为代码本身写得不规范，比如，有很多分支，常数也没有处理好。这些都在后面的系统测试和一些客户发现的问题反映出来。改进组便相应地加强了代码评审和代码规范的检查项和样例，来避免再发生同类问题。
总监问：有什么效果？
我答：其实大部分的缺陷都是人的缺陷防范意识弱，经过几轮培训与辅导，大家便更注意，主管也开始注重，后面的迭代，这类的问题就减少，不再是主要问题。
你们现在不是要求项目组在每个冲刺（迭代）后都必须要做个小组内部回顾吗？可否安排我参加，观察一下。
总监：正好我们下午应该有一个项目组要做内部回顾复盘(Retrospective)，欢迎您来看看。
从问题分析到根本原因到行动
我问：针对我们刚才一起找出的主因，根本原因是什么？如何可以避免同类缺陷再发生？
答：要加强对需求人员的培训，提高他们的能力。
总监说：我年初已察觉到确实很多需求没有表达清楚。导致开发出来的东西不符合客户要求,或不是客户要的。
我见过以下用户故事：
病人或他的家属能容易找到他选择的服务。 理由：他们熟悉网上购物，习惯了方便和快速的响应时间时间。
我问需求人员怎样才算容易找到，验收标准？
我估计她记得我说过需求必须可测量，她想了一会，说：验收标准：“普通病人能够在6秒钟内通过不超过三个动作定位任意一项服务。”
我说如果把‘普通病人’改为‘90%以上的病人’更好。
必须把模糊，有二义性的需求变成可以测量。
所以不能仅仅说 ‘新功能很酷，很创新’， 而应明确验收标准为：引入了新功能的三个月之内，60%的用户应该用它来完成规定的工作。75%以上的用户对产品表示赞许。
所以三个月前，我已经开始 准备正式规划产品经理与需求分析师岗位：要经过挑选，考试，然后培训，达标才能正式上岗。本来计划两周后会正式公告，现在既然你们问到，我就预告一下。
我说：既然高层已经有长远的规划，我们团队就应该针对下一个 冲刺，我们可以做到的事情。
项目经理说：我们每个岗位都已经尽了全力，没有什么可以做了。
我问：你们有做评审吗？如需求，设计评审
答：有。
问：需求评审发现多少缺陷，设计评审发现多少?
答：好像两三个。
问：发现什么问题？
答：记不清了，当时直接就修改了。
问：请问评审总共花了多少时间？多少人参加？
答：我们六个人，那次评审大概用了接近2小时。
问：2小时？
答：我们不仅仅发现需求问题，也一起讨论如何修改
问：如果评审只找缺陷，记录，应不会超过一小时，如果大家事前做好准备，估计可能半小时可以完成。所以通常检查（Inspection )不会当场讨论如何修改。
我接着说：我们刚才分析系统测试缺陷，不是识别出超过一半是源自需求吗？为什么我们不能在评审时预先发现？你们觉得可以下一个冲刺，评审时可以发现更多缺陷吗？
我立马用5分钟与大家分享有效评审能降提高产品质量，降低成本的例子。
答：估计应该可以，但不知道怎么做？
问：你们评审有检查清单吗？
答：没有。
问：清单可以帮助我们吸收以往的经验，避免以后同类问题再发生。例如刚才我们都识别了跟需求挖掘/分析/记录不足相关的具体问题吗？可否利用这些,更新评审检查单的检查项项，提醒我们要避免同类问题。如果大家同意，我们现在就行动。我们要改进 便要制定目标，例如计划下次需求评审，系统测试等各过程发现的缺陷数。这些目标你们可以下周一策划两周冲刺时定。
组长安排了小李更新检查单。准备在下次评审前与需求文档，预先发给参评人员。
我说：谢谢大家，我没有其他要说了，下次回顾，我或总监会来参加，看看冲刺的效果。
| 冲刺回顾与根因分析 回顾时对本冲刺的数据做根本原因分析 是持续改进的最佳实践。
|
改进要从个人数据统计入手
复盘会后，我找了团队的两位开发，她们都是在开发岗位工作了4、5年的女编程员，一位叫小萍(XP) ， 另一位叫‘Shirley’（S）
我问：大家觉得刚才回顾会后面的讨论怎么样?
XP过了一会说：以前回顾会都是问责，我们做开发的都不敢发言，说多错多。因为是我负责的模块缺陷偏多，我肯定不愿意在大家面前丢脸。到后面用 写便利贴方法 (她是指KJ法)，我就不怕直说了，其实以往的回顾会都是主持人（项目经理) 讲，我们只是听。
我问：你们觉得刚才在回顾里提到可利用加强评审来减少后面缺陷的返工怎样？
XP：有道理，但现在测试工具都很先进，立马就可以把缺陷暴露出来，为什么还需要 依靠人工查看代码，这样做不是更耗费时间吗？
问：好的，首先让我先理解你们现在的开发过程？
答：写代码编辑，先自己编译通过，然后自己手工测试一下。
（她们的表情好像在说：还听其他组员说您是软件工程20年经验的专家，还会问我这些低级问题？）
问：测试之前有没有做设计或代码的评审。
答：没有，因为时间都很紧，手工评审很耗时。
问：理解。但软件工程界统计过如果同样的缺陷等到系统测试才被发现，可能要好几天才能解决，但如果能在代码评审（或需求评审）中被发现，很可能不到30分钟便能解决。
一般情况下，你们需要花多少时间修复在系统测试阶段发现的缺陷？
答：没有正式统计过，差不多半天到好几天都有。
问：如果像Apache,Eclipse 那类超大型软件，很可能不止。如果要找出答案，便需要数据。例如，我们现在关心：缺陷数，评审工作量，缺陷修复工作量。必须要求每人在开发时，自己把数据记录下来， 以数据说话，到后面才知道有没有提升，返工工作量有没有减小。虽然通过评审尽可能早地发现缺陷是最好的， 但不能只依赖评审，必须也有单元测试。与评审一样， 单元测试也能帮助我们提前找出缺陷。
S:现在我们都已经用敏捷开发了， 同行评审好像都是上一代瀑布开发年代的事情, 是否已经过时?
我说：虽然敏捷好像不强调评审，但极限编程 (eXtreme Programming) 里有结对编程 (Pair Programming) , 其实也是一种评审。只不过不是等到写完代码后才评审， 编码的同时有人在评审， 所以敏捷并非没有评审， 目的都是希望尽早发现缺陷，防止遗漏到系统测试阶段。如果你们能在编码时能减少缺陷, 也同样能达到减少缺陷遗漏的目的.
S:是否应该通过测试后才评审代码?便可以针对有问题的代码，节省工作量？
我说：这个思路看来好像不错，但最大的问题是这会影响评审组找出缺陷的动力。因评审员都知道这软件已经测试过。
S:好吧，再前一步，是否应该在通过编译后才评审代码？
A:虽然各有长短。我建议先评审，后编译
例如编译通过不表示所有的编码格式问题都被找到。你们都不会再去关注代码的格式问题了，从而导致那些问题（可能10%）要到系统测试阶段才暴露出来。
我问：你们哪位知道如何制定锻炼计划准备六个月后可以参加半马比赛？
（S高高瘦瘦很运动型，我猜可能她知道。）
XP：必须制定很详细的每周锻炼流程，度量每次的时间、速度。
（后来我才知道XP她刚跑完半马，人不可以貌相）
我问：要提升个人的编码能力（质量，效率）就与准备马拉松一样，天天收集数据才知道新方法是否有帮助，有没有改善。你们有兴趣吗？
XP答：OK ，但S和我写不同的模块，收集数据是否只是供自己作前后比较？
我说: 很好的问题。两个月前，我们陈老师不是教你们用简化功能点来衡量项目规模吗? 如果像你们每个项目都使用功能点，你们的缺陷密度就有可比性了。
| 用功能点作为分母归一项目数据 要项目之间可以比较，成为公司级的标杆与基线， 必须要有项目的规模数，成为分母 但是缺陷数是无法比较的。 (项目缺陷数) / (项目的规模数) = 缺陷密度; 归一后便可比，建立公司基线。 |
XP:如何收集汇总缺陷，统计数据？
我说：先由开发人员自己记录，然后在回顾时，由项目经理和组长统一汇总到公司项目数据库中。大家也可以利用回顾，看看现在和以往的数据趋势，一起分析讨论。
我接着说：你们可以按照以下这个数据模板，记录下通过测试与评审发现的缺陷数量，与返工工作量，然后我们做统计分析。看看评审能不能帮到你们降低修复缺陷的工作量,最终能提高你的代码生产率。以下是以前两位编码人员的个人统计，可以看到如果能通过代码评审发现缺陷，代码生产率就越高：
Key: 评审效率 Yield = 代码评审找出缺陷数 / 代码引起缺陷总数 （=评审找出缺陷数+后期测试发现的缺陷数）
-
生产率 = 每人每周产出多少有效功能点 （FP）
你们后面也可以自己做出类似的图。
XP：听起来收集数据要花不少工作量，有软件工具自动收集吗？
我问：请问你跑半马前，如何做准备？
XP：比赛前六个月开始按定好的计划训练，并记录每次实际时间。
问：怎样记录?
XP：现代跑步的都有电子数字手表，记录每段的开始与结束时间，很简单。
我说：统计个人实际工时也类似，编码时记录开始与结束时间，不需要自动化工具。你也可以看看我以前的经验分享《个人如何写程序并记录》
难点不是在收集数据花多少时间，而是改变个人的习惯，您刚开始锻炼时估计也应遇过同类问题？
XP：是的，好在我们有个跑步团，我看大家都这样做，我慢慢便习惯了。
我接着总结说：当你们收集了多轮数据后，便可以分析并制定提升代码质量的策略：
每人都有各自的长短。有了自己的缺陷统计数据后。改进必须有针对性：哪一类的缺陷出现最多最严重？应选择哪个最弱的过程才容易有效果。
最后，预防胜于治疗，最终不能单靠评审与测试，更需要在编码时，注意避免引入缺陷。真是没有必赢的金科玉律，但有数据才有动力，才有方向，促进改变以往的习惯。好比减肥，必须每天测量自己的体重一样。（我看她们的两位体重都正常，应该可以提这个对女性较敏感的题目。）
| 一个半月后 的现场辅导 从过去三个冲刺回顾得到的数据，你们应该可以看出评审能减少遗漏到后面系统测试或者客户的数据吗？ 虽然质量有改进，还是不够。过去那些系统测试的缺陷数有没有一些可能是需求引起的？能否提前到需求（评审）被发现？ 但可能因评审人员总体经验还是不太够，所以你们可以考虑利用检查单提醒各位。 评审的主要关注点也应该预先用检查单形式发出来，让所有参与评审的人可以为评审预先做准备。 |
建立公司度量标杆(基线）与模型
四个月后，每项目组收集了五六轮数据。公司过程改进组长问如何分析数据建立公司基线。
我们就看了两个项目的迭代缺陷密度趋势图:
我问：你觉得怎么样？是否稳定？可否建立基线？（希望他可以自己找出答案，不仅仅听我的。）
他说：觉得P10比较好，波动的幅度不大，P2的差异太大了。
我说：是的，波动这么大，其实不用画控制图。
应先问问P2 项目经理变化这么大（68 - 145）的原因。确保数据正确之后，才可以分析数据，建立基线。其实这些项目数据量都不够。虽然如此，你还是可以告知两项目组这初步分析结果，但必须要提醒他们数据还未稳定下来。还记得我们培训时讲过以下基线例子，当过程已经稳定后（没有异常点）， 如有异常波动超越了控制图上下线范围，表示过程可能有基本变化。当变化后的过程稳定下来后，我们便需要更新基线。
[详见附件A3: 如何画ImR控制图]
分析项目数据，建基线
我问过程改进组长: 你们如何得出基线的？有什么分析？
答：这个就是我们各项目每个迭代的数据收集表，我就把以往所有项目的每迭代数据，统计所有数据，得出Q1(P25)、Q2(P50)跟Q3(P75)的数，成为我们的基线。
问：你有没有分析这些数据？会不会不同的项目之间不一样，导致你的总的基线需要细分一下呢？
然后我就举了一个我们用来培训的例子，对70个项目，收集了各种缺陷的统计，我们总体把缺陷归纳成7种类型。如我们按那个7种类型，各自看他的象限图的时候，明显看到他们是之间是有区分的，不能合并成一个基线，如果合并成一个基线，那整个基线的范围就太宽了，没有什么好的参考作用。从最低的0.3左右到最高的0.7。但是如果我们分成7组基线的话，每个基线的范围就窄很多，更有参考作用。
所以我们就简单地依据公司的不同项目，画出各项目的缺陷密度，看看是怎么分布。
问：所以你的基线不应该只是看所有的范围，而应该是针对这个稳定的取一个基线，针对这个这两个项目去考虑比较。因为这种比较稳定的项目数据基线，才更有参考作用。加入其它的项目只可能加宽基线范围，对后面项目作参考没有好处。
我再问：有了基线以后，你如何依据商业目标去制定你下个月的质量目标？
答：从商业目标，我们可以推算出缺陷数或者缺陷密度大概是什么水平？我们统计一下，平均一个缺陷的修复成本是112元左右。所以这个商业目标就可以帮我们知道，从业务目标每个月的缺陷密度要多少才可以有可能最终达到整年的成本降低计划。
我说:好啊，有了这个从业务目标得出的质量目标后,你怎么制定改进行动以达到规定成本降低目标？因为如果你没有什么基本的改变，理论上，缺陷密度或者缺陷数是不会降的。
我问：你们除了收集数据，有没有把过去每个迭代的质量相关数据标注在生产力发展趋势图上，让你们个人与团队都可以看到过去的变化？如果团队里个人之间的差异很大，这情况可能会按每个人统计更准确。
基线数据分析
我说：分析后，可以比较不同项目之间基线范围的差异。判断项目之间的差异有多大？是否合适归纳成一个总的公司基线。
除了按项目细分，也可以按其他维度细分（例如，按各种缺陷类型的比例。）帮你回答以下问题:
-
系统测试 / 验收测试缺陷从前面那个阶段遗漏下来
-
代码评审的效率(Yield)
-
效率是否跟缺陷种类相关？
如果差异很显著，就不需要使用 方差分析（超过2组） ， 双样本 T检验 （2组）方法判断分组有没有显著区分。
利用基线与模型制定质量计划
要降低最终测试缺陷率，不能单靠不断提醒自己要努力。要提升，也可以利用80:20原则， 针对占比最多的缺陷类型入手。
我们发现不良分支类占比最多。过程改进组使用KJ头脑风暴法，找出根本原因，并用加强评测/预防来减少失效质量成本的思路，得出以下对应纠正措施：
-
评测
-
完善评审检查单，增加与不良分支相关的检查项希望能在评审时检测出来。
-
预防
-
对应以下四大类根因种类的改进措施：
-
教育/培训 education 编码规范与培训没有明确要求
-
个人疏忽 oversight 忽略了要尽量避免不良分支
-
执行 transcript 因不良分支不是语法错误，IDE与静态检查代码都没有发现
-
团队沟通 Communication 组长安排编程任务与查看代码时没有注意
-
大家讨论后，除了改善规范检查单与培训外，也决定写个代码扫描小程序来暴露和数代码里这类问题，不仅仅靠人工评审查看。
= = = =
基于从项目收集的数据 - 每一个阶段的缺陷数，返工工作量范围, 过程改进组建立了一个水晶球蒙地卡罗预测模型[详见附件A5]：例如对每一个迭代
-
输入本迭代动态功能点数（规模）与各过程（需求/设计/编码）的缺陷率（引入多少缺陷）
-
输入需求评审各种方法的评审工作量和预估评审效率
-
输入设计评审各种方法的评审工作量和预估评审效率
-
输入代码评审各种方法的评审工作量和预估评审效率
-
输入代码单元测试的缺陷排除率
-
输入系统测试的缺陷排除率
-
模型便预测系统测试后的遗漏缺陷数，与返工工作量
因为要提高评审效率需要花工作量， 这模型就可以帮我们比较：哪个过程，使用什么评审方法，目标的评审效率，对缺陷数和质量成本的效果。
开始的时候，项目经理只能依赖经验来估算，现在有了公司的基线预测模型与性能目标要求作参考，便可以更好地制定本迭代的质量目标（各个过程，包括系统测试要发现多少缺陷 和相关的评审方法）。
无论是基线，或模型都是有它们的局限和不确定性。所以项目经理会除了参考极限与模型的预测外，还是会依据经验，综合考虑来制定量化目标和选用那种方法。
Key: 蓝色是以往的基线 - 绝大部分缺陷都是在系统测试才发现；浅绿色是量化质量计划的缺陷率目标 - 参考PPM(红线)，计划利用提高前期评审的效率，减少系统测试与验收缺陷密度
| 制定质量计划 从需求到设计、编码，如果方法没有变化，项目质量也不会改变。以代码评审为例，质量计划也要明确什么过程，选择哪一种评审方式。例如一般前端的代码,并非核心，使用简单的一对一或者代码扫描便可以了；但对于一些有逻辑处理的核心模块，可能需要用正式会议评审才能有效地找出大部分缺陷。 现在回顾复盘不像以前只是讨论哪些缺陷？哪些模块有问题？交给哪个开发去跟踪并处理？ 开发成员看到团队的趋势数据，就会想不断提升，保持和以往一样的同一个水平也不行，现在团队包括每一个成员都会关注质量生产率指标。 |
更新量化性能目标
我问过程改进组长：还记得六个月前，我问你们的改进目标吗？
答：当然记得，要降低开发成本一百万
我们刚做了回顾，从项目数据，基线，预测模型，并更新了目标。下图从高层目标关连到研发性能目标QPPO ：
我问：挺好，你们如何把高层的业务目标关联到开发团队的性能目标QPPO？
答：以前没有太多数据，到了3月份，我们就依据过去6个月的数据得出缺陷密度的基线——Q1: 0.27、Q2: 0.35、Q3: 0.41 (Note1)。依据这个基线，制定4月份的QPPO目标是Q1: 0.25，Q2: 0.34、Q3: 0.47,因为我们觉得中位数应该有些下降，但是不是每一个项目都具备强配合能力，所以估计向下那个范围还是跟以前差不多。
-
Note1: Q2=中位数 50 percentile,或叫P50 ; Q1= 25 percentile,P25 ; Q3= 75 percentile,P75
制定性能目标除了要有分布范围，例如 Q1 / Q2 / Q3 , 不再是以前升10% 的那种单点目标：
以前单点的话只会说均值从X%降到Y%（eg.来年希望降低质量成本25%）。但不会像这种从Q1、Q2、Q3，不仅考虑中位数也考虑范围。以前单点时可以说，是否达到预期的目标，只看中位数。这种考虑不够全面。现在我们有分布的概念，当被问到预期目标完成情况时,我们会说Q1达不到，跟以前一样，Q3也没有什么变化，但我们Q2 是达到本来预期目标。
改进效果
从建立第一轮基线后，过了三个月，过程改进组分析8个试点项目的改进效果，准备汇报给高层，发现8个项目的数据差异还是很大。其中有2个项目很明显看到有质量的提升、系统测试缺陷的降低、返工量的降低。有三个项目数据不全，而且也没看到太大的变化。有两个项目几乎就没有提供数据，过程改进组分析原因，发现和这个项目组的领导有关，两个有效果的项目，他的领导一直积极支持量化管理过程改进。
我看过程改进组好像对结果有点失望，就跟大家打打气说：
大家千万不要以为过程改进的路很简单，开始的时候反对声音大是很正常的，因为要改变一个人的习惯是很难的，但起码从这几个月的实验数据来看，我们的量化管理是有效果的。后面我们就可以利用这两个项目的经验，开始后面的改进。管理层监督都应该以数据说话，不应该只是听高层管理的一言堂。我相信再过几个月，会有越来越多项目组采用这个方式来加强管理。丰田的大野赖一先生在50年代推动精益管理时，也不是所有的主管听他这一套，但他一直坚持下来。现在不仅丰田，其他的日本汽车公司都以丰田生产方式(Just in time) 生产汽车，成为世界级的汽车生产流程。
总结
-
单靠统计分析是不会提高开发质量的，必须找到对应的方式，例如注重同行评审，不要等到系统测试才发现缺陷。
-
做好需求以减少设计与编码对需求的误解。
-
统计数据让开发人员可以“看到”到现在的状态与趋势，且分析新方法对提升有没有作用。
阅读总结
1.目标要满足SMART^ 原则，目标有分布的概念
-
^(S=具体 M=可度量 A=可实现 R=相关的 T=有时间 )
2.降低质量成本的方法：
定期复盘造成本次缺陷最多的原因，是需求原因还是编码过程不规范：从而加强代码评审和规范性检查，还是完善需求评审检查单。
3.质量抓重点：例如一般前端的代码。并非核心，使用简单的一对一评审或者代码扫描便可以了；但对于一些有逻辑处理的核心模块，可能需要用正式会议评审才能有效地找出大部分缺陷
4.检查单可弥补经验的不均衡。
5.收集个人数据
主要依赖手工收集，因很多是无法靠系统自动识别的 ，如缺陷源自哪个过程。
6.利用水晶球预测模型，帮项目组在策划时找最佳配搭
后记1 - 如何自动化
问：
我们现在最大的问题是，人员变动频繁，包括之前在过评审的时候，参加过您培训的同事，3年内人员基本上就会全换, 所以不能单依赖个人能力，必须有系统支撑，才能持续。
如果能够有系统（软件），只要培训一次，大家通过软件的使用就能够得到评估结果，并不断的根据系统的建议进行改进，并将改进过程也记录到系统中。
答：
赞同必须有系统（软件）支撑，不能单依赖人的能力。但自动化的程度就要看投入费用 与 回报（价值）。
在开始试点时。因为还在探索最佳流程，所以通常都是先把过程产出的数据 填在电子表单中，然后用工具分析。一些常见的改进方法：
-
代码评审可以引入一些自动化扫描工具，并制定卡点
-
自动单元测试应明确覆盖要求：如，代码分支覆盖率不能低于60%
| 过程 | 自动化方法 |
|---|---|
| 软件工程 | |
| 评审 | 用机器人扫描代码，如 sonar |
| 但很多设计的问题（如，克隆代码）sonar扫不出来，我们便提供其他代码扫描服务 | |
| 收集数据 | |
| 缺陷数据 | 缺陷管理工具, 如：JIRA |
| 规模 | 模板：把需求按 实体/行为 填，自动得到结果 |
| 工作量/工期 | WBS 项目管理系统 |
| 展示与分析 | |
| 数据画图与分析 | 水晶球（Monte Carlo） |
| 如：Minitab，JMP | |
当这流程经过项目实际应用并验证后， 有些公司会尝试把过程的某些环节自动化。
-
注意：
数据分析不一定适合全自动化。因五花八门，必须依赖人判断。（思路与大数据分析一样。）
后记2 - 改进成功要素
我与我们顾问团队做过程改进已经20年,最近内部回顾。
结论 -- 虽然过程改进的成功案例很少。但如果公司具备以下特性，有较大机会能成功量化过程改进：
-
公司人数在300以上，还在陆续增长，因为到了一定的规模，公司就不能再靠以前人治的方式来管理，必须有系统和数据
-
领导不满意现状 —— 有改进的意愿，因为过程改进需要人改变做事的习惯，而且开始的时候，领导会遇到各种阻力。如果高层动摇、不坚定，过程改进也会失败
-
除了高层外，还需要中层坚定的推动，把我们的建议落地，先试点再把这这些最佳实践推广到全公司，要求推动者要策划与执行的能力
-
也需要起码2名数据统计分析人员，收集数据并分析，因这工作挺耗时，如果没有这些资源的话，量化管理也是空谈
这个案例也具备上面这些必要元素。
后记3 - 如果客户需求驱动开发应如何策划评审
问：最近我们也碰到很多评审缺陷不愿意记录，因为很多当场就改掉了。如果不能当场改掉的才记录，所以会导致看起来数据很好，但实际情况却不理想。但如果全部都记录也会导致降低效率的问题， 包括测试人员和开发坐在一起，提了缺陷马上就改正，就可以发布了。
有时候，我也很困惑，流程是为了提升效率，但变成了降低效率。而且我们使用卡点后，流程都是有关联性的，所以一旦中间一个环节出错。就需要重头再走一遍流程。最近这种情况很多，我会有些困惑 -- 包括度量，到底是为了度量而度量，还是为了提升效率而度量。
答：评审有各种类型 - 检查（Inspections），走查（Walkthroughs），同伴检查（Buddy checks），环式评审（Circulation reviews ）...
各种评审有严有松，什么产出物用什么方法评审由项目团队决定按情况 预先定好。例如 检查最严，应只发现并记录缺陷，不是改正，见到太多正式评审花2.5~3 小时! 本应如大家准备好，应1小时内结束。
问：但现在是客户需求驱动的开发模式。客户当天提，1天之内就要回复，2天就要改好发布。
答：所以我们没有说所有产出物都必须做检查（Inspections）， 应按产物的重要性， 复杂度等，挑选最合适的评审方法 – 平衡发现缺陷的效率 与 投入工作量
附件
A1: 统计分析评审缺陷
因为每一个开发过程（测试除外）可能引入缺陷,为了提高交付产品的质量，希望测试之前的评审可以帮助我们更早找出缺陷，并改正。减小缺陷最终遗漏到系统测试/验收测试时才发现。
收集个人数据
主要依赖手工收集，因很多是无法靠系统自动识别的，如缺陷源自哪个过程。
每个缺陷数据包括：
-
属于哪个模块
-
缺陷种类
-
源自哪个过程 (如，需求)
-
哪个过程阶段解决
-
缺陷修复共花多少时间
有了这些数据便可以计算各评审的效率:
发现并处理的缺陷数/总共的缺陷数
注意：要到产品交付后才能计算各过程引入、排除 缺陷数
可如何提高评审效果：
-
利用检查单来提升评审小组如何更好地准备评审,能找出更多缺陷
-
编码规范 -- 作为评审时的参考依据
A2: KJ步骤
一种头脑风暴方法，每人把自己想法写在便利贴上，一起轮流把所有便利贴排放分组
-
把主题以问题形式写在大白纸的头顶；
-
把相关的事实写在便利贴上面，用黑色；
-
搜集相关的事实，如果是一组人的话，分散到不同人手上；
-
（团队）查看描述是否不清楚，是否要整理？
-
每人轮流把相关的便利贴组合在一起；
-
当每人都已经调整过便利贴组合后，一起把每一组便利贴加上一个题目，用红色标识；
-
红色的标题下包含相关事实的内容；
-
把相关的红色题目（最好不超过3个）组合在一起；
-
给这大组一个题目 – 蓝色；
-
在题目下放上相关的红色小组；
-
把蓝色的题目和剩下红色的小组或单独没有分类的便利贴都在墙上放好，也可以用一些箭头描述它们的因果关系；
-
（可选）
-
A 投票看看哪个是最重要的红色组
-
B 也可以加些总结性的描述
A3: 如何画ImR控制图
1/ 计算单值(X)平均数 (X-bar)
2/ 计算移动极差(mR moving Range)均值
3/ 利用以下方程式，计算X的上下限
-
UNPL=X-bar+(2.66*mR均值)
-
LNPL=X-bar -(2.66*mR均值)
4/ 利用以下方程，计算移动极差的上限
-
URL=3.27* mR均值
5/ 如果X或mR有超出范围，表示有过程变化的信号，过程不稳定
6/ 也不应该有连续8个或以上的点都持续提升，因这种发生的概率低于百分之一
Note:
-
UNPL=Upper Natural Process Limit
-
LNPL=Lower Natural Process Limit
-
URL=Upper Range Limit
例子:
1/ 计算单值(X)平均数 (X-bar) (X-bar)=0.135
2/ 计算移动极差(mR moving Range)均值 如第一移动极差为0; 第二移动极差为0.01;10点的均值=0.0128
3/ 计算X的上下限：UCL=0.170 LCL =0.100
4/ 计算移动极差的上限 使用上面公式 UCL=0.042 LCL =0
5/ 在2图中加上这些上下限与平均线：
A4:水晶球蒙地卡罗预测模型
-
按每个过程的统计数据，估计对应缺陷排除百分比的上下限与均值，工作量也类似。例如，从公司基线，代码走查的缺陷排除率是55%左右；评审总工作量（不包含修正缺陷）大概为20人时。如果开始时没有充足的项目数据，可以先依据行业基线：如代码正式审查应能排除85%，但平均人时会增加到35人时 （也是不包含修正缺陷）。得出下图：
-
模型会自动按输入的最大最小值计算标准差，变成分布（如：正态(normal)分布、三角形(triangular)分布），水晶球模型会依据黄格里的数字选取对应的分布。
-
取对应的分布，依据项目历史数据统计，估算各个过程缺陷的返工工作量与成本。例如：修复一个系统测试发现的缺陷，平均要用6000元，最高7500，最低5000。如果缺陷导致的如果是工时那行，填上对应工种的平均人时总成本。水晶球模型就会依据我们输入的范围估算单位成本的分布，放在绿格里。
-
如果从需求到验收测试，每一个过程的成本数都是单一值; 我们可以简单用 XLS 把数加起来得出总数。但如果每个过程的成本数都是一个分布，例如三角形分布,
必须要使用蒙地卡罗方法才可以把每个过程”加”起来。
-
水晶球可以帮我们估计质量成本的分布，例如我们需求评审用审查（2），设计评审用走查（2） ，代码评审也用走查（2），单元测试是手工（1），系统测试估计走3轮（2），验收测试预计走3轮（2），水晶球就会依据我们刚刚输入的分布用蒙地卡罗预测模型预估质量成本的分布。
-
比较各种不同的配搭，选出质量成本最低是哪个配搭组合，帮助项目组在策划时选择使用什么方法，得出最佳效果。
下图显示一直水晶球优化的过程，和最终的最“佳”配搭：
在需求评审，设计评审，代码评审，单元测试，系统测试，验收测试都有两种选择时，跑优化，95%的置信区间 得出 Overrall goal (Quality + Effort) = 1476773
References
1. Humphrey, W.: 软件工程规范 A Discipline for Software Engineering 2002.
4261
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
