如何做好迭代回顾 3/4

分析事故根因：下集

我：陈总，听说你三年前开始锻炼马拉松，所以现在身体这么好，有什么心得可以让我学习一下？
总经理：本来我很胖，也常常很困，体检指标不太理想，我听说可以用长跑锻炼身体，便开始尝试。开始的时候并不容易，因为一直都没有锻炼，先跑五六公里，按程序逐步提升，后面便慢慢养成习惯。最终经过三年锻炼完成马拉松，身体也觉得比以前好多了。
我：开始的时候，请问您怎么去持续维持，因为很多人还是一时冲动去锻炼，但持久不了，例如买了跑步机，但一两次后面就没再用了，您有什么心得可以让你持续下去？
总经理：现在支持长跑运动员的度量挺多，最简单的指标就是一公里要多少分钟。我就一直都有度量这个系数来监控进展。比如我开始的时候一公里要接近八分钟，跟走路差不多，后面慢慢就变成七分钟，六分半，六分钟。。。是锻炼出来的，所以有了这个数，我就知道自己现在是什么水平，是否在进步。
我：好比每天跑步锻炼，如果没有手表帮你度量时间速度，你是不知道是否有进步；数据可以给做事的人反馈，让当事人知道现在在差距有多少，所以如果可以从定性提升到定量管理，也可以产生同样的作用。例如，：如果评审发现缺陷数量太少，团队应该担心，因为很可能有不少缺陷未被发现，后面到了客户使用时才暴露，代价更大。感兴趣吗？
总经理：很感兴趣
我：首先须要利用以往项目数据，建立标杆（基线）例如下图：

如果代码是800行以下，每千行代码的缺陷密度均值与范围。800行以上的缺陷密度会低一些，因分母较大。
如果某次代码评审，700行的模块，代码评审发现的2个缺陷，比基线下限7个缺陷（注）低很多，团队便应担心，很可能存在不少缺陷未暴露。
总经理：但我希望团队有提升，不仅仅是维持，团队怎样可以利用度量数据帮助提升？
我：可以利用水晶球模拟，利用缺陷排除率，预估如使用新方法后的缺陷范围。
如果也收集团队的缺陷返工工作量，我们更可以预估能降低多少返工。 从降低后面缺陷返工入手，能提高产品开发质量，也能提高团队的生产效率，降低开放成本

（注：从基线左图，如按每千行代码有10个缺陷为下限，700行代码便应发现起码7个缺陷）

我用实例在白板上估算提前发现解决缺陷能降低研发成本接近一半。

总经理：很好，应怎么样开始？
我：你们有没有一些团队已经是按小迭代开发？
总经理：有的，我们去年开始已经有些团队按一个月一个迭代交付，有些更短可能两到三周。
我：你们这些团队人员的能力主动性如何？
总经理：我觉得还是挺不错的。
我：如果你可以识别出两到三个正在在迭代开发的团队，就可以开始做量化的回顾，你们那些迭代团队以前有每轮迭代后做回顾的习惯吗？
总经理：都没有
我：首先就要让他们了解什么是根因分析？为什么要做回顾/复盘？希望达到什么目的？ 你们管理层也需要有心理准备。开始的时候人员要花时间学习，因为你们也准备参加CMMI评估，团队做好量化迭代回顾就可以帮助你们从以前三级的水平提升到CMMI4级，并开始利用项目迭代数据，建立基线和预测模型。但团队要做好第一次迭代回顾，就像要小孩学游泳，不能只是扔他到水池里面要他自己自学，必须先有培训帮助他。首先要安排这些团队参加一个一天的根因分析和回顾培训，也需要你们内部的管理层包括有经验的主管作为内部教练辅助整个培训，你们愿意尝试吗？
总经理：好的。

= = =

有了高层的支持，我们便可以试点，找团队做好迭代回顾，但不会是点石成金。

要利用根本原因分析做改进，必须有数据， 也需要有机会立马实验改进方法，评判效果， 所以迭代回顾（或复盘）是做根本原因分析的最佳时机。 但很多团队只在迭代回顾时讨论如何解决迭代暴露的缺陷与相关职责分工，没有探索根本原因， 和如何能避免同类问题再发生。应如何做好迭代回顾？

先看回顾的主要步骤：

