翻牌游戏玩法实践与反思

游戏目的

敏捷是否真能提升研发效率？敏捷对比瀑布有哪些优势？员工通过直观的游戏环节，模拟迭代交付和瀑布交付，更能深刻体会两者的区别，并理解快速交付、自组织、客户协作、瓶颈等敏捷概念。

道具

• 纸牌一组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可能会好很多。
• 各个小组的工作时间都有所波动，但并不影响整体时间，所以优化一个流程需要从整体考虑，而不能只是一味的进行单团队/个人的优化。
• 如果大家配合更积极，参与更投入，时间会更快，比如这次最快的是第一组（武汉团队），他们在远程受干扰较少，所以敏捷中专注很重要。