為什么軟件開發方法論會失靈?

　　作者簡介：Jez Humble是ThoughtWorks公司首席咨詢顧問，《持續交付》一書的作者，致力于幫助企業快速、可靠地交付高質量軟件，經常在各種敏捷技術大會上發表演講，擁有牛津大學物理學學士學位和倫敦大學民族音樂學的 碩士學位。2000年至今，他曾在各行業和不同技術領域擔任系統管理員、開發人員、培訓人員、咨詢師和經理人員?！冻掷m交付》是第21屆Jolt大獎獲獎作品，被譽為2010年最重要的技術書。

　　譯者簡介：蘇光榮，現一淘網廣告技術部高級測試開發工程師。2004年～2009年在多家軟件公司擔當測試工作師，各種類型的測試都有所涉及。2009年進入淘寶，從事搜索引擎的測試工作。

　　譯者序：軟件工程沒有銀彈。相對于流程、方法，人仍然是制勝武器;鑿子到處都是，米開朗基羅只有一個。追風、盲目照搬和套用、流于形式的實踐某種軟件開發方法，并不能給你帶來任何好處。只有理解方法的精髓和真正實質并實踐之，才能達到預期效果。是軟件開發方法失靈了嗎?不是，是我們沒有用好;我們還應該相信軟件的各種模型、定律嗎?是的，但不是盲信和盲從(cargo-cult)。Jez Humble在這篇文章里從獨特的角度提出了他對敏捷方法、乃至各種軟件開發方法的精髓的見解，很有啟發性。

　　圍繞軟件開發實踐和方法論，有很多教條式的爭論。階段性檢查方法在軟件開發風險管理方面是真的有效，還是只不過一些花拳繡腿罷了?TDD真的能帶來更高質量的軟件嗎?結對編程是比代碼評審更有效的替代品嗎?或者只是為了提高咨詢費而已?

　　我將要闡釋的觀點是，盡管缺乏科學論據，但是有兩個原則可以幫助我們選擇好的實踐來提高我們所交付軟件的價值：縮短周轉時間和增加反饋。

　　Michael Feathers有如下觀點：

　　我認為，我們最終不得不接受這樣的事實：相對于語言的選擇或者方法論的不同，開發者的技能差別是更加決定性的因素1。坦白的說，我認為我們都明白這一點，但是看起來被某種錯覺欺騙，認為語言或者方法論才是問題的關鍵。也許這是一種根深蒂固的思想的延伸：從經濟學的角度看，勞動力可以隨意替換是一種完美的現代化生產場景。

　　問題是，如何找到熟練的開發人員?由于IT領域個人生產力的概念從來沒有被滿意地定義出來，所以，這是一個非常難以解決的問題。代碼行——仍然是一個流行的度量標準——有重大的缺陷，因為一行代碼是債務，非人們通常認為的資產。衡量工作時數會鼓勵英雄主義行為，但是經驗表明，這些“英雄”通常也是那些在早期冒了不可接受的風險而導致項目延期的人，而且，長時間的工作會使人疲勞，產生低質量的軟件。目前還沒有一套能讓人們普遍接受的，適用于評判IT專業人士專業技能的專業標準或招聘系統，招聘優秀的IT員工更多的是一種藝術而不是科學。

　　至少，心理學家們解釋了IT技能難以習得和評估的原因。Daniel Kahneman在《思考，快與慢》中指出，獲取一項技能需要兩個基本條件：一個有規律性足以預期的環境，以及通過長期實踐來學習這些規律的機會。

　　但是傳統的軟件項目恰好是無規律，不可預期的。項目成功的唯一的好的標準——項目結果(產品或服務)在其生命周期中是不是創造出了預期的價值——距離那些導致成功或者失敗的重大決策是如此的遙遠，以至于項目團隊成員甚至很少能在項目帶來收益的現場得到反饋。實踐上幾乎不可能判定哪些決策導致了成功或者失敗(在人工智能領域，這被叫做功勞分配問題)。

　　這些因素造成了IT專業人員很難掌握引導產品和服務走向成功所需的能力。取而代之的是，開發者們都學會了那些能最快達成組織規定的目標的能力——通常是盡可能快地宣稱他們的開發工作已經完成，而不去考慮功能是否能被集成，是否可以上線——其他領域也是如此。

　　事實上，軟件項目是復雜系統的集合體，而不是有規律的環境。這還會帶來另外一個問題：證明技術、實踐、方法真正有效的數據非常難以采集，將之應用到其它項目幾無可能。

　　在Laurent Bossavit的著作《軟件工程的妖精》中，他對一些軟件開發傳說進行了猛烈的抨擊，例如：“變更的成本”(或者說“缺陷的成本”)、“曲線”、開發人員的生產率水平差異達一個數量級、不確定性模型、以及許多其他軟件開發方法論的基石級的觀點。他表示，這些理論，還有許多其他的理論，都只有非常小的數據集支持，這些數據集是從計算機學科的非正式的學生實驗、或是一些不能有效控制的項目中收集而來的。形成這些理論的研究常常在方法論上是不牢靠的，在數據上是缺乏分析的，更過分的是，對這些調查結果的一般化大大超越了它們的適用領域2。

　　因此，不要拿一些泛泛的比較太當一回事：是否敏捷開發比瀑布模型更好，或者更差。“思想領袖”的直覺也沒有多大參考價值。就像Kahneman說的，“人們在直覺上的信心并不可靠...在評估專家直覺的時候，你應該考慮是否有足夠的機會去發現更多的線索，即使是在有規律的環境里也是如此”。Ben Butler-Cole在一篇帖子“why software development methodologies rock”中指出，引進一種新的方法論的行為可以產生一些引進者預期達到的結果。

　　你可能認為，這將使我們手足無措，不知道如何來運轉團隊。但是想想為什么軟件開發不是一個有規律的環境?為什么開展實驗、學習技能、衡量哪些實踐和決策帶來成功或者導致失敗是如此的困難?所有這些情況的根本原因——造成環境缺乏規律性的原因——在于發生變更和理解變更結果之間的反饋環過長。這里的“變更”應該被廣義地理解為需求的變更、方法的變更、開發實踐的變更、商業計劃的變更、代碼的或配置的變更等。

　　縮短循環時間有很多好處，這是當我們將精益思想應用到軟件開發中時最重要的一個原則。短周期對于創造偉大的產品是非常重要的，正如Bret Victor(譯者注：蘋果公司的UI交互設計師)在他精彩的“ Inventing on Principle”視頻(譯者注：關于這個視頻，這里有一篇中文評論文章)中說的那樣，許多的創造只是發現，如果你不知道自己在做什么(產生了什么結果)，你就不能發現任何東西。

原文轉自：http://www.anti-gravitydesign.com