回顾流程

冲刺回顾可按下图的五步，确保各成员都全心投入参与，并能从分析形成行动，达到改进效果：

1. 设置舞台 -‘破冰’
2. 收集数据（除了收集‘硬’数据，如缺陷，工作量，进度偏差等，也要收集‘软’数据,如团员感受）
3. 分析，找出根因 （除了鱼骨图，FMEA，也可参考附件里的KJ分析法，大家利用便利贴做分析）
4. 决定做什么 （必须明确下个迭代的具体改进行动到人，任务，时间）
5. 结束

以上只是根因分析的技巧，若要团队做好迭代复盘，取得效果，还要注意以下原则：

做好回顾4原则

1. 回顾让数据提供者能即时收到反馈

• 软件开发与工业生产不一样，大部分的数据必须开发人员自己收集，不能但靠机器/系统（例如：返工工作量）
• 如果回顾时分析根因是依据迭代数据，除了能帮助根因分析更具体外，也让团队成员有动力收集数据（因他们知道会一起分析数据）

因为软件开发是知识性工作，例如，某活动所花的工时，必须靠个人记录（具体步骤可参考‘个人量化管理’）

• 但记录数据要花精力，如果不了解收集的数据，后面有什么用途，便难以维持不断收集数据的习惯
• 反之，当大家都清楚到迭代回顾时会一起分析团队数据，并制定针对改进措施，就有动力继续迭代里统计数据

2. 整个团队（所有相关干系人）参与
整个团队分析全局问题。例如，如果只是从测试人员的角度，他可能以为缺陷都是来自开发；需求分析人员（或产品经理）会觉得自己做得很好，因需求评审里没有什么问题被发现。但如果团队所有成员聚在一起（包括项目经理、需求、设计、编码、测试），把所有的缺陷列出来，让团队所有岗位一起分析，才可以全局看问题，才可能发现不少问题是因为需求没有明确，导致后面做出来的功能并不是客户要的。后面可扩大参与回顾的干系人，例如客户代表，可以更全面分析。

3. 让团队自己寻找改进方案 （避免盲人摸象）

 “必须参与一起分析、讨论，才有动力后面采取行动”

“我们团队回顾都是全部成员参加，一起讨论”某团队组长说。 以下是团队一起讨论后的根因分析结果： 项目组 原因 投票数 **雄 建议使用FindBugs代码扫描工具 1 张** 缺少系统业务培训 1 高** 没有合适的代码扫描工具 2 李* 希望公司制定缺陷数据分析标准 1 韩** 公司应提供合适的代码扫描工具 3 高* 公司应加强相关业务培训 2 *一铭 没有合适的代码扫描工具 4 孙** 建议使用有力的代码扫描工具 5 有没有看到组长（雄）提出建议使用代码扫描工具后，其他7位团队成员中4位也提类似原因？ 所以当团队一起围着开会时，很多人都会避免提出与众不同意见，所以如果用投票方式，让大家对提出的“原因”进行投票时，票数最多的通常也是组长提出的方案（扫描工具）。

从Asch 1951实验（详见附件）,看到人容易受群众压力影响（尤其当大家不认识），不敢独立表达个人看法，所以很多会议都只是项目经理一言堂，其他人只是观众，没有投入分析。 为了鼓励每人畅所欲言，表达独立看法，并达到共识需要：

1. 鼓励每人用实例讲对质量、过程的观点/经验（寻找大家的共通点）
2. 鼓励每人分享个人感受，想法，满意开心/困惑的时刻（让大家相互了解）

• 当大家都感受到面对的问题和情况类似，才会放开自己，分享个人看法
• 教练、顾问也鼓励每人发声，大家表达自己的观点

所以在回顾时，也要想办法避免发生这种心理上的影响，导致不能真正挖掘问题的原因。所以在回顾需要大家开放，以下两方法可以减少团队压力，让大家更投入，能畅所欲言：

1. 回顾开始时 （设置舞台，“破冰”），用互动游戏，让团队放开顾虑，全心投入讨论 （可参考附件里“游戏：应与否”）
2. KJ分析法(详见附件):每人都有一支水笔+便利贴 ，一起找根因，每人都可以写上自己的意见。而不是传统开会方式，很多时候都只是某一个人讲，其他人听。无法得到每个团队成员的充分参与。如果可以给团队自主权，他们就更能发挥、更能达到目标。

