玩几场「精益厨房」游戏，居然惹怒女朋友要分手！

8月底的北京RSG大会上，我玩到了一个游戏神作，这个游戏叫 Over Cooked 2，中文别名「分手厨房」。

两个人需要紧密地配合才能获得高分，考验默契和手残度，于是情侣在玩的时候就很容易擦出愤怒的火花啦！

游戏进行中的各种现象，很容易让人联想到软件研发中的很多浪费，从而引发思考，没准儿能给你的工作带来启发呢？（如果用精益价值流图来画，还真不容易画出来，交错缠绕的，空间和时间维度都要考虑）

游戏介绍

如果你曾经在线下精益敏捷培训中玩过“Pizza Game”，或者你去肯德基打过工，就会比较熟悉这个游戏。进入游戏后，屏幕左上角不断显示的是餐厅客人不断下的订单，是典型的「按订单生产」的模式。将订单中的原材料加工完成后，必须端到传菜口，才能获得积分奖励。

❧ 这些订单有以下特点：

• 每个订单的回报不同；
• 订单有时间限制，超时会被扣分（客人催单啦）；
• 有的菜品只需要一种原材料，有的需要两种或三种；
• 有的原材料只需要一道工序，有的需要好几道；
• 加工过程比如煮饭过久，会起火！
• 后厨空间有限，原材料和加工位的分布在各处，两位厨子要跑来跑去，甚至互扔来传递。

玩法介绍

前方即将有一大波「干货」来袭~

丰田精益生产之道(TPS)的创立者大野耐一（Taiichi Ohno）把大规模制造业的生产浪费划分成七个主要类别，我们来看看对应到软件开发中，分别对应什么浪费。

在制品

有时候会发现，很多个订单都完成了一大半，就缺最后的一道工序，导致订单积压，不能得到奖励。时间到了，还剩下一些半成品，不仅浪费了原材料，也浪费了前面投入的时间和精力。进入倒计时，右边负责煮米饭，洗盘子的红色玩家，推测已经够用了，就不要继续洗盘子和煮米饭了，而是应该到左边去，把接近完成的菜品完成并递交给客户。

软件研发上，赶不上版本了，是不是应该集中把已开始的工作做完，而不是开始更多的工作？但你可能是我是前端，前端的活儿已经干完了，我只能开始一些新的前端工作啊。这就是为什么「结对编程」是「极限编程」的重要实践了，通过结对，可以让团队成员一专多能，更快地成为通才，更有利于消团队瓶颈。同时，组建端到端「特性团队」也是为了让大家聚焦尽快完成，消除在制品。

过度生产

如果不按订单要求，做出来的东西不是客户需要的，无法变现，这是最大的浪费。需要的没有得到交付，客户不满意。没有客户的认可，团队没有成就感。

在现实中，一方面开发团队 996加班，一方面，统计显示 64% 的功能几乎没人用。我们并不需要做更多，只需要把现在做的不需要的替换成客户需要的，就已经好很多了。

额外的过程

米饭在锅里煮好了，要盛出来，有两种方法，一种是把盘子拿到锅那里，一种是把锅端到盘子那里。而后者就需要多一个放下锅的动作，这就是多余的动作。

工作中我们常常做的测试执行，打包，部署等，都可以自动化，既提高执行效率，也提高准确性。无效的会议，返工的沟通，多余的流程，冗余的文档、不干活的职位等，应该无情地摒弃。

运输

游戏中，米饭原材料在左边，煮米饭的炉子和锅在右边，黄瓜在右边，切黄瓜的砧板在左边。如果一个人玩，经常需要端着东西走很远，这是非常明显的浪费。在现实中，设计厨房时都会考虑到「洗菜 – 切菜 – 炒菜 – 出菜」的流水线操作便利性，尽量减少不必要的移动。好的是，游戏里可以直接把东西「扔」出去，提高运输的效率。

在软件研发中，让团队坐在一张桌子上，降低工作交接的成本。每日站会，促进协作。结对工作，面对面沟通最有效最高效，互相了解彼此的领域，消除分工过细带来的鄙视链现象。

交接

在游戏中，如果一个人要做「全栈」厨师，把一个订单交付完。那就需要在不同的工序之间来回切换。身体的移动和上下文的切换都是一笔不小的开销。

在软件研发中，尽管推崇「全栈工程师」，但目的是为了消除瓶颈，并不是说每一个需求都要一个人从前端到后端独自完成。平时还是可以按前后端分工，减少上下文切换，工作环境切换的成本，在出现某一端没活儿，另一端积压时，没活儿的可以去补位。另一方面，也会利用工程化的方法来降低切换的成本，比如 Docker，IaaS（基础设施及代码）等技术。

等待

在某一关中，两个厨师被隔离在两个小船上，上边的厨师只能切菜，而原材料却在下边的船上，下边的玩家要不时给上边的玩家扔原料，不然上边的玩家就只能干着急。他们只能「各司其职」，这就是企业里分工过细造成的工作依赖和部门墙。

敏捷软件开发 12 条原则第 4 条，说客户要和团队呆在一起，就是能尽量减少团队的阻塞。同样，破除和融合瀑布式流程各个阶段，构建脚本要尽量快，减少开发人员的等待。审批环节要尽量少，给团队更大的权限，减少审批的等待，包括购买更多商业软件 License。

缺陷

右边有三个炉子，刚开始会把米饭连续地放进去，但会差不多时间煮好，出锅的时候就很着急，煮过了就会着火，要花很多额外的时间来灭火。后来我发现这个问题，就调整了节奏，煮一锅米饭，干点儿别的，再煮另一锅米饭，这样出锅时就不会赶在同一时间，不会出现手忙脚乱。再者，有时手残，扔食材不准确，反而要过去重新捡起来，这既是缺陷，也带来了等待和额外的浪费。

软件研发中，通过单元测试，代码评审，重构技巧等实践，提升代码的内部质量，避免将大量时间花在问题的检测和修复上。

敲黑板

除了消除以上七种浪费，要取得高分或做好软件，还需要注意以下两点。

优先级排序

时间会让重要不紧急的事变得很紧急，并造成额外的负担。游戏中，订单有倒计时，超时的话会被惩罚。我们做软件也是这样，如果迟迟不交付，客户满意度就会下降。在对需求进行优先级排序时，既要考虑价值，又要考虑时效性，有的订单虽然价值高，但需要的原材料多，加工步骤多，时间长。产品负责人要定期梳理需求列表，调整优先级，并在 Product Backlog Refine 会议或 Sprint Planning 会议上，根据团队的估算，重新审视优先级。

回顾会议

游戏一旦开始，可以说是忙得没有时间思考，各种倒计时会让你心乱如麻，手忙脚乱。每一局游戏结束后， 就是反思改进的最佳时机，反思的结果可以马上应用到下一局游戏中，得到检验。好的就保留，无效的就舍弃。这便是持续改进。所谓敏捷，一方面在产品方向上试错，另一方面在团队工作方式上也是不断试错。我们把Development Team比喻成厨子团队，而Product Owner就是点菜人，根据点菜人的需求，厨子团队要“合作”、“跨职能”、“自组织”地完成任务。”

好啦，精益厨房游戏就介绍到这里，去和你的男女（zhu）朋（dui） 友（you）合作一把精益厨房吧！