敏捷与盲目自信
盲目自信常常源于一厢情愿的想法。它是一个状态，这个状态表现为，预期与现实可能相差很大，然而在一个特定的时间段内它却又给人一种一切尽在掌控之中的感觉。敏捷开发中有很多这样的情况，这导致一个团队即使在每况愈下时，也要坚持那些盲目的自信。
Mike Griffiths引用了Malcom Gladwell在盲目自信的高低程度与信息化呈现水平相关中的一段话，是一个关于精神科医生展示有关病人信息的例子。根据信息图表显示，他们的自信水平为25%，评估准确度大约为25%。然而，当他们获取到约10页信息的数据量时，他们的精确度稍微提高了一点到了29%，但他们的自信增加到了90%。
Matt认为，一些公司在人为制造自信。他们将规范、文档，以及过程作为可信赖的东西。这些可信赖的东西给了他们错误的信心，认为自己不会出现可怕的错误。
问题是，当你通过文档以及其他东西建立自信时，你已经对你自己做出了定论，而那些假设可能是错误的（一旦认清现实，假设常常被丢到一旁）。好吧，你可能觉得你一定会有一个完美的方案，认为这样更好。但是如果它是一个失败的方案，那么又有什么意义呢？
这同样也适用于测试。J.B.Rainsberge曾经提到“集成测试是一个骗局”。原因是，依赖于编写不同的集成测试，一个团队可能会产生盲目自信的感觉。根据Mark Needham的说法，单元测试也会这样。
确保我们的单元测试真的测试了一些有用的东西，而不是在写代码和维护方面的成本远超我们获取的利益，这点是非常重要的。
同样，Doug Rathbone也提到许多团队对于拥有自动化构建机制非常满意。然而，关键不是要有自动化构建机制，而是要有自动地构建和部署的能力。
如果你不能用自动化的方式进行构建部署，那么你只需要降低生产链上人为的错误也能达到不错的结果。同时，以你的能力轻易地推动一个项目也会给你自己盲目的自信。
另一个会产生盲目自信现象的情况是代码冻结者是干系人。Jonathan Leffler问过一个有趣的问题，有关代码冻结状况下盲目自信的价值。
我认为将这些状况称为"代码冻结"就是给干系人提供盲目自信的机会。甚至可能是我们自己伪装为"代码冻结"的，因为根据Scrum原则，每个冲击阶段之后，我们要有一个可交付的软件，这也是我们为什么要使用Scrum的原因。因此我们必须将它称为Scrum期望的方式，而不是它真实是什么。
另外，大多数盲目自信的建立也与规范有关。根据Mike的说明：
规范是另一个易于产生错误的地方。当我们花费大量的时间收集规范、验证规范，以及详细修改流程和异常的时候，我们已经在其中建立了自信的感觉。
在你的项目中，你有看到帮助建立了盲目自信但却没有增加价值的其他地方吗？
