[樂譯 第11期] 為什麼軟體開發方法論讓你覺得糟糕？

第一次翻譯樂譯文章，結果翻譯的時候發現這篇比較難啊......，之間停了兩天出去走了走。
本人2gua，你認識就認識了，不認識也就不認識了。
作者試圖告訴你，方法無形，不能形而上，你得緊緊抓住劃小開發週期以及提升反饋效率這兩大法寶，其它的神馬基本上都是浮雲，組建多功能型團隊建立一個學習能力和適應能力都很好的組織。

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

Michael Feathers給出了以下觀點：

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

問題是，我們怎樣才能找到有（合適）技能的開發者？IT界從未很好地定義個體生產率，從這點來看，那麼，要找到合適技能的開發者就是個很難解決的問題。程式碼行數（Lines of code） - 在現在仍然是一個主流的度量方法 - 深陷“一行程式碼一個責任”泥潭，這並不是一個好的方法。而度量工作小時數則是鼓勵（個人）英雄式舉動 - 經驗表明，“英雄們”通常就是導致專案延期的人，依賴“英雄”往往是一開始就採取的不該採取的冒險行動，長時間工作導致人變得魯鈍，並導致低質量軟體出現。目前還沒有被普遍接受的針對IT專業人才的專業要求系列標準和僱用正規化，招聘好的人才，是一門（招聘）藝術，而非（招聘）工程。

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

但是典型的軟體專案往往是沒有規律及可預測環境的。專案成功的唯一正確度量就是：最終的結果通過整個生命週期裡的實施達到了預期目標嗎？ 很難知道什麼關鍵活動導致了專案成功和失敗，很少有人能夠通過舊有或現有的專案獲得答案。幾乎不可能判定哪些決策導致了成功或失敗（在人工智慧領域，這叫作信度分配問題）。

這些因素造成了IT專業人員很難掌握引導產品和服務走向成功所需的能力。然而，開發者掌握能幫助他們更高效地達到目標的技巧，將使他們更有動力 - 通常稱之為“開發完成”，儘可能快的、不考慮是否功能被整合以及生產就緒。類似的場景也常出現在其他功能性實施領域。

實際的軟體專案是複雜的，沒有規律可循，這會導致另一個問題 - 為了證明某種技術、實踐和方法論是實際有效而收集相關資料是極度困難的，幾乎不可能在脫離收集環境的情況下歸納出這些資料。

在Laurent Bossavit的好書The Leprechauns of Software Engineering中，他抨擊了軟體開發的一些慣式，比如“成本變化”（或“缺陷成本”）“曲線”，這些慣式是許多其它的軟體開發方法論知識基礎，稱開發人員生產率的變化是一個數量級（參照確定性金字塔原理）。Laurent Bossavit說明了相關依據 - 很多人依賴從電腦科學專業學生進行的非正式試驗或是從無法被有效控制的專案中收集小量資料。這些研究組織的給出的論調基礎往往是不健全的，資料缺乏分析，而且，最過分的是調查結果普遍遠遠超出了他們的適用領域[2]。

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

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

還是有一些辦法幫助縮短週期的，比如當我們應用精益軟體開發思想 - 一個很重要的方法。縮短開發週期在大型產品開發中是很重要的：在Bret Victor的精彩視訊Inventing on Principle中提到，“如此多的創新被發現，只要你真正理解了你在做什麼，你就能發現任何事物”。

但對我而言就是這樣的：我們幾乎不可能實踐持續改進、學會怎樣使團隊或個人變得更好、掌握成功建立大型產品與服務所需的技能。除非我們聚焦於盡可能使反饋間隔時間縮短，以便實際洞察其間關聯，以及辨別原因和影響。

事實上，從想法到反饋的週期儘可能短的好處是如此明顯和重要，應該把其作為商業模式中要遵循的一個重要原則。如果你糾結於要把你的產品建立成一個使用者安裝式的軟體還是SaaS模式（software-as-a-service，軟體運營服務模式，軟體即服務），這時的想法會自然而然地推動你強烈考慮SaaS模式（有感而發）。如果你要重建你的系統（包含硬體），應該考慮怎樣儘快實現原型（how you can get prototypes out as quickly as possible），以及模組化硬體和軟體，以便你可以快速和獨立地整合。3D printing（三維列印成型技術）技術看起來在這方面有著巨大的用武之地，因為它可以滿足軟體開發應用實踐朝硬體系統（原型呈現）的演進。如果你想如願以償地縮短週期，或多或少按多功能型團隊（cross-functional teams）方式運作是需要的。

軟體方法論，即使僱用一群牛人並讓他們自我組織，也是糟糕的，因為他們時常搞得“cargo-cult”（貨物崇拜，敏捷開發裡的知名小故事，形而上）：我們在做stand-ups（每日站立會議），我們有優先順序的backlog（優先待辦事務），我們甚至看在老天的份上實踐了continuous integration（持續整合）。我們的到頭來的結果為什麼還這麼差呢？因為你忘了最重要的事情：建立一個學習能力和適應能力都很好的組織。

---

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

2. 我並非建議放棄在軟體開發中的可行性試驗，在這裡的上下文中，我這麼闡述是對的。恰恰相反的是，我說的是我們並沒有努力去做好，做得還遠遠不夠。

---

原文：Why Software Development Methodologies Suck

原文作者：[英] Jez Humble，第21屆Jolt大獎獲獎作品《持續交付》作者，該書被譽為2010年最重要的技術書。