王屋村移山公司的程序員果凍最近請假參加了一系列敏捷的培訓, 有好事者傳言他和 “a-girl”勾搭上了, 其他年輕同事有點坐不住了, 也表示要參加此類活動。 幾天後, 果凍回到公司, 給所有人發了一枚寫有 “Agile” 的胸章。 他糾正大家的發音, 這個詞不是發 “a-girl”， 而是“愛腳兒”！ 果凍希望大家一起在公司裏掀起一股愛腳兒的熱潮, 把公司的軟件工程質量從 CMM5 再提高一個檔次。
小飛給他講了一個笑話:
軟件團隊開會, 領導說: 我們要採用敏捷的開發流程. 很簡單, 就是木有計劃, 木有文檔, 馬上寫代碼, 隨時發牢騷。
工程師問: 培訓有木有?
領導說: 有, 剛纔就是培訓. 散會! 現在可以寫代碼和發牢騷了.
以上圖片從 dilbert.com 提供的鏈接得來
果凍說, “我不覺得可笑, 我認爲敏捷是瀑布模型發明以來的另一個巨大的進步。”
大家笑完之後, 問那 愛腳兒模式到底是什麼玩意兒? 能管用麼? 能掙更多的錢麼?
果凍說, 大家稍等幾天, 多種敏捷大會的 PPT 就上線了. 到時大家就敏了!
晚上大家在頂球就把喝酒的時候, 碰到阿超, 於是就有這樣的問答:
問: 愛腳兒 - 敏捷到底是什麼東東? 好像有很多名詞, 縮寫和傳說…
答: 敏捷 (Agile) 是一股思潮, 它包括了好幾種軟件開發的方法論 (methodology); 這些方法論又是建立在許多業界證明行之有效的最佳實踐方法 (best practices) 上面的。 如圖所示:
問: 敏捷的思想是從天上掉下來的麼?
答: 不是, 是人們自己總結出來的。
問: 敏捷的方法論有哪些?
答: 比較有名的是:
-
- 愛撫弟弟 (FDD)
- 史克朗姆 (SCRUM)
- 極限編程 (XP)
問: 那比較有名的最佳實踐是什麼?
答: 這就太多了, 你把任意三個字母組合一下, 說不定就是一個最佳實踐, 例如 TDD (踢弟弟) 就是一個最佳實踐。很多程序員老大哥都很喜歡踢弟弟。
問: 爲什麼人們以前沒有總結出來敏捷, 而是最近這幾年才醒悟呢?
答: 這個… 當原始人沒有東西喫的時候, 爲什麼他們不知道喫方便麪? 稍稍正經一點來說 - 有幾個原因導致敏捷在互聯網時代出現:
-
- 最初的軟件 (20 世紀60-70 年代) 的顧客都是大型研究機構, 軍方, NASA 這些, 他們需要軟件系統來搞科學計算, 軍方項目, 和登月項目等, 這些系統相當龐大, 對準確度要求相當高。
- 20 世紀 80年代到90年代中, 軟件進入了桌面軟件的時代, 開發的週期明顯縮短, 各種新的方法開始進入實用階段. 但是軟件發佈的媒介還是軟盤, CD, DVD, 做好一個發佈需要較大的經濟投入, 不能頻繁更新版本。
- 互聯網時代, 大部分的服務是通過網絡服務器端實現, 在客戶端有各種方便的推送 (push) 渠道. 由於網絡的轉播速度和廣度, 知識的獲取更加容易, 很多軟件服務可以由一個小團隊來實現。 同時技術更新的速度在加快, 那種一個大型團隊用一個固定技術開發2-3 年再發布的時代已經過去了。 用戶需求的變化也在加快, 開發流程必須跟上這些快速變化的節奏。
問: 什麼樣的牛人一夜之間想出了這麼多敏捷的東東?
答: 首先, 很多方法已經在實踐中運用了很多年, 不是牛人們一夜之間想出來的; 其次, 很多方法論把原來單個的實踐方法結合起來, 運用到極致, 吸引了不少眼球。 不過, 一些牛人的確在幾個晚上搞出了一個 “敏捷宣言”:
2001年2月，17 位軟件綠林好漢聚集在美國猶他州的滑雪勝地雪鳥（Snowbird）雪場。白天除了滑雪, 沒啥鳥事; 晚上除了喝酒侃大山, 鳥沒啥事… 但是他們都感覺世變時移, 變法宜矣。 經過討論，《敏捷宣言》應運而生:
敏捷思潮的價值觀：
Individuals and interactions over processes and tools
個人和交互 重於 過程和工具
Working software over comprehensive documentation可用的軟件重於 完備的文檔
Customer collaboration over contract negotiation和客戶協作重於 合同談判
Responding to change over following a plan響應變化重於 遵循計劃
後者並非沒有價值，只是我們更加關注前者。
敏捷的原則中文版在這裏。
問: 爲啥很多研究都證明敏捷很有效果?
答: 大多數被測試, 被研究的新東西都很有效果, 這是Hawthorne 效應。例如你可以測試 “給每一個程序員發毛絨玩具 - 然後測試勞動生產率“， 你會發現勞動生產率提高了!
問: 敏捷是萬能的麼? 我上學的時候老師教我們 “形式化的軟件開發方法 (Formal Method)”, “里程碑式的開發 (Plan-driven development)”, 它們都被淘汰了?
答: 不是, 和任何武功和戰術一樣, 敏捷有它最適用的範圍, 我藉着酒勁, 畫一個表:
| 客觀因素/最適用方式 | 敏捷 (Agile) | 計劃驅動 (Plan-driven) | 形式化的開發方法 (Formal Method) |
| 產品可靠性要求 | 不高, 容忍經常出錯 | 必須有較高可靠性 | 有極高的可靠性和質量要求 |
| 需求變化 | 經常變化 | 不經常變化 | 固定的需求，需求可以建模 |
| 團隊人員數量 | 不多 | 較多 | 不多 |
| 人員經驗 | 有資深程序員帶隊 | 以中層技術人員爲主 | 資深專家 |
| 公司文化 | 鼓勵變化, 行業充滿變數 | 崇尚秩序, 按時交付 | 精益求精 |
| 實際的例子 | 寫一個微博網站; | 開發下一版本的辦公軟件; 給商業用戶開發軟件 | 開發底層正則表達式解析模塊; 科學計算; 複雜系統的核心組件 |
| 用錯方式的後果 | 用敏捷的方法開發登月火箭控制程序, 前N 批宇航員都掛了。 | 用敏捷方法, 商業用戶未必受得了兩週一次更新的頻率。 | 敏捷方法的大部分招數都和這類用戶無關, 用戶關心的是: 把可靠性提高到 99.99%, 不要讓微小的錯誤把系統搞崩潰! |
在實際情況下, 有許多號稱敏捷的項目好像也敏捷不到那裏去 （這兩天在博客園看到的例子1,例子2，例子3）。 要記住, 有許多最佳實踐在各個開發方式下都在使用， 所以各個開發方式並不是井水不犯河水, 老死不相往來的那種關係.
問: 敏捷難道不是通喫一切的? 你列這個表, 好像沒有給敏捷應得的名分呀?
答: 我酒後的見解就是這樣。 比如有穿全套制服, 開警車出行的警察; 也有很多便衣警察; 他們各有最佳的適用範圍，對吧？ 如果你覺得便衣的名分沒得到, 給他們統一打扮起來, 就成了下面的情況:
名分是有了, 但是他們的最佳適用範圍呢?
問: 聽說有大寫的愛腳兒, 和小寫的腳兒之分?
答: 有的, 有些激動的人士把敏捷當作一種宗教, 所以大寫 Agile; 另一些人只是把敏捷當作一個形容詞, 所以小寫 agile.
"we follow an agile process" 一般指團隊的流程比較靈活。 "we follow theAgile process" 指按照官方敏捷流程的教義開展工作。 當敏捷變成了宗教, 你說它還會敏捷麼? 當實事求是的做法和教條發生了衝突， 你怎麼辦呢?
舉個例子, 果凍晚飯吃了 “小蔥拌豆腐”, 這是歷史悠久的一道素菜。
果凍的朋友不會說-
哇, 這不是最近某大師推薦的麼？ 你成了他的粉絲？你要喫素?! 你要做和尚麼? 有什麼想不開的？
我們不要把一些 “有益健康的飲食”和 “投靠某大師/宗教的教義”混淆起來。 當然, 有些大師希望把天下每一道素菜都當作自己首創的, 這另當別論。 如果有人說 - 有些人不適合喫小蔥拌豆腐 (例如痛風病人)。 你可以想象有狂熱者反駁 - 你難道說豆腐不好? 你有沒有搞錯？ 你們看到現在喫豆腐多麼流行！這麼多喫豆腐的人都錯了麼?!
半年前果凍還經常喫生的茄子呢, 那滋味怎麼樣 。。。 哦, 扯遠了, 我們是在聊什麼？ 哦, 愛嬌娥, 愛腳兒…
回到敏捷 (agile) ， 它是一個形容詞， 不是一個東西， 它修飾的是做事情的方式，不是這事情本身。 所以“敏捷”需要一個動作的執行者和一個動作。 光說“敏捷好”是沒有用的。
問: 我怕宗教，那麼如何分清原教旨主義的愛腳兒, 和把愛腳兒當作實踐工具的人士?
答: 很簡單, 你有禮貌地問對方: 敏捷方法有不適用的場合麼? 然後冷靜觀察對方的回答和表情, 就可以了. 必要的時候要準備好逃跑的路線。
問: 現在俺們村裏有很多發傳單, 推廣敏捷培訓的人士, 他們是哪一種?
答: 他們是賣東西的，掙錢不容易, 我們不必擋別人的財路。無語微笑, 避免過多目光接觸, 走自己的路即可。
問: 要敏捷的話, 是不是手頭用慣了的工具都不能用了?
答: 那倒未必, 有很多工具支持敏捷的方法論, 例如 微軟的 Visual Studio Team System 就支持 Agile 的方法論 （叫 msf-agile）。 它也有自己的一套方法論 - 以前我們不是有一個白話MSF 的討論麼?
有理論而沒有工具, 那理論也是白扯
有工具而不懂理論, 那工具不能發揮最大作用
問: 敏捷的思想是不是能指導軟件開發以外的工作?
答: 當然可以, 例如把下面文章的某某思想換成敏捷思想, 也是能講得通, 你看那pair-programming 的兩個妙齡少女身手多麼敏捷!
問: 我想敏捷，但是項目的期限不能往後拖, 敏捷能幫我早日完成任務麼?
答: 敏捷不是萬能的。 敏捷的方法能幫助你更早地知道你是否能如期完成任務, 僅此而已。敏捷的方法（迭代的方式）能幫你儘快讓用戶看到項目的部分 價值。 當你儘早交付 部分 價值的時候， 也許用戶對你目前交付的東西已經很滿意了，這樣你就不用再花時間來實現其它事情。 另一種可能是， 用戶看到了部分系統，他們有新的需求，這樣你就可以實現新的需求，而不用再浪費時間實現過時的需求了.
**************