敏捷開發一千零一問系列之一：序言及解決問題的心法（無我）

 作敏捷開發時間長了，就感受不少事情都理所固然，愈加以爲「問題很難得」，最近作培訓的時候收集了一些問題，不少現場來不及解答，逐一發表在這裏。

如何解決一個問題

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

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

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

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

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

無我

包括兩個部分，無我無人 和 無如今無將來的我。

無我無人

這裏的」人「是他人的意思。

原來的敏捷宣言中包括了無我無人的成分，「個體與交互賽過過程與工具」及「客戶協做賽過合同談判」說的就是這個部分。

爲何須要過程、工具、合同、談判？由於有部門分割，有利益差別。

在傳統開發過程當中無形中產生了不少對立團體，好比客戶負責本身的價值而咱們負責編寫功能（注意功能不等於價值，不然用戶故事語法就不須要前面的」做爲一個……「和後面的」以便……「了），程序負責編碼而測試負責質量，領導負責計劃而員工負責執行，產品經理負責銷售市場及競爭力而項目組負責……甚至乃至在一個團隊中，都有個人任務、你的任務之分，一旦這些成爲事實，那就太須要過程、工具、合同、談判了。

因此要用敏捷開發的方法解決問題，首先應該先融合不一樣團體的利益，好比擁抱客戶價值，擁抱變化，團隊工做，代碼全部制，自動化測試與持續集成（開發人員參與編碼的測試）、代碼審查……

無如今的我和將來的我

就是千萬不要以眼前利益爲驅動，而要把如今和將來放在一塊兒考慮。

這個沒有出如今敏捷宣言裏，於是經常被僞敏捷的人拿來做爲不寫文檔的接口，又被反敏捷的人拿來做爲***敏捷的漏洞。

」到底要不要寫文檔？「答案固然是」看着辦「。但怎麼看着辦呢？若是一我的在」看「的時候內心想：」其實我本身開發者寫代碼不需把想法寫出來的，如今勞心費神寫文檔的人是我，將來不知道便宜了哪一個後來人呢「，這個時候看着辦就是危險的。

但若是他在想：」這個部分代碼裏邊表達地很不清楚，而這個產品20年後還會有人用（好比汽車電子），因此應該寫成文檔；那個地方呢，一看代碼就很明確了，不寫了。「這個時候看着辦就是安全的。

差異在哪裏？第一我的的想法裏邊有」我「有」他人「，干擾了看着辦的出發點。

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

還有不少事情有如今和將來的差異，好比短時間功能的生產率與長期架構的穩定性，短時間「強分工的專家團隊」的高效率與從此人員離職的困擾，如今馬馬虎虎提交代碼與往後測試團隊加班測試……這裏邊潛意識裏都有一個概念：「如今先湊合過吧，到時候我還在不在仍是個問題呢」。這都是由於區分如今的我和將來的個人緣由。

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

若是解決問題的時候，老是想「咱們應該幹什麼，他們應該幹什麼」「由於他們少幹了什麼，因此咱們不能幹什麼」「這件事情沒作好，是由於他……」，那麼像開發人員要關心客戶價值、兩我的要結對編程、一個團隊要天天立會這些實踐，就永遠用很差。