如果能让每位团队成员都“发声”，表达意见，不单能集思广益，做到更好的对应方案，，也能提升团队后面执行改进方案的积极性，因为一般人都会更喜欢自己挑选的东西。

详见附件里两个实验：

1. Brehm 1956 决策影响实验
2. 粮食分配实验

验证了：人都会觉得自己选的东西比较好，更有动力尝试。

4. 看全局，寻找大家的共通点
避免局部最优(sub-optimization)，避免盲人摸象， 最终希望可以全面从每个角色的视角全面分析。

某公司管理层一直非常关注度量，对各过程，包括需求、开发、测试等，都订了七八个KPI指标，并每月监控。但各个过程按指标做好不一定代表总体效果会好。 每个过程都会影响软件开发最后遗漏到客户的缺陷数，迭代回顾的时候，团队可以用缺陷排除的预测模型让团队‘看见’如果代码评审排除率提升如何影响每个过程的缺陷数，不仅仅是定性的讨论分析。

例如，为什么要用‘设置舞台’开始迭代回顾？（例如‘应与否’是其中一种方法，详见附件），目的是让整个团队全心参与，如大家没有担心，愿意提意见，才能更全面看问题，寻找共通点，而不是辩解。

例如发现大量缺陷大部分都在系统测试和验收测试才暴露， 大部分缺陷未在前面评审和单元测试发现并解除，根因分析讨论后发现单元测试没有任何要求，依赖程序员自己测。但很多时候程序员就因为时间压力都没认真去测。因为大家都忙，没有时间去深入去看，代码评审也没有发现多少问题。针对这些点大家觉得可以加强静态扫描工具，尽早发现一些语句基本问题，或重复代码等问题，减轻依赖人工查看；单元测试可以用脚本写，并规定有一定的语句覆盖率要求(例如，>80%）。但如果团队只是按这些去做，没有定量化目标就很难衡量，做得够不够？不然要等到迭代最后复盘时才知道效果如何。 好比要设计一座新的80层高楼，建筑师预先用工程模型预估它防地震、防台风的能力，不要等到建好才知道有问题。团队可利用蒙地卡罗预测模型预先依据以往迭代的数据，把参数输入模型，比如每个阶段引入的缺陷数，每个阶段的缺陷排除率。首先可以利用蒙地卡罗模型，看看它出来的缺陷分布，验证是否对应以往迭代数据，预估范围是否可以覆盖以往数据。 第二步，就可以使用蒙地卡罗模型做一些实验：例如，我们估计用了静态扫描可以把代码评审的排除率从本来的10%提升到50%，团队利用蒙地卡罗模型可以预估这种搭配的各个过程的缺陷分布，我们就可以看到如果这个排除率提升的话，评审应该出发现多少缺陷，比以往提升多少。团队也可以加入利用脚本的单元测试的缺陷排除率，例如估计能从本来的排除只有20%提升到55%，看到对整个缺陷分布的变化？这样的话，我们就可以团队有下一轮迭代各个过程的缺陷预估范围参考。如果发现在代码扫描后这个缺陷数达不到本来的预期目标，便可立马采取纠正措施，不要等到最后迭代回顾时才发现未能达不到本来的预期效果。 如果有好几种方法选择，蒙地卡罗预测模型更可以帮我们做选择一个最优的最佳搭配，比如我们只是先做好评审，还是先做好单元测试，因为那些都会增加一些工作量，还是两边种方法都做，我们就可以要用蒙地卡罗以总成本最低选最佳搭配。反过来，如果没有这种蒙地卡罗工具的话，团队是很难看到每一种变化总体的效果，像盲人摸象。 因为工具可以反映过程之间的相互关系，如果我前面评审发现多了，遗漏到后面的缺陷就会减少，一层一层的关系，它利用那个缺陷排除的关系模型就可以估计总体的效果，也帮团队迭代回顾从定性改进分析，提升到定量。（如何从迭代的缺陷数据，利用蒙地卡罗预测模型，做定量分析，详见附件。）

团队迭代回顾根因分析常见问题

1. 没有利用缺陷数据做帕累托图分析，不清楚应针对哪一类，不清楚哪一类问题最多，导致根因分析讨论没有针对性。有些缺陷分类没有定义好，不明确或重同一缺陷可以归到几个类别，导致分析结果没有参考作用。
2. 不清楚怎么是根因，只找到表面看到的现象，例如人经验不足，对技术不熟悉，对业务不熟悉等。没有抓到系统的根本问题。
3. 没有量化目标，只有定性的根因分析，下轮迭代难以判断效果能否达到。

除了教团队根因分析技巧（定性）以外，也需要展示如何使用水晶球蒙提卡罗预测模型，预估各类缺陷数范围，有了范围才可以判断最终结果是否达标，差多远。识别出哪些过程有差异，下一轮回顾才能更有针对性。如果团队想下一个迭代降低遗漏到客户的缺陷数，尽量提前用评审或测试预先发现并解决。如果仅仅提一些改进方法，比如加强评审，使用工具等，效果很有限。例如团队一般也有做评审，例如需求评审，但无法判断评审质量如何？ 例如，发现四个缺陷是否足够呢？我们就可以用缺陷排除率配合蒙地卡罗体水晶球模型，估计使用新提升方法后，预计的缺陷数范围，这样的话，如果团队发现缺陷数没达到预期，就知道立马可以加大力度加强，而不仅仅是走过程。（关于缺线排除率配合蒙地卡罗的原理，详见附件）

4. 回顾时间不够

5. 设备、纸张、工具等未准备好

以上前三点可以利用培训加强相关能力，为了确保团队能做好第一次迭代回顾，建议要之前和团队做培训。 后两点可以做好准备，预防问题发生，所以若要做好回顾，除了要理解上面4原则，也需要注意以下两条件：

• 回顾的环境，设备： 有大白纸贴在墙上，水笔，便利贴等

有些时候便利贴可能太小，或者字很小，笔不够粗，原因是如果用大白板的那种粗的水笔的，字就太大了，如果用平常的水笔，自己用的就太细都不合适。应该买一些比如GMM粗的水笔去写那个便利贴归纳，让大家可以在一到两米距离都能看得清。还有那些便利贴是不适合直接贴在普通白板上面的，所以必须先从图文店买一卷比如两米宽的卷纸贴在墙上，也可以用泥胶布条稳固在墙，这样的话呢我们在贴便利贴的时候，就不会出现下面翘起来看不清的情况，整个房间应该有充分的空间让大家活动，而不是那种传统一个大长座的会议室，因为越是让大家活动流动，才会投入的。

• 足够的时间，起码3小时

某成都客户反馈 研发总监： 已经做了很多年过程量化考核，起初能给团队带来活力，因为至少比以前好，有路径可以量化他们，员工觉得做有所值，公司也看得见。前几年执行的很好，产出和上线频率比过去好很多。但是现在感觉逐渐拉不出差距来，因为大家都非常熟悉这套游戏规则。 我：理解，比如现在你们团队开始做迭代回顾，团队一起分析根因，持续改善。您觉得效果如何？ 研发总监：挺好，但是还是感觉他们开回顾会，耗时太长了，2个小时以上 我：因需要团队收集数据，分析，讨论下迭代措施，所以通常要3小时，熟练后会快一点，底线是改进的节省应大于回顾的投入。 高层的支持是任何改进的重要成功要素。所以首先要让管理者赞同迭代回顾能为公司带来回报（省钱),可以节省的成本（工作量）大于回顾的人力投入；也要让他理解任何改变都有个混沌的过渡期，要经过几轮回顾后，团队才能自己持续改善。

