王屋村移山公司的程序員果凍最近請假參加了一系列敏捷的培訓, 有好事者傳言他和 “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%, 不要讓微小的錯誤把系統搞崩潰! |
原文轉自:http://www.anti-gravitydesign.com