• 敏捷培训有感


    一周前参加了个关于敏捷的培训,今天回想起来,记忆最深的是两个游戏环节。

    游戏一

    组装 10 只同样小狗,每只小狗需要 5 块积木,流水线上 5 个人,每人负责固定的一块积木的拼接。

    这个游戏一共玩两轮,两次的玩法不一样。

    • 第一次:上一个人组装完 10 个后,再一次性的交给下个一人。
    • 第二次:上一个人每组装完 1 个,就交给下一个人。

    第一次的方式代表「瀑布」,第二次的方式代表「增量」,游戏是想说明「增量」比「瀑布」效率高。

    游戏结束后,同事质疑:“第二次完成时间比第一次短,看似更优,但对他个人而言,他的工作时长变长了。”老师似乎没理解,匆匆进入了后面的章节。我来分析分析这个问题。

    假设流水线分 3 步,分别由工人 A、B、C 完成,每个人的效率如下:

    工人 单个零件组装消耗时间
    A 1
    B 2
    C 1

    如果采用「瀑布」的方式,上个人组装完 10 个后,下个人才开始,每个人工作时长如下:

    工人 单个零件组装消耗时间 开始时间 结束时间 耗时
    A 1 0 10 10
    B 2 10 30 20
    C 1 30 40 10

    如果采用「增量」的方式,上个人每组装完 1 个,就交给下个人,每个人工作时长如下:

    工人 单个零件组装消耗时间 开始时间 结束时间 耗时
    A 1 0 10 10
    B 2 1 21 20
    C 1 3 22 19

    可以看到,C 的工作时长翻倍了,原因是 C 每做完一个都要等一分钟。C 的时间被打碎了,而这种零碎的时间是难以利用的。如果 C 很贵,代价就很高。这种情况可以推迟 C 的开始时间,等 B 完成了一半后,C 再开始。

    引入敏捷,不是把固定流程引进来就完了,要根据团队情况、任务情况动态调整才行。


    游戏二

    一个铁盒,里面装了黄色珠子和红色珠子。盒子打开前,可以随意摇晃,盒子打开后就不可以动了,然后从盒子里挖满满一铲珠子,看谁挖的红色珠子最少。

    游戏也进行两轮,看第二次玩有没有比第一次进步。

    有意思的是当大家都不知道如何改进时,一个声音打破了僵局:“红色珠子比黄色的重,多摇摇把红色珠子摇到下面就可以了”。之后大家就都认可了这个说法,去用力地摇盒子。但实际上红色珠子并不比黄色珠子重,挖到多少红色珠子是随机的。游戏想告诉大家「在框架不变的情况下,再怎么使劲,也提升不了效率」。

    我比较感兴趣的是那个「打破僵局的声音」,以前我喜欢这样的声音的,因为它推动了事情的发展。但这次也让我看到,这个声音可能让大家都走到一个错误的方向。所以发出「打破僵局的声音」的人,一定不能是有权威的人,因为大家会停止思考,跟着有权威的人的思路走。发出「打破僵局的声音」的人,需要是一个大家敢于质疑的人。

  • 相关阅读:
    为什么大多数IOC容器使用ApplicationContext,而不用BeanFactory
    重温Java泛型,带你更深入地理解它,更好的使用它!
    看完了这篇,面试的时候人人都能单手撸冒泡排序!
    JAVA基础4---序列化和反序列化深入整理(Hessian序列化)
    VS Code 变身小霸王游戏机!
    equals()方法和hashCode()方法详解
    openFeign远程调用时使用Mybatis-plus的IPage接口进行返回分页数据失败的记录
    通过express快速搭建一个node服务
    UML 类图
    jdk命令行工具系列——检视阅读
  • 原文地址:https://www.cnblogs.com/apolis/p/13991768.html
Copyright © 2020-2023  润新知