為什么軟件開發方法論不管用？

無論大小項目，大型團隊還是我個人，陳腐的聯邦機構還是牛逼的硅谷公司，我都工作過。我學習并使用過至少20種編程語言。我還經歷過瀑布模型/預先設計模 型（BDUF：big design up front），結構化編程，自頂向下，自下向頂，模塊化設計，組件，敏捷，Scrum，極限，TDD，OOP，快速原型，RAD，還有我可能想不起來的其 它方法。我不敢肯定它們都管用。

【EDIT：讓我解釋一下本文的目的。我認為它們本身不能提供一個可預期的或可復制的軟件開發過程。我不認為使用一種方法論會使項目失敗。大多數軟件開發方法論試圖使編程成為類似工程的過程，在那方面它們是不足的。】

你該如何識別方法論管用？

一種方法論是否管用取決于條件：團隊生產力，快樂，保持，遵從，可預言，有責任，溝通，每天代碼行數，人月，代碼質量，工件等。如果你用對了地方，每個方 法論都管用。但是依照唯一的衡量方法就會出現問題，那就是按時、不超過預算地滿足需求，我還沒有看到任何方法論能夠取得一致的結果。

我自己的經歷有些軼事，但是它們也被我認識的每個程序員分享。這表明軼事是每個人都有的：軟件開發方法論的嚴格學習并不管用，因為控制所有變數是不可能的。

做個思想上的實驗：假定兩組程序員小組，相同的需求、日程規劃和預算，同樣的環境，相同的語言和開發工具。一個小組使用瀑布模型/BDUF，另一個使用敏捷技巧。很明顯這不是一個好的實驗：個人技能和團隊成員性格，彼此如何溝通，都將對方法論產生非常大的影響。

Alistair Cockburn 2003年的論文《軟件開發中的人和方法論》指出，“人們的狀態，因人不同，一個時刻與另一個時刻也不同，形成了團隊行為和結果的第一位的驅動力。他們彼此相處如何，性格與工作分工是否匹配等因素，都對方法論產生著巨大的、與項目相關的約束。結果表明了通常人們的性格特點對方法論有一定影響。”

我們自己最大的敵人

當我在1970年開始編程時，軟件開發稍稍通過項目經理、業務分析員和高級程序員等層級管理。我們沒有選擇語言和工具。我在公司里的一些大型的、復雜的項 目就是這樣做的。一些成功了，一些沒有成功。現在讓程序員選擇方法論和工作方式，還有語言和工具比較普遍了。分析員不再出現在大多數程序員的經歷里，項目 經理已經被演變成“team lead”和“Scrum master”，沒有管理授權，除了團隊一直通過的儀式，并不真正控制什么。

嚴格的管理，像甘特圖、日程規劃和文檔，被精簡為“利益相關者”和“用戶”，再被抽象為“用戶故事（user stories，也有叫用例的。譯者注）”。對于我來說，參與沒有成熟監督機制的項目變得普遍了。令人驚奇的是，留下程序員自己，他們不會回歸到冒失鬼的 編程方式——他們采用或創造更為嚴格的方法論，被 比我在1980年經歷的要多得多的儀式 所包圍。事實上，今天的程序員對他們的方法論比他們認為的70年代COBOL shop更為教條和宗教徒式。現在我常常老一套地陷入1-2個開發人員的項目中，背負著太多的過程和“最佳實踐”，而它們并沒有產生多大價值。

一旦編程小組采用了一套方法論，不可避免地一些小組成員，或許只有一個人專橫，就會要求嚴格地遵守，并轉化成宗教徒。被動侵害的后果扼殺了比任何方法論或技術決定更快的效率。

有管用的嗎？

我的個人經驗，被Cockburn的論文和Frederick Brooks的《沒有銀彈》 驗證過，當團隊關鍵人物分享共同愿景，Brooks稱之為“概念完整性（conceptual integrity）”。這不會催生任何特定的方法論，就算缺乏類似于一個過程也會出現。團隊每個人情投意合，事情就搞定了，我懂這種感受。我不理解的 是，為什么 我在過去有BDUF和業務分析員的日子里 比 現在 感覺更強烈。

我認為程序員應該在傾聽和協同工作上 比 儀式和工具上 投入更多的關心，我們應當對 過多的、號稱能夠使每個人神奇地提高效率的過程或方法論 保持懷疑。與其他人相比，或許社交技能對程序員太難了（我不確定這是真的），但是培養這些技能一定比嘗試另一種開發方法論取得更多的回報。

原文地址：http://typicalprogrammer.com/why-dont-software-development-methodologies-work/