如果回顾只能一个或一个半小时的话,就不够时间让团队针对缺陷分组分类、画帕累托图做分析，没有根据实际数据分析根因，也影响到团队没有动力在后面迭代花精力去收集数据。例如，缺陷返工数据一直都非常难获取得到的，也需要在迭代根因分析时给时间团队讨论统计，所以通常一个完整的迭代根因分析回顾不会小于三小时。要做好这块如果有本地的教练可以更好控制整个回顾的节奏。不会在某一个环节耽误太多时间，也不会太长，也确保大家团队人员都全程投入讨论参与。这个我们在下一章会详细讲。

培训：策划与准备

培训能让团队能先了解利用模拟工具量化管理的原理，也让团队为收集迭代数据做准备，所以建议先做模拟互动培训。

培训的目的：

1. 让团队用模拟数据体验一个迭代回顾量化的应如何进行。
2. 知道为什么要收集缺陷和返工工作量的用途。并利用类似一般开发项目的环境的缺陷数据模拟。
3. 收集到团队真实数据是最大的挑战，培训过程中也要团队自己讨论准备如何收集迭代的数据。因为没有数据是无法做量化的迭代回顾。

下面是一天互动培训的时间安排：（上午是做上一章迭代回顾的互动练习，下午是使用蒙特卡洛预测模型预测下迭代的互动练习。）

