敏捷開發一千零一問系列之二：序言及解決問題的心法（無住）

這是敏捷開發一千零一問系列的第二篇。（之一，之二，之三，問題總目錄）

也是般若敏捷系列第十一篇。（之一，之二，之三，之四，之五，之六，之七，之八，之九，之十，之十一，之十二）

 

無住

在般若敏捷系列中已經提過，包括不住於法，不住於空。

不住於法

就是不停留在一種固定的方法上。

若是把「敏捷」理解成一個名詞，就會出現一個問題：什麼是敏捷？又會擴展成Scrum是敏捷，仍是XP是敏捷？RUP是否是敏捷？等等問題。

若是把「敏捷」理解成一個形容詞，也就是「敏捷的開發方法」，大體能找到敏捷新的定義：敏捷是一種輕量級的開發方法。

若是把「敏捷」理解成一個副詞，也就是「敏捷地開發」，就會找到一個更新的定義：敏捷就是不拘泥與形式不斷優化地改進開發方法。

用最後一個理解看待開發，敏捷方法的定義就有很大不一樣。

好比CMMI，若是CMMI1.3修訂以後更加適合美國國防部尋找適合的供應商開發軍工項目（CMMI是美國國防部的供應商評價標準，而不是一個學術機構總結的通用最佳實踐），那麼CMMI就很敏捷；而一家企業已經實施Scrum好久了，但其質量、進度與日劇減，但你們堅持使用原汁原味的Scrum，那麼反而很不敏捷。

那爲何如今的敏捷方法看起來更像是「輕量級的開發方法」呢？這是由於重量級的敏捷開發方法早就有了（最先的軟件工程始於軍工、航空航天、銀行業），其餘行業好比敏捷宣言發表時乃至今日仍盛行的互聯網行業卻一直沒有方法。當他們「敏捷地」尋找的時候，找到了「敏捷的」方法。

但若是覺得已經找到了就停了下來，就不敏捷了。

不住於空

「既然敏捷開發也不是最好的方法，那咱們何苦要用敏捷方法呢？」「去年大家推CMMI，今年又推敏捷，明年天知道大家又會推什麼方法（因此我打算不配合）」。

由於世界上沒有絕對最好的編碼規範，因此大家別說個人編碼爛；由於世界上沒有最好的管理方法，因此大家也別說個人方法亂；由於世界上沒有絕對的好人，因此且容我再當一次壞人……這是不少人處世的哲學，開發團隊也不乏這樣的「老油條」「刺頭」。

若是把「好」看成一個點，的確沒有一種方法只好不壞。但若是把好看成一個方向，那麼眼前，這裏，這個項目，這個團隊，的確有一些方法比另一些方法好。雖然不是普適的最佳方法，但仍然值得追求。

不住於空，就是儘管沒有最好的方法，可是不能所以放棄尋找更好的方法。

以往研發管理的教訓

這裏不得不提一下以往軟件研發管理的教訓，尤爲是推廣CMMI時的教訓。

「爲何牛奶要檢測氮含量？」「由於氮含量高，就意味着有更多的蛋白質，於是對人體更加有益。」若是把後兩句給忘了，就產生了往牛奶裏邊添加三聚氰胺的作法。

昨天一個學員就提到說他們企業堅持要他們編寫一些文檔，而他們明明知道這些文檔被扔在那裏歷來沒有人看過，不寫又不行，問應該怎麼辦（這個將是1001問系列中的一個問題）。

不少軟件企業中的文檔、評審、計劃、會議並無起到應有的做用，但卻被盲目地堅持着。人們對這些方法的關注甚至超過了最終項目的成敗和企業的盈利能力（神奇的是，美國國防部經過對這些方法的關注而大大提升了項目的成功率，但要認爲咱們只須要學習他們就能成功，則住在法上了）。

重讀敏捷宣言

敏捷宣言中關於可運行軟件賽過繁雜文檔 及 響應變化賽過遵循計劃的描述，說的就是這件事情。

不過，爲了通俗易懂，敏捷宣言把「敏捷地找到」的方法貼出來了，因此變成了「敏捷的方法」，若是住在上面，就會出問題。

這就像「打土豪分田地」是一個通俗易懂的口號，但若是認爲這就是共產主義，等土豪沒了，田地分了，也就迷茫乃至要走上歧路了。