博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
敏捷游戏:从硬币游戏学习Scrum敏捷方法
阅读量:5960 次
发布时间:2019-06-19

本文共 3046 字,大约阅读时间需要 10 分钟。

  在中都介绍了这个硬币游戏,我觉得不错,如果游戏者真正参与进来,应该能够体会到较多的敏捷思想。而最近项目组也来了很多新的MM,她们对敏捷不太清楚,而这个游戏又不错,所以我就在项目组中组织了一次游戏,游戏中我进行了一些修改。本篇向大家介绍一下这个游戏,以及游戏中我的一些体会。

游戏介绍

  • 时间:1.5-2个小时
  • 人物:客户方(项目发起人,项目负责人)、厂商(N个小组,每个小组由一个管理者和工作者组成)
  • 物品:
    • 硬币(N枚 1元、5角、1角、5分、1分)
    • 秒表:可用手机来记录
    • 笔纸:画时间图,我是直接在玻璃墙上画的
  • 规则:
    • 工作
      • 工作者和项目负责人用手翻硬币
      • 项目发起人和管理者负责计时
    • 翻硬币:
      • 硬币传递到下一组时全是正面或反面
      • 会规定用一只手还是两只手
    • 计时:为了把客户方对项目的影响考虑进来,我修改了计时人的规则,客户方项目负责人不计时,游戏后面几轮的翻硬币时间会影响总体时间
      • 各小组内部完成时间:由管理者记录小组有硬币存在的时间
      • 首次交付时间:由项目发起人记录第一个小组接到第一枚硬币开始到收到第一枚硬币的时间
      • 项目验收时间:由项目发起人记录第一个小组接到第一枚硬币开始到收到最后一枚硬币的时间
    • 规模:小组间每次批量传递的硬币个数,游戏中每轮的规模会有所指定
    • 单手、双手:每轮中翻硬币时会限定用单手还是允许双手进行
    • 传递:每次传递由项目负责人开始,负责人将所有硬币翻成正面后,按照规模大小进行硬币的传递,下一组接到硬币后把硬币翻成另一面后再交给下一组,以此类推,直至硬币交回给客户发起人
    • 产品价值:客户收到的硬币面额值表示为客户收到的价值,面额越大价值越大
    • 限定时间:从第一小组收到硬币开始计时到停止传递的时间段
  • 每轮游戏介绍
    • 第一轮:规模=所有硬币,单手
    • 第二轮:同第一轮
    • 第三轮:规模=5个硬币,单手
    • 第四轮:规模=5个硬币,双手
    • 第五轮:规模=任意,双手
    • 第六轮:规模=4个硬币,双手
    • 第七轮:限定时间=40秒,这一轮开始5秒后,我会额外给客户项目负责人几枚1元和5角的硬币,这是项目负责人为了传递最大价值的硬币,需要把这几个硬币全部翻成正面,并且与现有硬币组成4个硬币为一个传递规模交付给第一个工作小组
    • 第八轮:规模=4个硬币,双手,所有组可以根据之前的成绩自由重新组合搭配
    • 第九轮:规则同第八轮
    • 第十论:限定时间=40秒,由于第八轮重新组合过队伍,所以与第7轮的差别就是人员组合不同

进行游戏

  我抽屉里正好有一些硬币,拿了大概20几个硬币,还有好几个1分的呢:)硬币准备好了之后,我召集大家在一起,原计划半个小时,因为我想每轮大概四五分钟,来个七八轮也就是半个小时,加上介绍规则等等也就差不多半个多小时。不过后来可以看出,这个游戏我们到下午6点多才结束,总共进行了1个半小时,如果中间再加些分享等等时间最好在2个小时。

    

  • 讲清规则,以免大家做错了
    我把规则讲完后,客户方还是蛮聪明的,一下子就想到了用一张纸作为运输工具,这样的交接效率会较高
  • 第一轮:规模=所有硬币,单手
    瀑布式开发,这一轮最后一个小组的工作者出现一个故障,翻到一半说分不出哪是正反面了,由于方向错误导致延迟较为严重
  • 第二轮:同第一轮
    由于第一轮熟悉了规则和如何翻硬币,大家也变成翻硬币的熟练工了:)这一轮时间明显有所下降,总时间由3‘41’‘变成2’21‘’
  • 第三轮:规模=5个硬币,单手
    这一轮做了两次,因为第一次中间计时出现错误。由一次性做完改为迭代进行,交付时间和验收时间都明显下降,总时间由2‘21’‘变成56’‘
  • 第四轮:规模=5个硬币,双手
    解放生产力,有单手变成双手,提高工作效率,时间都明显下降,部门工作时间由平均23’‘变成15’‘,总时间由56’‘变成46’‘
  • 第五轮:规模=任意,双手
    由于选择了第一次传递2个,所以首次交付时间明显缩短,由23’‘变成14’‘,但是可以看到验收时间并没有什么变化,由46’‘变长45’‘。传递过程中,出现了有些小组某一时刻空闲着。
    任意组合时,客户发了几个奇数规模的硬币,由于这时可以双手翻,所以奇数规模传递会影响效率,这是由客户引起的问题
  • 第六轮:规模=4个硬币,双手
    规模定为4个后,传递过程中没有出现工作停止的小组,虽然首次交付时间由14’‘变成19.5’‘,但是可以看到验收时间由45’‘变成39’‘了
  • 第七轮:限定时间=40秒
    在我给硬币给客户方时,客户翻动硬币出现问题,延误了时间,导致产品传递价值明显减少,这也是客户引起的
  • 第八轮:规模=4个硬币,双手,所有组可以根据之前的成绩自由重新组合搭配
    由于人员重新组合,剩下的都是翻硬币较快的人员,而且大家都撤离了一张桌子来保证减少硬币传递时间,所以这次比第六轮时间都要减少,总时间由39’‘变成36’‘
  • 第九轮:规则同第八轮
    大家都想再来一次,所以第八轮后再进行了一次,总时间由36’‘变成35’‘,但是可以看出没有明显的变化了
  • 第十论:限定时间=40秒,由于第八轮重新组合过队伍,所以与第7轮的差别就是人员组合不同
    这次进行了两次,因为第一次进行后发现同第七轮一样,但是因为人员重组过,并且客户方也没有发生上次的传递失误问题,所以按道理应该肯定减少,所以重新进行了第二次。这一次,在37’‘就把所有硬币传递完毕,但是在遗留了一个5分硬币在一张纸下面。
  • 简要的分析了一下数据变化的原因
    由普遍变成迭代,由单手变为双手,由新手变为熟练工,由分配角色到自我组织,这些都是改变数据的原因