时间安排

如果是首次根本原因分析培训，建议先在培训当天早上做以下根因分析小组互动练习，让大家先熟悉根因分析的重点：

• 提供一对模拟数据，要求团队利用帕累托图加鱼骨图分析，找出根本原因与改进措施
• 目的：让团队先感受如何基于数据，找出根本原因

培训对象

• 后面会参与试点的项目组，培训后可以把学过的在项目里实践
• 所有团队角色都参加

准备数据，让团队模拟

要做量化根本原因分析就必须要有数据,所以内部教练须要预先准备下面缺陷与返工工作量数据，类似一轮冲刺后的场景：

1. 系统测试缺陷数据，建议从缺陷管理工具里抽取，40 - 60 项
2. 开发个人系统测试BUG返工工时统计表：那个BUG号 / 总修复工时 / 备注
3. 开发个人开发期间用于修复评审/单元测试返工工时统计表：那个模块 / 总修复工时 / 备注

• 打印以上的数据表，发给团队做练习时参考

例如，互动练习时，要学员利用开发人员工时表 （模拟他们迭代中用于改缺陷的工时，与评审缺陷数，与开发和修正代码的工时）：

准备工具

• 分2-4组，6-8人一组，，需要有一个大而光亮的会议室， 方便小组互动，大白板和架子，各种颜色的水笔，墙壁可以贴上小组的白纸
• 教练提供有MonteCarlo工具的笔记本电脑

经验教训

很多开发人员虽然编码/测试很有经验，但不熟识统计分析，蒙地卡罗模拟等，所以整个培训需要有内部的教练辅助他们怎么利用那些工具技巧去分析数据。团队只是提供数据和分析结果，不一定要很了解里面的数学分析，但必须真正了解根因分析，所以我们培训会以根因分析开始，用前面的丰田故事，日本绅士俱乐部原因分析故事。让大家了解根本原因分析的重点。然后给小组前面的机场延误数据，让他们利用KJ模拟方式和帕累托图，自己动脑筋找出根因，我们的经验：越多互动练习，他们就越感兴趣，越主动参与。所以如果时间有限，尽量可以压缩讲理论的部分，甚至要他自己先阅读了解，大部分时间让他利用数据分析根因。有了这个基础就可以进入第二部分，利用内部教练准备好的几十条系统测试缺陷，要他们按缺陷排除的方式，找出缺陷的主要来源，并估计返工工作量，再利用蒙地卡罗模拟估计每一个过程的缺陷范围。经过培训，他们便可以在下一个迭代回顾时用同样思路，分析自己的迭代数据，找出根因并制定下一轮迭代的纠正措施。培训结束前，内部教练在总结时要求大家团队讨论后面有什么方式可以收集到做迭代回顾所需要的数据，例如缺陷数，返工工作量等。

结束语

要做好迭代回顾，首先必须得到高层的支持，并取得所需的资源与时间。策划与培训是成功的第一步。因一般团队没有回顾与根因分析的概念，教练如何现场辅导也很重要。

下章会分享如何在回顾中的注意事项和如何持续。

附件

游戏:应与否

在迭代回顾中使用。

目的

帮助建立有效沟通的思维模式。帮助参与者抛开指责和判断，以及对指责和判断的恐惧。

所需的时间

8到12分钟，取决于小组的大小。

描述

在描述这些模式之后，参与者讨论这些沟通模式的意义。

步骤

1. 将注意力集中在“应与否”(见下图)，并简要阅读。
2. 组成小组，每组不超过4人。要求每组用一对词来定义和描述。如果有四对以上的词对/组，如果有多个组有相同的词对，也可以。
3. 让每个小组讨论他们的两个单词的意思和它们所代表的行为。让他们描述各自对团队和回顾的影响。
4. 每个小组向整个小组汇报他们的讨论情况。
5. 询问大家是否愿意使用左面的方式。

