解讀敏捷2 - 敏捷實施的六個陷阱

隨著敏捷日益成為主流，各種各樣的敏捷會議召開，一本又一本的敏捷圖書出版，一個又一個的公司前赴後繼的邁向敏捷，好一番火熱景象。這讓我回憶起了當年看報時的一個感受，當時每張報紙的顯眼處都能看到牛皮癬和肝病的廣告，咋一看感覺會治病的人很多，仔細思考下才發覺是根本原因是能治好病的人很少，否則市場上不會那麼熱鬧。敏捷的現狀是不是也是如此呢？

“與其做敏捷，不如變敏捷！Be agile rather than do agile.”但對於大多數公司來講，如果沒做過敏捷，怎麼知道如何變敏捷。而且做敏捷可以檢查和測量，變敏捷則不能，這違背了“不能被測量則不能被管理”的管理定律。但大多數敏捷實施會失敗！那些被敏捷後的美好前景吸引、前赴後繼奔向敏捷的公司基本上是在自尋煩惱，“苦逼敏捷”開始盛行。

竊以為要想成功實施敏捷必須先解決下面六個問題：

1. 沒有目標，為敏捷而敏捷

為敏捷而敏捷，並不是為了解決真正的問題，把手段當做目標。不少公司簡單的被市場宣傳打動，認為敏捷就代表著好，不敏捷就不好。這些公司往往會被輕易的忽悠，高估敏捷實施的效果，希望通過簡單的敏捷實施就能解決面臨的很多問題。因為沒有目標，他們在實施的時候只能力求規範。這是一種符合國情的管理方式，俗稱運動式管理。運動式管理的目標僅僅是為了運動，運動之後才知道自己在裸泳。

貴公司當前的主要問題是什麼？實施敏捷要解決哪些問題？哪些問題是不能通過實施敏捷解決的？

2. 沒搞懂敏捷

不想變敏捷，只想做敏捷。沒有真正投入成本研究敏捷的公司並不知道敏捷因何生效。當然，他們也有研究，例如派人參加兩天的CSM培訓，拿到證書；或者買進兩本敏捷的書籍，看看紅綠模式或者知道每天早上要回答三個問題。這種膚淺的研究把敏捷看做過程，而且是非常簡單的過程。他們往往會低估敏捷實施的難度，高估敏捷實施的效果，結果在真正實施的時候碰的頭破血流。在這種情況下實施敏捷就是一個悲劇。“我遵守所有的規則，人的和神的。而你不遵守規則，但他們愛你勝過愛我。“——《燃情歲月》

敏捷是什麼？敏捷到底是怎樣發揮作用的？需要多長時間？敏捷對什麼沒用？

They told me that the world would be changed if I could answer three questions every morning. Now I've answered them for a month, why hasn't the world been changed?

3. 錯誤的方法：套裝癖

套裝癖是指人們更喜歡看起來完整的東西來滿足他們的心理願望，以逃避獨立思考和解決問題的真正困難。套裝癖現象不僅僅發生在敏捷軟體開發，它體現了人們對解決方案而不是解決問題的熱愛。瀑布模型並不是瀑布模型提出者的本意，但它被曲解成了瀑布模型這樣一個軟體開發解決方案；之所以提出CMM是為了衡量過程中的質量，但它變成了解決軟體開發企業管理問題的解決方案；Scrum不是解決方案，但人們或者是抱怨Scrum解決方案沒有提供足夠的實踐，或者是自己為它加上使用者故事、計劃撲克和其他實踐，一定要把它變成解決方案。人們一邊在市場上追逐套裝，一邊在抱怨套裝原來是中看不中用啊。的確，實施一個套裝比實施一個實踐難多了，但套裝癖們還是樂此不疲。

實施敏捷就是實施Scrum嗎？真的需要所有的實踐嗎？有沒有哪一個實踐做好了，真的有效了？

4. 基礎不行

敏捷軟體開發還是軟體開發，不會因為實施了敏捷，就可以招聘技能更低的人完成工作了。以Scrum為例，Scrum是暴露問題而不是解決問題，解決問題還是要靠人。人與人之間的衝突需要衝突解決能力，團隊建設需要領導能力，對業務的深入理解需要對業務的掌握和分析能力，開發人員的設計編碼能力更別說。Scrum的創始人說過，白痴也可以用Scrum，然後他又補充了一句，當然，他們只能產出垃圾而已。你們公司需要垃圾嗎？

貴公司現在的軟體開發能力如何？經過6-12月後，程式碼的質量能保障嗎？開發人員理解業務嗎？架構是不是讓人很崩潰？

5. 環境衝突

要實施敏捷，卻沒有實施敏捷所需的環境、人和文化。大多數的公司無法包容為了解決問題突破公司規定，敢指出領導問題的人，在這種公司大規模實施敏捷，純屬找抽。這也是很多人談到敏捷都會說，敏捷很好，但是在我們公司不適合的原因所在。而且實施敏捷帶來的透明性會讓壞訊息在開始的時候滿天飛，能否容忍壞訊息？能否正確引導團隊的認識？對管理層是極大的考驗，其實壞訊息一直存在，只是以前被捂住了而已。“貪官奸，清官要更奸。”——來自周星馳《九品芝麻官》

貴公司有沒有更奸的清官？能不能容忍壞訊息？能容忍多久？鼓勵嘗試嗎？還是對任何“錯誤”都要懲罰？

6. 高估研發管理能力

軟體研發管理能力是被軟體開發公司忽視的癌症。有一個非常簡單的問題來考察軟體研發管理能力，“請問貴公司Code review做的怎麼樣？”看看管理層如何回答這個問題，到幾個專案團隊去看看實際做的怎麼樣，問問開發人員對Code review的感受。Code review是搞軟體的人都懂的實踐，人人都知道應該做，但是大多數公司在這一點上都不合格。

貴公司有沒有一個軟體開發實踐是真正推下去了，沒有應付了事的？哪一個敏捷實踐是貴公司準備實施的？怎麼真正推下去？

解讀敏捷

這就是解讀敏捷這個系列的目的了，希望通過這個系列達到如下目的：1）展示我對敏捷的理解，以幫助更多的人真正瞭解敏捷；2）對實施敏捷提出想法和建議；3）提供一些例項供參考。

雖然看起來很容易，但是敏捷真的很難，需要多年的學習和實踐。只想按葫蘆畫瓢，結果就會是按下葫蘆浮起瓢。我的格言是：簡簡單單就能做好的事不值得付出努力。就是因為難，所以做好了才能成為競爭力，才能與眾不同，是這個道理吧。

後續的內容還沒有全部構思好，但考慮中的內容包括：

1）實踐與理論解析

敏捷有多難？從細節看全域性，如何將細節做到極致，從細節理解敏捷。請看後續：解讀敏捷實踐之結對Review，解讀敏捷實踐之每日立會。怎麼理解套裝的Scrum、XP等等。

敏捷背後的理論解析，排隊論，博弈等等。

2）實施方法與樣例

你想解決什麼問題？採用什麼方法？問題域分析與道法術器。

3）雜談

一些相關的事例與感悟。