InfoQ

InfoQ

新闻

我的书签

登录注册 以永久保存书签。

该内容已经被标记书签!

标记书签错误,请重试!

敏捷与盲目自信

作者 Vikas Hazrati 译者 黄玲艳 发布于 2011年4月20日

领域
过程 & 实践
主题
企业级敏捷 ,
自动化操作 ,
敏捷 ,
代码覆盖率 ,
文档 ,
测试

盲目自信常常源于一厢情愿的想法。​它是一个状态,这个状态表现为,预期与现实可能相差很大,然而在一个特定的时间段内它却又给人一种一切尽在掌控之中的感觉。​敏捷开发中有很多这样的情况,这导致一个团队​即使在每况愈下时,也要坚持那些盲目的自信​。

Mike Griffiths引用了Malcom Gladwell在盲目自信的高低程度与信息化呈现水平相关中的一段话,是一个关于精神科医生展示有关病人信息的例子。根据信息图表显示,他们的自信水平为25%,评估准确度大约为25%。然而,​当他们获取到约10页信息的数据量时,他们的精确度稍微提高了一点到了29%,但他们的自信增加到了90%。​

Matt认为,一些公司在人为制造​自信。他们将规范、文档,以及过程作为可信赖的东西。这些可信赖的东西给了他们错误的信心,认为自己不会出现可怕的错误。​

问题是,当你通过文档以及其他东西建立自信时,你已经对你自己做出了定论,而那些假设可能是错误的(一旦认清现实,假设常常被丢到一旁)。好吧,你可能觉得你一定会有一个完美的方案,认为这样更好。但是如果它是一个失败的方案,那么又有什么意义呢?

这同样也适用于测试。J.B.Rainsberge曾经提到“集成测试是一个骗局”。原因是,依赖于编写不同的集成测试,一个团队可能会产生盲目自信的感觉。根据Mark Needham的说法,单元测试也会这样

确保我们的单元测试真的测试了一些有用的东西,而不是在写代码和维护方面的成本远超我们获取的利益,这点是非常重要的。

同样,Doug Rathbone也提到​许多团队对于拥有自动化构建机制非常满意。​然而,关键不是要有自动化构建机制​,而是要有自动地构建和部署的能力。

如果你不能用自动化的方式进行构建部署,那么你只需要降低生产链上人为的错误也能达到不错的结果。同时,以你的能力轻易地推动一个项目也会给你自己盲目的自信。​

另一个会产生盲目自信现象的情况是代码冻结者是干系人。Jonathan Leffler​问过一个有趣的问题,有关代码冻结状况下盲目自信的价值。​

我认为​将这些状况称为"代码冻结"​就是给干系人提供盲目自信的机会。​甚至可能是我们自己伪装为"代码冻结"的​,因为根据Scrum原则,每个冲击阶段之后,我们要有一个可交付的软件,这也是我们为什么要使用Scrum的原因。因此我们必须将它称为Scrum期望的方式,而不是它真实是什么。

另外,大多数盲目自信的建立也与规范有关。根据Mike的说明:

规范​是另一个易于产生错误的地方。当我们花费大量的时间收集规范、验证规范,以及​详细修改流程和异常的时候,我们已经在其中建立了自信的感觉。

在你的项目中,你有看到帮助建立了盲目自信但却没有增加价值的​其他地方吗?​

英文原文地址:Agile and the Crutches of False Confidence

译者 黄玲艳 是一名资深Flash工程师,做过互动产品开发及音视频等多媒体产品开发,现供职于新浪,负责部门内Flash开发团队。

做为一个一句话提醒还不错,做为一篇文章,感觉干货少了点。 发表人 Tong James 发表于
直译为虚假的信心,似乎更为妥当 发表人 张 林 发表于
Re: 直译为虚假的信心,似乎更为妥当 发表人 anchuan qian 发表于
Re: 直译为虚假的信心,似乎更为妥当 发表人 张 林 发表于
  1. 返回顶部

    做为一个一句话提醒还不错,做为一篇文章,感觉干货少了点。

    发表人 Tong James

    如题

  2. 返回顶部

    直译为虚假的信心,似乎更为妥当

    发表人 张 林

    盲目自信似乎是一种个人行为,就像上面的评论一样,作为一句话提醒还不错。其实文章中讨论的内容应该主要是:
    在工作中人们往往会自觉或不自觉的利用他人思维的缺陷(对某种产物或行为的虚假的信心,而忽视了结果),创造出虚假的信心,从而蒙蔽他人或自己,误导工作。

    我读完后,收到干货如下:
    1. 每个人都存在思维缺陷,这里的例子中包含了我们对文档、测试、自动化、代码冻结等产物或行为存在的虚假的信心。
    2. 在工作中注意发现团队或他人的这种倾向,少受蒙蔽。
    3. 在工作中注意发现自己的这种倾向,少蒙蔽他人和自己。

  3. 返回顶部

    Re: 直译为虚假的信心,似乎更为妥当

    发表人 anchuan qian

    我觉得使用软件开发实践,要理解背后的真正目的,只有在切实需要的时候引入。不要把问题的解决方法当成问题的本身。否则,盲目的追求敏捷实践,就和传统的过程的开发方法没有区别。

  4. 返回顶部

    Re: 直译为虚假的信心,似乎更为妥当

    发表人 张 林

    说得透彻。“我们有计划”,“我们用Scrum”,“我们使用了TDD”,这些话语会让不少人(尤其是领导)产生信心感觉安全,但实践不代表结果。拿出5个为什么,一问就全露馅了。