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

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

?

無住

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

不住于法

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

如果把“敏捷”理解成一個名詞，就會出現一個問題：什么是敏捷？又會擴展成Scrum是敏捷，還是XP是敏捷？RUP是不是敏捷？等等問題。

如果把“敏捷”理解成一個形容詞，也就是“敏捷的開發方法”，大致能找到敏捷新的定義：敏捷是一種輕量級的開發方法。

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

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

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

那為什么現在的敏捷方法看起來更像是“輕量級的開發方法”呢？這是因為重量級的敏捷開發方法早就有了（最早的軟件工程始于軍工、航空航天、銀行業），其他行業比如敏捷宣言發表時乃至今日仍盛行的互聯網行業卻一直沒有方法。當他們“敏捷地”尋找的時候，找到了“敏捷的”方法。

但如果以為已經找到了就停了下來，就不敏捷了。

不住于空

“既然敏捷開發也不是最好的方法，那我們何苦要用敏捷方法呢？”“去年你們推CMMI，今年又推敏捷，明年天知道你們又會推什么方法（所以我打算不配合）”。

因為世界上沒有絕對最好的編碼規范，所以你們別說我的編碼爛；因為世界上沒有最好的管理方法，所以你們也別說我的方法亂；因為世界上沒有絕對的好人，所以且容我再當一次壞人……這是很多人處世的哲學，開發團隊也不乏這樣的“老油條”“刺頭”。

如果把“好”當作一個點，的確沒有一種方法只好不壞。但如果把好當作一個方向，那么眼前，這里，這個項目，這個團隊，的確有一些方法比另外一些方法好。雖然不是普適的最佳方法，但仍然值得追求。

不住于空，就是盡管沒有最好的方法，但是不能因此放棄尋找更好的方法。

以往研發管理的教訓

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

“為什么牛奶要檢測氮含量？”“因為氮含量高，就意味著有更多的蛋白質，因而對人體更加有益。”如果把后兩句給忘了，就產生了往牛奶里邊添加三聚氰胺的做法。

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

很多軟件企業中的文檔、評審、計劃、會議并沒有起到應有的作用，但卻被盲目地堅持著。人們對這些方法的關注甚至超過了最終項目的成敗和企業的盈利能力（神奇的是，美國國防部通過對這些方法的關注而大大提高了項目的成功率，但要認為我們只需要學習他們就能成功，則住在法上了）。

重讀敏捷宣言

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

不過，為了通俗易懂，敏捷宣言把“敏捷地找到”的方法貼出來了，所以變成了“敏捷的方法”，如果住在上面，就會出問題。

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

轉載于:https://www.cnblogs.com/spring3/archive/2012/01/10/2401350.html

總結

以上是生活随笔為你收集整理的敏捷开发一千零一问系列之二：序言及解决问题的心法（无住）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。