敏捷開發般若敏捷系列之四：如何推廣敏捷（上）（無我，無人，無眾生）

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

敏捷開發中有幾個地方相當創新，或者說儘管之前的方法中可能也有涉及，但卻從來沒有像敏捷開發這樣提升為“根本大法”來對待。

一個是“擁抱客戶價值，擁抱變化”，一個是TDD/結對程式設計/自動化測試為代表的開發與測試的融合，一個是“團隊協作/結對程式設計/共同估算/代碼共同所有制等自組織團隊實踐”，還有一個則是認為協作重於流程，溝通勝於文檔。

傳統開發的困局

在敏捷開發之前，儘管沒有成文的說法，但客戶與開發人員整體是個博弈的關係，雙方要小心謹慎相處。比如需求要簽字確認才能開發，計劃要提前敲定並監督完成；而變更要走嚴格的變更流程……

開發人員與測試人員也基本上是兩類人，有一個經典的考核方法足以讓這兩類人水火不容：“測試人員每發現一個Bug，開發人員扣N元，測試人員得N元”，這個對立的，零和的考核方法讓這兩個團隊不可能坐在一起，討論如何共同提高績效。

傳統的考核往往是考核個人，因而常常出現忙的忙死閑的閑死，鍵盤之聲相聞，老死不相往來，一人離職，全隊泡湯的情景；而敏捷開發倡導整個團隊一起工作，以集體智慧共同解決問題，並以此獲得生產力的提升。

敏捷破局

敏捷開發的這種破局，本人並不認為是對整個管理作出深刻反思的結果，相反是忽略一切沒用的制度，全心全意“逐利”的自然結果。

需求開發和變更過程，無非是想通過向客戶交付價值獲得回報；開發或測試無非是想提高產品品質；考核無非是想提高生產率。

繁雜的文檔讓客戶遲遲不敢簽字，或把寶貴的時間精力花費在評估和抵制客戶的變更上，並不能獲得回報；開發人員與測試人員的博弈，無非是最終讓開發人員開發出測試人員測試不出來的Bug留給客戶發現；而針對個人的考核，反而導致實際團隊總生產率的下降。

敏捷Team Dev發現，若能突破我們（就是開發人員，敏捷開發的發明者），測試人員，開發/測試團隊，乃至突破企業/客戶的界限，將大家的利益統一考慮，效果不可思量。

這也就能看出為何敏捷開發認為協作勝於流程，溝通勝於文檔。

流程與文檔的很大目的，就是在於跨人/跨部門工作的時候，交接完整，責任明晰。

而協作與溝通則拋棄了交接、責任這些“多餘的中間產物”，令責任始終同時處於大家一起負擔的狀態。

無我，無人，無眾生

所謂無我，就是不能執著地認為自己的利益和績效是要獨立考慮的，可以獨自提升。

所謂無人，就是不能把別人的利益與自己對立起來，而是要統一考慮統一提高。

所謂無眾生，就是不能執著地考慮小團隊的利益，也要不斷擴充團隊的概念；為誰考慮，誰就會積極回應，而大家的利益就可能共同提高。

這三者的基礎是先要做到無我，所以這裡把淡化自己、其他團隊成員、團隊乃至客戶之間界限，將其共同利益作為出發點的心法，通稱為無我。

這種無我不是形式上的，比如某些敏捷開發的程式員口口聲聲為客戶價值負責，卻不能為測試人員、產品經理的利益負責，就是只學到形式上的無我。

回報與不執著於回報

無我與不考慮自己的利益是兩碼事，而是說若能綜合考慮全體的利益，自己的利益才能得到根本保證。

但若考慮全體的利益時，執著於自身得到回報，則是另一種我執（即執著於我）。

下一篇，還將談到回報與不執著於回報間的辯證，尤其是那些“在本公司都無法得到回報”的情況。

 

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