敏捷開發般若敏捷系列之九：敏捷開發與本能反應

這是敏捷開發般若敏捷系列的第九篇。（之一，之二，之三，之四，之五，之六，之七，之八，之九）

經常聽到有人提到敏捷開發與“本能反應”非常近似，比如凡事都需“看著辦”，比如“不拘泥於形式”，比如“直擊代碼，不寫無用的文檔”等等。

那麼敏捷開發與本能反應之間的差別是什麼呢？

簡單地說，敏捷開發就是無我狀態的本能反應。

無我，無人（無我，無人，無眾生）

按理說，本能反應是最接近最佳路徑的，一線人員，工作現場，當下的問題，一定能在事先預定的路徑之外找到更好的方法，除非有個“我”字。

1. 比如測試人員最近的工作繁忙，需要多調度幾個測試人員過來，才能保證測試不延期。如果按照本能反應，開發人員中的一些人極有可能過來幫忙測試，或協助編寫一些節省人工的自動化的測試代碼（後者是01年我們團隊的做法，最終結果是25個開發人員只需要1個測試人員就能完成測試）；但如果“我們是開發人員，他們是測試人員”，尤其是“每發現一個缺陷，他們得10元，我們扣10元”，這件事情多半就辦不成。

2. 比如有一個人在每日例會上說遇到了困難，而另有人對此有非常容易解決的方法。如果按照本能反應，可能一句話就能協助節省幾個小時；但如果“我有我的工作，他有他的工作”，尤其是“如果協助了他，我的工作可能完不成”，這件事情也多半辦不成。

3. 比如某個文檔在這個產品中的確不需要寫，但是“如果他們不寫，做CMMI評估的時候我們EPG組就會比較難辦”，那麼這個文檔到底要還是不要寫就真成了一個問題。

這些我與別人的分隔，使得很難在事情上走最佳路徑，而多半會在人和分工上走最佳路徑，尤其是按“我”的利益來走最佳路徑。在這種情況下，本能反應就是錯誤的。

無現在的我，無未來的我（無壽者）

一個人的時候，也會出問題。

1. 一個設計非常複雜，按本能反應，怎麼也應該記錄下來點東西。但是如果“我現在心裡清楚設計不用寫，未來也不一定是誰在維護這些代碼”，那麼就很容易不寫這個文檔，卻在未來產生很大的麻煩。

2. 一個代碼這樣寫未來可能產生缺陷，但是這個版本這樣寫最快。如果“我要按最快的方法寫，管他未來是誰”，那麼多半代碼就會很爛。

如果一個人說：我不寫文檔的原因是“我把設計表達在代碼裡”，如果代碼很漂亮則的確如此，如果代碼又很爛，就可見前者只是一個借口。

說實話多數吆喝“代碼即設計”的程式員代碼都很爛。

創造無我的環境

在多數有我的環境中，對某件事情而言，每個人提出的解決方案都不相同，而且沒有一個是與這個事情的最佳解決方案重合的，因為每個“我”都按自己的利益行事。

最終的結果，是為了讓這些我能湊在一起工作，創造出無數的部門規範、工作流程、中間文檔、計劃、中間文檔的評審標準等等，用來約束每個我的工作。本能反應也就被壓抑了。

“如何創造一個無我的環境？”這個問題在每個具體環境中，都有具體的最佳答案，受到具體人、事、物的限制，很難一概而論。

但如果如果沒有任何前提條件地回答這個問題，倒也有一個“般若”一點的答案，就是“共振”。

所謂共振，就是在能控制的範圍內先取得一些成效，以此換取他人及未來的共鳴，從而推廣下去的方法。世界上的各種偉人，無一不是以這種方法工作的，影響力能遠達萬裡、千年。

作為個人，首先可以破除現在的我；作為小團隊（比如3個人），可以小範圍破除我人之分，共進退；作為開發組，可以局部破除分割和個體考核；作為研發部，可以在部門內部推行新的績效考核體系，等等。

儘管這些事情看起來都有其困難之處，但與那些“萬裡、千年”的事情相比，卻微不足道，幾乎可以說基本上只要去做，沒有做不成的。

不過共振的原理，就是不謀求一說就通，一做就成，而是找到事物推廣的固有頻率，走得太快了，難免做不成先驅，反而成為先烈。

本人曾經在10年裡頻繁地更換工作，目的是找到一個可以“大展宏圖”的地方，但都失敗了。直到在一家企業固守了3年，結局令我大吃一驚，原來每個企業都是很容易被推動的，唯一要判斷的其實只有一個問題：“這個企業值得推動嗎？”

共振的內容，在本系列的以後會有2篇以上的文章還會提及。

點擊下載免費的敏捷開發教材：《火星人敏捷開發手冊》