• 关于“卖身契”的5个Why

    2010-11-13

    分类:咨询之道

    版权声明:转载时请以超链接形式标明文章原始出处和作者信息及本声明
    http://www.blogbus.com/skysw-logs/83870999.html

    背景介绍:Smoke Test,可以理解为系统基本功能测试,敏捷开发继续集成测试的首要环节;

     

    现象:

    团队成员不遵守 “在系统基本功能测试“Smoke Test”运行失败之后,除非修复测试,否则不能继续提交工作代码”的规则,在测试失败后,继续提交并非用于修复测试的工作代码;

     

    方案一:大讨论统一思想;

    Step 1: 团队成员表态,60% 的人选择了可以继续提交代码,不赞同上述规则;

    Step 2: 分组辩论,在大家提出了部署分层的持续集成的解决方案之后,同意了上述规则;

    Step 3: 赞同的童鞋们都签下了“卖身契”,感兴趣的可以到 这里 围观;

     

    方案二:5 Why from Lean;

    Why 1: 为什么出现这种情况?

    团队成员对于上述规则未能达到共识;

    Why 2: 为什么在 basic practice 上没有共识?

    1) 目前的 Smoke Test,不能帮助快速失败(Fail Fast),

        不能获得及时反馈,修复之后再提交的价值不大;

    2) 修复测试的时候,提交过程被阻塞,造成过多的未经验证工作代码被积压,

        从而提高了在提交之后,测试出现失败查错的难度、回滚提交的风险,

        行成闭环增量反馈;

    Why 3: 

    1) 为什么 Smoke Test 不能起到应有的作用?

    本应首先运行的 Smoke Test 被放置到最后运行,

    并且测试与数据之间的耦合程度较高,测试涵盖了数据迁移等等额外职责;

    2)为什么修复 Smoke Test 会造成大量提交的阻塞?

    团队规模发展到 40 多人,分成了三个小组,在中国、印度两地分布式开发,

    共用一个持续集成环境;大家需要频繁地提交工作代码;

    Why 4: 为什么三个小组要用一个持续集成环境呢?

    不一定,其中一个小组使用独立的持续集成环境已经有一段时间了,

    本地的持续集成环境运行与小组内工作相关的测试;

    开发过程中,小组内可以频繁的提交工作代码,及时得到反馈;

    保证每天两次的频率向主持续集成环境提交,若测试为通过,通过小组内部沟通协调,

    找到空闲资源及时修复测试;可以完全解决上述问题;

    Why 5: 这个解决方案有什么潜在风险?

    当小组提交到主持续集成环境出现问题,并且长时间不能修复的话,会再次造成提交阻塞;

    会给负责验收测试的 QA 带来较大工作压力;

     

    规则和法律一样,都是对遵守它们的人的一种保护,是为守规则、守法的人服务的;但是随着时间的迁移,遵纪守法的人们也会发现难以适从;

    这就是为什么在 2006 年的新刑法中对“正当防卫”的概念进行重新修订;试想下,就连“杀人有罪”这样的常识都会被被不断的补充、解释、界定;何况是团队内的规则呢;

    当人为规则所累的时候,规则就是去了意义;

    随着时间和场景的改变,任何已经存在的共识都有可能被打破,原有的任何知识都可能被颠覆!

    当它们发生时,你做好准备迎接挑战了吗?

     

    是片面的追求认识的统一?能够迅速的解决表面问题,但是忽略隐藏问题,往往会引入新的问题;

    还是 5 Why方法?能够一定程度上解决根本问题,要更多人参与讨论,了解问题背后更多事实;

    关注问题是对的,更因该探索问题背后更深层次的问题;

    强调规则是对的,更因该关注打破规则背后所隐藏的事实;

     

    抛砖新的引玉,新的 5 Why:

    获得一组龙飞凤舞的签名和揭开大家心中的 5 个 Why 哪个更重要?

    为什么只有大家都在嗟叹规则的被打破,而没有人问 Why?

    为什么团队中本来就有好的实践,却没有能够推广呢?

    分组是不是已经成为大团队持续改进的瓶颈?

    集体 Retro 是否必要?

     

    PS:Why 的 “最高境界”!

    分享到: