圍繞軟件開發(fā)實踐和方法論，總有很多教條式的口水仗。階段式（phase-gate）方法能夠有效管理軟件開發(fā)過程的風(fēng)險，還是說只是風(fēng)險管理中的花哨噱頭？TDD真的能夠促生出高品質(zhì)軟件？結(jié)對編程是代碼評審的有效替代抑或只是增加了商議溝通代價？我想說，雖然缺乏證據(jù)判斷這些論調(diào)的謬處，但有兩條常用的法則能夠幫助我們選擇好的實踐，同時，提升我們所提供軟件的價值：劃小開發(fā)周期以及提升反饋效率。 Michael Feathers給出了以下觀點：

我認為，到了最后，我們還是得倚重開發(fā)者的能力，這才是個更重要的考量因素，而非選擇哪門語言或糾結(jié)于方法論間的細微差別[1]。坦誠地說，我們都清楚這點，但我們看起來好像過度糾結(jié)于開發(fā)能力是關(guān)鍵因素這事兒上。或許這是個經(jīng)濟學(xué)里一個被廣泛接受的觀點的引申，但如果人是可以輕易輪換的（隨便找個人都能頂上），那才是堪稱理想的。

問題是，我們怎樣才能找到有（合適）技能的開發(fā)者？IT界從未很好地定義個體生產(chǎn)率，從這點來看，那么，要找到合適技能的開發(fā)者就是個很難解決的問題。代碼行數(shù)（Lines of code） – 在現(xiàn)在仍然是一個主流的度量方法 – 深陷“一行代碼一個責(zé)任”泥潭，這并不是一個好的方法。而度量工作小時數(shù)則是鼓勵（個人）英雄式舉動 – 經(jīng)驗表明，“英雄們”通常就是導(dǎo)致項目延期的人，依賴“英雄”往往是一開始就采取的不該采取的冒險行動，長時間工作導(dǎo)致人變得魯鈍，并導(dǎo)致低質(zhì)量軟件出現(xiàn)。目前還沒有被普遍接受的針對IT專業(yè)人才的專業(yè)要求系列標準和雇用范式，招聘好的人才，是一門（招聘）藝術(shù)，而非（招聘）工程。

心理學(xué)家至少對這個問題進行了研究：為什么IT業(yè)的技能很難被掌握和度量Daniel Kahneman說（Thinking Fast and Slow），掌握技能有兩個基本條件：一個環(huán)境足夠規(guī)律以便可預(yù)測；有機會通過長時間實踐來學(xué)習(xí)掌握這些規(guī)律。

但是典型的軟件項目往往是沒有規(guī)律及可預(yù)測環(huán)境的。項目成功的唯一正確度量就是：最終的結(jié)果通過整個生命周期里的實施達到了預(yù)期目標嗎？ 很難知道什么關(guān)鍵活動導(dǎo)致了項目成功和失敗，很少有人能夠通過舊有或現(xiàn)有的項目獲得答案。幾乎不可能判定哪些決策導(dǎo)致了成功或失敗（在人工智能領(lǐng)域，這叫作信度分配問題）。

這些因素造成了IT專業(yè)人員很難掌握引導(dǎo)產(chǎn)品和服務(wù)走向成功所需的能力。然而，開發(fā)者掌握能幫助他們更高效地達到目標的技巧，將使他們更有動力 – 通常稱之為“開發(fā)完成”，盡可能快的、不考慮是否功能被集成以及生產(chǎn)就緒。類似的場景也常出現(xiàn)在其他功能性實施領(lǐng)域。

實際的軟件項目是復(fù)雜的，沒有規(guī)律可循，這會導(dǎo)致另一個問題 – 為了證明某種技術(shù)、實踐和方法論是實際有效而收集相關(guān)數(shù)據(jù)是極度困難的，幾乎不可能在脫離收集環(huán)境的情況下歸納出這些數(shù)據(jù)。

在Laurent Bossavit的好書The Leprechauns of Software Engineering中，他抨擊了軟件開發(fā)的一些慣式，比如“成本變化”（或“缺陷成本”）“曲線”，這些慣式是許多其它的軟件開發(fā)方法論知識基礎(chǔ)，稱開發(fā)人員生產(chǎn)率的變化是一個數(shù)量級（參照確定性金字塔原理）。Laurent Bossavit說明了相關(guān)依據(jù) – 很多人依賴從計算機科學(xué)專業(yè)學(xué)生進行的非正式試驗或是從無法被有效控制的項目中收集小量數(shù)據(jù)。這些研究組織的給出的論調(diào)基礎(chǔ)往往是不健全的，數(shù)據(jù)缺乏分析，而且，最過分的是調(diào)查結(jié)果普遍遠遠超出了他們的適用領(lǐng)域[2]。