看板

  • 过程中记录每轮的时间

   

  • 各组完成总时间

  • 第一次交付时间和最后验收时间,以及指定时间交付的价值

感悟

  1. 产品开发时必须明确方向,否则就会出现不知道正反面而慌了手脚。没有方向时可以假设方向,然后去快速验证。
  2. 迭代开发比瀑布式开发明显可以更快速的进行价值的传递
  3. 团队的绩效可以通过工具(由单手变双手)、经验(经过多轮工作),但是要想有大的飞跃,更需要方法(由瀑布方式改为敏捷方式)的创新
  4. 规模的大小会影响所有时间,一开始并不知道什么规模是最优的,由全部变成5个,由任意变成4个,Scrum中的迭代速率需要经过几次迭代后才能够度量出来
  5. 从最后限定时间传递价值可以看出,硬币的面值就像需求的优先级,传递价值时我们首先关注的是最高优先级的需求
  6. 各个小组的工作时间都有所波动,但是并不影响整体时间,所有有时优化一个流程时,更多的需要从整体进行考虑,而不能只是一味的进行单部门的优化
  7. 整个过程是由客户方和厂商一起完成的,也就是说对于产品的完成必须双方的沟通、反馈来配合完成
  8. 如果大家配合更积极,参与更投入,时间会更快,所以敏捷中专注很重要
  9. 传递前大家总是计划好先传递那组,后期限定时间的几轮由于有更高面值硬币加入,所以会打破原有计划,这时我们做的不是遵循计划,而是随需应变

回顾

  1. 每轮之后就分析数据,讨论数据变化的原因以及后续改善的方式,这其实就是敏捷的回顾会议内容。
  2. 时间估计不足,由预定半小时进行了1个半小时,以后对于这种游戏需要考虑中间讲解以及进行过程中的一些延时间
  3. 感觉游戏的方式比一味的知识传授型的方式要好一些,如果这两种结合起来进行讲解可能会更容易被大家理解
  4. 硬币准备得更好一些,这样进行最后一轮时可以有剩余的硬币,这样可以更好的表示优先传递高价
 本文转自 jingen_zhou 51CTO博客,原文链接:http://blog.51cto.com/zhoujg/518062,如需转载请自行联系原作者
你可能感兴趣的文章
iOS App 之间的相互跳转
查看>>
iOS基于百度地图的开发 (百度地图BMKSearch问题) (作者不允许转载 我也没办法 ......
查看>>
往事两三则
查看>>
使用LiveData和DataBinding进行双向绑定
查看>>
Convert Url to InetAddress
查看>>
oracle 限制特定ip登录
查看>>
解酒方法
查看>>
vi 命令
查看>>
1.1
查看>>
Elasticsearch 安装与启动
查看>>
[logstash-input-redis]插件使用详解
查看>>
优化应用的电池寿命(笔记)-1
查看>>
SSH Secure Shell Client
查看>>
JFinal源码分析------初始化那些事儿
查看>>
处理 允许远程协助连接这台计算机 灰色
查看>>
使用Jquery 加载页面时调用JS
查看>>
css+div+jquery弹出层
查看>>
求职相关(链接,不定期更新)
查看>>
pdo 连接数据库 报错 could not find driver 解决方法
查看>>
设计模式之策略模式
查看>>