喜歡敏捷的很多想法，喜歡它務實的態度。我說“敏捷不能當飯喫”，當然不是說敏捷無用，相反，我倒是挺推崇敏捷的。之前有兩篇文字都涉及到一些對敏捷的看法。一篇是 與神對話 ，另一篇是 對敏捷的一些想法 。只是看到很多人好像敏捷是他爺爺寫的一樣，龜孫子似地迷信和追捧敏捷，把工作一條一條跟書上描述的對照，一旦工作中實際操作跟書上有不一致，口誅筆伐，吐沫拳頭無影腿就一齊上來了，那就太過了。敏捷跟太極拳一樣，是一種思想精髓，它的一招一式體現在實際工作中靈活運用敏捷原則，敏捷並無特定套路。Scrum等流程是敏捷的一種成功案例，這個案例在特定環境下工作得非常好，但那只是特定環境而已。敏捷大師們自己也總提醒，很多項目採用敏捷開發，仍然一塌糊塗，是因爲應用敏捷並不簡單。
Kent Beck是敏捷的發起者之一，很多敏捷的發起者後來都寫了關於敏捷的書，但Kent Beck的書是最有影響力的，它的Extreme programming explained – embrace change可以在這篇博客 中找到。這本書主要闡述敏捷的一系列理念，對實踐描述的並不具體。scrum之類講敏捷流程的書，對實踐操作的環節就會講的很具體。先了解並接受敏捷的理念，再去看敏捷流程的話，比較容易理解流程背後的用意是什麼 ，只有深刻理解了敏捷精神，才能比較好的實踐敏捷。而現實情況很多時候不是這樣，直接學習流程總是比較省事兒，於是scrum就被當成聖經直接拿來就用了，人家mc hotdog早就說過，“照單全收的盲從，就像在喫屎”。我相信通常情況下，scrum的實踐在一個項目組，只有一小部分能用得上，當然，這已經是件很偉大的事情了。在一些常見的工作環境中，有些scrum的想法並不適用。
一個方面是，scrum強調“全功能團隊”，每個人瞭解產品的每一個feature；團隊人數在敏捷中是有限制的。但如果一個負責某個產品的團隊就是有12，3個人，那麼怎麼辦？ 再拆成兩個敏捷團隊以適應敏捷對人數的要求？垂直劃分feature提供了細化團隊的機會，但產品不總能清晰地一刀切成兩半，尤其還要考慮各個程序員有不同的專長，甚至根本用的不是同一種編程語言，如果團隊只有一個c程序員，一個js程序員，一個pl/sql程序員，其他做java，那麼切分項目組的方式是跟c有關的一組，跟js有關的另一組？底層架構和公共模塊都不容易豎切。如果產品比較大並且不易細分，大家都瞭解每個feature是很難做到的。如果產品使用的技術比較繁雜，pl/sql, js, java, c樣樣都用，全功能團隊怎麼實現？js的程序員跟c程序員也講不到一塊兒去啊。我可以理解scrum的想法，也認同它的道理，但是在實際工作中，如果確實人數對不上敏捷的要求，或者程序員的技術特長分散在不同層面，這很難照搬scrum的實踐。人多開會費時間，效果又不好，雞同鴨講，各說各的。寫c的人才不關心js有什麼技術瓶頸呢。
還有，scrum想了個招兒，用打撲克的方式溝通需求和幫助定schedule。這是建立在全功能團隊的基礎上的，上面已經論述過了，如果產品比較大，程序員沒法兼顧所有story，那成本太大了，打撲克也只能流於形式，尤其術業有專攻，唯一的c程序員的工作只有他自己估計纔有意義。更實際的問題是，當你知道story具體需求的時候，還不足以估計出時間，程序員必須知道“怎麼做”才能估出來比較靠譜的時間。很多時候需要做一些research的工作以及一點兒prototype纔好估時間 ，在這樣的情況下，你非逼我出張牌，我只能出“問號”。 有時候，雖然我不需要做prototype, 但我確實也不能在5分鐘之內理清思路, 知道用什麼approach更合理，那麼我怎麼辦，告訴大家容我想想，等我一會兒？技術問題本來也不應該規定在5分鐘之內出個計劃，非逼我出計劃倒也沒問題，但是隨後我就得重做計劃。還有一個問題，大家一起打牌，A知道這工作十有八九落在B頭上，A可能出於好心多估時間，B可能爲了面子少估時間，這些人爲因素如何排除掉？
敏捷強調單元測試，這肯定是沒錯的。問題是，各個團隊之間容易開始攀比覆蓋率，其實程序員心裏都明白，覆蓋率的欺騙性很強，單元測試的有效性更重要 。如果單元測試又沒貢獻於驅動開發，也沒貢獻於質量保證（簡單的api，諸如getter/setter之類的api就是這樣，不用測試驅動直接就知道怎麼寫了，寫了手動測試一遍就知道寫的沒錯，code以後也不可能改），那麼就沒必要寫這種單元測試，寫這種單元測試的唯一好處是，成本低，比較容易貢獻覆蓋率。麻煩在於，太多弱智這麼說，咱們敏捷了，單元測試覆蓋率應該向某某弱智team看齊，於是人在江湖，身不由己，開始對付覆蓋率。好吧，scrum其實也沒說具體百分比，這不是scrum的錯。
我絕對不想抨擊敏捷或者scrum，我覺得這都是很出色的想法。只是聽了太多“這不是敏捷”這種話，是不是敏捷根本不重要，能優化流程，讓工作更有效才重要 。我喜歡敏捷的地方在於，敏捷強調以人爲本，尊重程序員的各種訴求。正視design不能一蹴而就的現實。承認長期計劃不靠譜。強調優先級，決定優先級的時候從性價比的角度考慮。scrum的很多實踐也很實用，比如backlog應該包含的內容等等不一一羅列。敏捷不是一門玄奧難懂的技術，不需要花錢找培訓機構受教育。敏捷的出發點就是務實，用務實的態度擁抱敏捷就足夠好。套用二八原則，scrum的實踐在實際中也許只需要吸收20%，卻能取得80%的效果，剩下那20%要靠基於敏捷精神的創造力。