用角色扮演为做好回顾打基础

学员用各种角色扮演什么是吵架，什么是交流，让观众和表演者更能感受到量化回顾先要有对事不对人的心态：

• 

  “对话”

• 

  “辩解”

如何在迭代回顾时分析缺陷数据得出预测模型参数

上章介绍了缺陷排除率(Defect Removal Efficiency DRE)

如果能尽早发现并解决缺陷能减少返工工作量，降低质量成本。

下面我们介绍一下怎么从引进量化管理来提高开发质量：

1. 设定量化目标。例如希望最终遗漏到验收发现的缺陷数降多少？
2. 并设定中间阶段目标缺陷数，从而预测能否达到最终目标，不要等到最后才知道不满足

可用缺陷排除率来判断每一个过程的质量：
如果要最终质量好，缺陷排除率就要高。但计算缺陷排除率，必须要等到整个开发完成才可以计算，我们可以建立一个预测模型，模拟这个过程：
需求会引入缺陷，然后需求评审排除缺陷等等。把各引入缺陷数，排除率输进蒙地卡罗预测模型，然后使用它估计每个阶段的缺陷数量范围。

Table 7.2 Defect Distribution in Infosys's PCB Infosys PCB的缺陷分布

Process Stage 过程阶段	Percentage of Total Defects 占总缺陷数百分比
RR + DR Requirements review需求评审+ HLD + detailed design review 概要/详细设计评审	15% (15% - 20%)
CR+UT Code reviews代码评审 + unit testing单元测试	55% (50% - 70%)
IT+ST Integration testing集成测试 + system testing系统测试	22% (20% - 28%)
AT Acceptance testing验收测试	8% (5% - 10%)

如果我们按上面 infosys 公司的各阶段缺陷利率百分比，设计与需求排除缺陷15%，代码评审与单元测试55%，集成/系统测试22%，验收测试8%，下面按缺陷总数为100， 得出算出设计与需求排除共15缺陷, DR+RR=15，CR+UT=55, IT+ST=22, AT=8,求出各阶段的缺陷输入与缺陷排除率，把参数输入蒙地卡罗预测模型：
表D1:

得出下面Figure7.2，缺陷分布是中间最高头尾低，右面与左面不同，有条长尾巴，类似估算软件开发项目工作量的 Rayleigh 曲线。

模型假定每个阶段的缺陷排除率都比较稳定,在某个范围之内，不同阶段引入的缺陷也在一定范围之内。 蒙地卡罗模型让我们可以设定缺陷排除率和缺陷输入数量的波动范围，预测各阶段缺陷排除分布范围（不仅仅看单点数)。

Asch 1951 群众压力实验

问题：请问右面那条线 (A, B, C) 的长度最接近左面线的长度？

实验设计：随机邀请几位志愿者（包括你） 参加，实验之前与（除了你以外）所有人预先说好，都选A，并且要假装成经过深思熟虑。实验时，你是最后一位作答。

结果：

• 有群众压力时，大概37%会从众选择错误答案 (虽然不同人有差异，但总体只有25%能坚持自己的正确答案。)
• 个人自己作答，接近100%选对，错误率少于1%

影响因素:

• 前面选择错误答案的人数越多，错误率越高:

1. 一位：接近0%答错
2. 两位：大概14%
3. 三位: 32%（详见下图）

• 如果前面其中一位选了正确答案，你的错误率就显著降低（大约原本水平的1/4，看下图黄线），并让你感到与他更亲切
• 但当这‘战友’后面实验里也从众选错误答案，你的错误率会返回原本水平（原本水平是下图绿线）

• 尴尬场景(例如，迟到)，你的错误率会更高
  • 实际你没有晚到，只是让你觉得确实迟到了，觉得尴尬
• 如果不是要你说出答案，而是让你把答案写在纸上，错误率会降低三分之一

Brehm 1956 决策影响实验

实验设计：