因此，不太可能輕易下論斷敏捷開發(fā)實踐就比瀑布模式之流合適，反之亦然。“方法大師”的見解其實也沒太大指導(dǎo)意義，就像Kahneman說的，“人們在想法方面的信心，并非是有效行事可倚重的因素…當評估專家的想法，即使在有規(guī)律可循的情況下，你也一定要想清楚是否有合適時機可以引入其想法的可能性”。就像Ben Butler-Cole指出的（why software development methodologies rock），引入一種新方法往往會帶來一些影響。

你可能會認為當我們決定怎樣運作一個團隊時，我們就陷入了被動。但細想一下為什么軟件開發(fā)無章可循？為什么在這個環(huán)境里很難進行一些試驗以及獲取技能？什么實踐和決定會導(dǎo)致成功或失敗？其中的根原因就是：環(huán)境是不規(guī)律的，做出變更與理解變更帶來的結(jié)果之間的反饋過程太長了。這里的“變更”一詞是指廣義上的需求變更、方法變更、開發(fā)實踐變更、商業(yè)計劃變更、代碼或配置變更等等。

還是有一些辦法幫助縮短周期的，比如當我們應(yīng)用精益軟件開發(fā)思想 – 一個很重要的方法。縮短開發(fā)周期在大型產(chǎn)品開發(fā)中是很重要的：在Bret Victor的精彩視頻Inventing on Principle中提到，“如此多的創(chuàng)新被發(fā)現(xiàn)，只要你真正理解了你在做什么，你就能發(fā)現(xiàn)任何事物”。

但對我而言就是這樣的：我們幾乎不可能實踐持續(xù)改進、學(xué)會怎樣使團隊或個人變得更好、掌握成功創(chuàng)建大型產(chǎn)品與服務(wù)所需的技能。除非我們聚焦于盡可能使反饋間隔時間縮短，以便實際洞察其間關(guān)聯(lián)，以及辨別原因和影響。

事實上，從想法到反饋的周期盡可能短的好處是如此明顯和重要，應(yīng)該把其作為商業(yè)模式中要遵循的一個重要原則。如果你糾結(jié)于要把你的產(chǎn)品創(chuàng)建成一個用戶安裝式的軟件還是SaaS模式（software-as-a-service，軟件運營服務(wù)模式，軟件即服務(wù)），這時的想法會自然而然地推動你強烈考慮 SaaS模式（有感而發(fā)）。如果你要重建你的系統(tǒng)（包含硬件），應(yīng)該考慮怎樣盡快實現(xiàn)原型（how you can get prototypes out as quickly as possible），以及模塊化硬件和軟件，以便你可以快速和獨立地整合。3D printing（三維打印成型技術(shù)）技術(shù)看起來在這方面有著巨大的用武之地，因為它可以滿足軟件開發(fā)應(yīng)用實踐朝硬件系統(tǒng)（原型呈現(xiàn)）的演進。如果你想如愿以償?shù)乜s短周期，或多或少按多功能型團隊（cross-functional teams）方式運作是需要的。 軟件方法論，即使雇用一群牛人并讓他們自我組織，也是糟糕的，因為他們時常搞得“cargo-cult”（貨物崇拜，敏捷開發(fā)里的知名小故事，形而上）：我們在做stand-ups（每日站立會議），我們有優(yōu)先順序的backlog（優(yōu)先待辦事務(wù)），我們甚至看在老天的份上實踐了continuous integration（持續(xù)集成）。我們的到頭來的結(jié)果為什么還這么差呢？因為你忘了最重要的事情：建立一個學(xué)習(xí)能力和適應(yīng)能力都很好的組織。

1. 雖然像Laurent Bossavit說的（私下交流），“一個開發(fā)者掌握的技能，受限于他/她所掌握的方法及他/她偏好一種語言甚于其它語言”。

2. 我并非建議放棄在軟件開發(fā)中的可行性試驗，在這里的上下文中，我這么闡述是對的。恰恰相反的是，我說的是我們并沒有努力去做好，做得還遠遠不夠。

原文鏈接：http://continuousdelivery.com/2012/08/why-software-development-methodologies-suck/

譯文鏈接：http://www.ituring.com.cn/article/13466