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

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

做敏捷開發時間長了，就感覺很多事情都理所當然，越發覺得“問題很可貴”，最近做培訓的時候收集了一些問題，很多現場來不及解答，逐一發表在這裡。

如何解決一個問題

知識多了自然可以解決問題，經歷多了自然也可以積累經驗，但是在一個只出現10年的領域，還有一堆只工作了10多年的年輕人中間，必然有一天會遇到從來沒有人解決過的問題，這時候怎麼辦呢？

掌握解決問題的心法是核心。

對這個系列而言，就是要掌握用敏捷開發的方法解決問題的心法。掌握了心法就能解決所有問題，這比知道一千零一個問題的答案更加重要，因此會先用三篇來綜述一下解決問題的心法，可以總結為無我、無住、共振三個詞彙。

為什麼不寫成更通俗易懂的現代漢語？因為找不到貼切的詞彙，更沒有簡短、容易記憶的語句，羅哩羅嗦寫了一大段，保證大家關閉IE就忘光了。

估計在看完十個二十個問題和答案後，再回來看這篇序言，大家會和我一樣認同這三個詞彙是最佳答案。

無我

包括兩個部分，無我無人 和 無現在無未來的我。

無我無人

這裡的”人“是他人的意思。

原來的敏捷宣言中包括了無我無人的成分，“個體與互動勝過過程與工具”及“客戶協作勝過合同談判”說的就是這個部分。

為什麼需要過程、工具、合同、談判？因為有部門分割，有利益差異。

在傳統開發過程中無形中產生了很多對立團體，比如客戶負責自己的價值而我們負責編寫功能（注意功能不等於價值，否則使用者故事語法就不需要前面的”作為一個……“和後面的”以便……“了），程式負責編碼而測試負責質量，領導負責計劃而員工負責執行，產品經理負責銷售市場及競爭力而專案組負責……甚至乃至在一個團隊中，都有我的任務、你的任務之分，一旦這些成為事實，那就太需要過程、工具、合同、談判了。

所以要用敏捷開發的方法解決問題，首先應該先融合不同團體的利益，比如擁抱客戶價值，擁抱變化，團隊工作，程式碼所有制，自動化測試與持續整合（開發人員參與編碼的測試）、程式碼審查……

無現在的我和未來的我

就是千萬不要以眼前利益為驅動，而要把現在和未來放在一起考慮。

這個沒有出現在敏捷宣言裡，因而常常被偽敏捷的人拿來作為不寫文件的介面，又被反敏捷的人拿來作為攻擊敏捷的漏洞。

”到底要不要寫文件？“答案當然是”看著辦“。但怎麼看著辦呢？如果一個人在”看“的時候心裡想：”其實我自己開發者寫程式碼不需把想法寫出來的，現在勞心費神寫文件的人是我，未來不知道便宜了哪個後來人呢“，這個時候看著辦就是危險的。

但如果他在想：”這個部分程式碼裡邊表達地很不清楚，而這個產品20年後還會有人用（比如汽車電子），所以應該寫成文件；那個地方呢，一看程式碼就很明確了，不寫了。“這個時候看著辦就是安全的。

差別在哪裡？第一個人的想法裡邊有”我“有”他人“，干擾了看著辦的出發點。

人有天生的惰性，習慣了”Max the undo“，就是把事情拖到最後再做，如果一旦誤解了敏捷開發中的“不做不行的時候才做”，就很容易找到藉口把很多應該做的事情推掉。

還有很多事情有現在和未來的差別，比如短期功能的生產率與長期架構的穩定性，短期“強分工的專家團隊”的高效率與今後人員離職的困擾，現在馬馬虎虎提交程式碼與日後測試團隊加班測試……這裡邊潛意識裡都有一個概念：“現在先湊合過吧，到時候我還在不在還是個問題呢”。這都是因為區分現在的我和未來的我的原因。

無我對於運用敏捷開發方法解決問題至關重要。

如果解決問題的時候，總是想“我們應該幹什麼，他們應該幹什麼”“因為他們少幹了什麼，所以我們不能幹什麼”“這件事情沒做好，是因為他……”，那麼像開發人員要關心客戶價值、兩個人要結對程式設計、一個團隊要每天立會這些實踐，就永遠用不好。