1. 提供十多种不同礼物，包括台灯，多士炉，挂钟、收音机、等
2. 请你按自己喜好对礼物排序 。例如，最喜欢的选一，如果同样喜欢两件礼物，可以不分高低，写同一个数字
3. 让你从两件同样喜好的礼物，让你选其中一件，让你拿走
4. 但在你离开之前，请你再对所有礼物按喜好排序

结果：

• 绝大部分人都会抬高自己选择拿走的那一件礼物排序，调低非选择的那件礼物排序
• 但如果不是自己选择，而是由老师选好给你，你后面的礼物排序就没有变化

结论：

• 人都会觉得自己的选择比较好
• 例如，选大学，选汽车，选伴侣；如果是由你自己决定选择（非被安排），你会不会都会觉得自己的选择较好

粮食分配实验

二战时，美国虽然不是战区，也需要控制粮食供应。政府面对的难题：

• 怎么让那些家庭的消费习惯，可以满足战时的食物供应？

比如当时有些食物是要分配的，如何让家庭多吃一些供应充足的食物，避开紧缺的食物。他们实验发现，首先要知道整个过程是家庭里哪个人做这一块的决定？
他们研究分析发现，绝大部分的家庭都是由家庭主妇决定购买什么、储存什么、怎么做菜，丈夫没有太多的意见，通常是由媳妇决定。

KJ分析方法步骤

一种头脑风暴方法，每人把自己想法写在便利贴上，一起轮流把所有便利贴排放分组

1. 把主题以问题形式写在大白纸的头顶；
2. 把相关的事实写在便利贴上面，用黑色；
3. 搜集相关的事实，如果是一组人的话，分散到不同人手上；
4. （团队）查看描述是否不清楚，是否要整理？
5. 每人轮流把相关的便利贴组合在一起；
6. 当每人都已经调整过便利贴组合后，一起把每一组便利贴加上一个题目，用红色标识；
7. 红色的标题下包含相关事实的内容；
8. 把相关的红色题目（最好不超过3个）组合在一起；
9. 给这大组一个题目 – 蓝色；
10. 在题目下放上相关的红色小组；
11. 把蓝色的题目和剩下红色的小组或单独没有分类的便利贴都在墙上放好，也可以用一些箭头描述它们的因果关系；
12. （可选）

A: 投票看看哪个是最重要的红色组

B: 也可以加些总结性的描述

水晶球蒙特卡洛预测模型

• 按每个过程的统计数据，估计对应缺陷排除百分比的上下限与均值，工作量也类似。例如，从公司基线，代码走查的缺陷排除率是55%左右；评审总工作量（不包含修正缺陷）大概为20人时。如果开始时没有充足的项目数据，可以先依据行业基线：如代码正式审查应能排除85%，但平均人时会增加到35人时 （也是不包含修正缺陷）。得出下图：

• 模型会自动按输入的最大最小值计算标准差，变成分布（如：正态(normal)分布、三角形(triangular)分布），水晶球模型会依据黄格里的数字选取对应的分布，

• 取对应的分布，依据项目历史数据统计，估算各个过程缺陷的返工工作量与成本。例如：修复一个系统测试发现的缺陷，平均要用6000元，最高7500，最低5000。如果缺陷导致的如果是工时那行，填上对应工种的平均人时总成本。水晶球模型就会依据我们输入的范围估算单位成本的分布，放在绿格里。

• 如果从需求到验收测试，每一个过程的成本数都是单一值; 我们可以简单用 XLS 把数加起来得出总数。但如果每个过程的成本数都是一个分布，例如三角形分布,

必须要使用蒙特卡洛方法才可以把每个过程”加”起来。

• 水晶球可以帮我们估计质量成本的分布，例如我们需求评审用审查（2），设计评审用走查（2） ，代码评审也用走查（2），单元测试是手工（1），系统测试估计走3轮（2），验收测试预计走3轮（2），水晶球就会依据我们刚刚输入的分布用蒙特卡洛预测模型预估质量成本的分布。

• 比较各种不同的配搭，选出质量成本最低是哪个配搭组合，帮助项目组在策划时选择使用什么方法，得出最佳效果。

下图显示一直水晶球优化的过程，和最终的最“佳”配搭：

在需求评审，设计评审，代码评审，单元测试，系统测试，验收测试都有两种选择时，跑优化，95%的置信区间 得出 Overrall goal (Quality + Effort) = $1,476,773