閱讀學習-為什麼軟體開發方法論讓你覺得糟糕？

英文原文：Why Software Development Methodologies Suck

譯文出處：為什麼軟體開發方法論讓你覺得糟糕？

圍繞軟體開發實踐和方法論，總有很多教條式的口水仗。階段式（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說明了相關依據 - 很多人依賴從計算機科學專業學生進行的非正式試驗或是從無法被有效控制的項目中收集小量資料。這些研究組織的給出的論調基礎往往是不健全的，資料缺乏分析，而且，最過分的是調查結果普遍遠遠超出了他們的适用領域。

是以，不太可能輕易下論斷靈活開發實踐就比瀑布模式之流合适，反之亦然。“方法大師”的見解其實也沒太大指導意義，就像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（持續內建）。我們的到頭來的結果為什麼還這麼差呢？因為你忘了最重要的事情：建立一個學習能力和适應能力都很好的組織。