盲目自信常常源于一廂情愿的想法。​它是一個狀態，這個狀態表現為，預期與現實可能相差很大，然而在一個特定的時間段內它卻又給人一種一切盡在掌控之中的感覺。​敏捷開發中有很多這樣的情況，這導致一個團隊​即使在每況愈下時，也要堅持那些盲目的自信​。

​　　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