游戏目的
敏捷是否真能提升研发效率？敏捷对比瀑布有哪些优势？员工通过直观的游戏环节，模拟迭代交付和瀑布交付，更能深刻体会两者的区别，并理解快速交付、自组织、客户协作、瓶颈等敏捷概念。
道具
- 纸牌一组12张（也可以是硬币、筹码等）；
- 白纸每组两张；
- 水笔每组一支；
- 角色贴纸；
- 手机计时。
- 预计占用60分钟
角色分工
- 每组6-10人，每一组围着一个桌子站好。
- 每一组需要确定每个人的角色：一个CEO，一个PO，剩下几对SM-DevTeam模拟几个团队。
- 选好角色后，每个人手臂上用角色贴纸贴上角色
规则
- 工作：DevTeam用一只手翻纸牌，1次只翻1张；SM/PO/CEO分别计时
- 计时：
- 团队时间：SM记录从本团队的DevTeam收到第一个纸牌，一直到完成所有纸牌的总时间；
- 上市时间：PO记录从把纸牌交给第一个团队，一直到从最后一个团队收到第一张纸牌的时间；
- 项目完成时间：CEO记录从纸牌交给第一个团队，到PO收到最后一张纸牌的时间。
- 工作规模：每一轮由组织者说明一个任务规模，每个DevTeam在完成指定的工作规模之后才能把工作移交给下一个团队的DevTeam。
- 记录：每个团队都需要记录每一轮每个组的团队时间、上市时间以及项目完成时间
- 标准：每个团队所有纸牌必须数字朝上，否则无效
团队记录
- 每轮完成后，每个团队需要将记录的数据填写到表一：
|
第一轮 |
第二轮 |
第三轮 |
第四轮 |
第五轮 |
|
|
规模 |
|||||
|
团队时间 （SM） |
|||||
|
上市时间 （PO） |
|||||
|
项目时间 （CEO） |
- 五轮完成后，每个团队将表一记录的数据更新到汇总表中对比。
- 备注：由于本次培训我们每组只有7人，且大家对项目时间和团队时间较关注，就没有设置PO角色，只记录了团队时间和项目时间。
游戏环节
练习
- 一次把12张纸牌交给第一个团队，第一个团队的DevTeam把所有纸牌翻完之后，交给第二个团队。这一轮的目的是让每个人熟悉一下工作，尤其是该怎样记录时间。过程中如果正反面翻错了，需要重新翻。
- 规则：左手
- 规模=12张纸牌，一次下发
- 计划：2分钟
- 回顾：每轮之后有2分钟回顾，对如何改进下一轮工作达成一致
第一轮
- 规则跟练习时一样
- 计划：2分钟
- 回顾：2分钟
第二轮
- 一次6张纸牌
- 需要注意的是，每个团队的SM记录的是从本团队的DevTeam收到第一张纸牌，一直到完成所有纸牌的总时间；
- 规则：左手
- 计划：2分钟
- 回顾：2分钟
第三轮
- 一次6张纸牌
- 需要注意的是，每个团队的SM记录的是从本团队的DevTeam收到第一张纸牌，一直到完成所有纸牌的总时间；
- 规则：双手
- 计划：2分钟
- 回顾：2分钟
第四轮
- 一次3张纸牌
- 规则：双手
- 计划：2分钟
- 回顾：2分钟
第五轮
- 规模降到1，也就是上一个团队每翻完一张纸牌，立刻交给下一个团队继续翻
- 规则：双手
- 计划：2分钟
- 回顾：2分钟
实际游戏结果
各组实际数据
| 1组 | 2组 | 3组 | 4组 | 1组 | 2组 | 3组 | 4组 | 1组 | 2组 | 3组 | 4组 | 1组 | 2组 | 3组 | 4组 | 1组 | 2组 | 3组 | 4组 | |
| 规模 | 12，左手 | 6，左手 | 6，双手 | 3，双手 | 1，双手 | |||||||||||||||
| 团队时间 | 10 | 14 | 16 | 25 | 9 | 9 | 13 | 18 | 8 | 6 | 9 | 14 | 8 | 14 | 15 | 14 | 11 | 15 | 21 | 18 |
| 9 | 10 | 18 | 13 | 10 | 8 | 15 | 12 | 10 | 4 | 10 | 8 | 8 | 13 | 13 | 15 | 12 | 14 | 19 | 17 | |
| 15 | 6 | 18 | 10 | 12 | 5 | 17 | 15 | 10 | 4 | 11 | 8 | 13 | 11 | 14 | 13 | 12 | 14 | 21 | 16 | |
| 项目时间 | 41 | 38 | 60 | 64 | 26 | 42 | 35 | 32 | 21 | 30 | 24 | 24 | 19 | 26 | 23 | 21 | 18 | 19 | 27 | 19 |
对各组数据，从轮数的维度采用曲线图分析：
从游戏结果来看，随着WIP的减少，项目时间越来越短，但是团队时间却是先减少后增多。
对各组数据，以小组的维度用曲线图趋势线分析：
结果一样，即每组的项目时间逐渐减少，但团队时间先减少，后增加。
可见，随着迭代频率的加快，确实可以有效减少项目时间，但是团队要不断加快步伐，感觉做的事情越来越多，越来越累。说明除了可以采用迭代开发，还要找到合适的迭代频率，否则可能事倍功半！
结果反思
- 大家对游戏结果感觉挺惊讶，甚至表示怀疑，为啥团队时间会随着迭代频率加快反而增加哪？每组的结果都是这样，说明并不是巧合。
- 实际上，随着每轮迭代规模的减小，项目完成时间大大缩短，但是项目需要完成的其他活动也显著增加，比如12张牌一起只要传递一次，而如果分成6张、3张甚至1张，那么传递的次数成倍增加，时间自然增加，在精益理论中，这就是一个浪费。可见，若没有持续集成或者自动部署，那么每完成一次发布，都需要配置、运维完成一次发布操作，如果这几次发布能合并到一起，则配置、运维可以减少操作次数，减少工作量。所以，不能仅想着提高迭代速度，经过几次迭代后，应找出适合自己团队的迭代频率。
- 游戏中，有些团队搞不清正反面要求而慌了手脚，迟迟没有启动。所以产品开发时必须先明确方向（验收准则），没有方向时可以假设方向，然后让客户快速验证。
- 团队的绩效可以通过工具（单手变双手）、经验（经过多轮工作）改进，但是要想有大的飞跃，更需要方法（由瀑布方式改为敏捷方式）的创新；
- 规模小的时候，开发的波动会比较小，开发速度会比较快，形成了“流”，这也是我们一直强调要稳定迭代的原因，这样才能有稳定的输出。
- 规模较大的时候，瓶颈现象十分明显，随着规模的减小，瓶颈现象逐渐消失。
- 自组织能力非常重要，比如第三组在培训的时候每个人表现都很好，回答问题也很积极，但到了游戏环节，需要小组共同配合的时候就落后了，研究了好久也没搞清游戏规则，且最后一轮他们的团队时间和项目时间都是最长的。这时候如果先选择出一个Scrummaster可能会好很多。
- 各个小组的工作时间都有所波动，但并不影响整体时间，所以优化一个流程需要从整体考虑，而不能只是一味的进行单团队/个人的优化。
- 如果大家配合更积极，参与更投入，时间会更快，比如这次最快的是第一组（武汉团队），他们在远程受干扰较少，所以敏捷中专注很重要。