從2000年在美國工作的時候，就開始知道敏捷開發流程，隨著後來自己開始管理技術團隊，對敏捷開發的理解也越來越透徹了。

敏捷開發其實就是軟體開發流程當中的特種部隊，以前的戰爭講求兵力的多少，武器的多少，而現代戰爭更加強調小規模性和快速應變能力。以前的軟體開發模式，設計階段需要寫很多文件，文件寫好了，發現需求可能又變了，然後又去修改文件，大量的精力花費在文件上面，開發進度很慢。設計階段，文件勞動量很大，開發和測試很閒，到了後期，產品經理又變得清閒，開發和測試很忙，而且產品,開發和測試3者之間的溝通成本很高。有的人玩笑說，當需求設計好，開發到一半，發現需求過時啦，白開發了。

前幾年開始，敏捷開發在國內流行起來，於是出現了很多的敏捷培訓師，傳授敏捷開發流程技術。如果團隊的單兵技術不行，硬要上敏捷開發，就和教一幫新兵蛋子特種部隊戰法似的。我們知道特種部隊的人員來源一般都是來自普通部隊的老兵，可見特種部隊的成功是和單兵素質分不開的。

個人認為，能夠成功實現敏捷開發，並且在高速開發中能夠保證產品質量的團隊，必須具有下面的特質：

1.    優秀的團隊領導，他是團隊的靈魂人物，就和一個冠軍球隊需要一個靈魂人物一樣，他是整個團隊的粘合劑，需要有跨界的綜合性能力。

他必須懂業務，我們知道軟體是為業務服務的，不懂業務搞軟體就是耍流氓，當然不一定是最精通業務的那個，但必須有很強的溝通能力，能夠通過和業務專家交流，迅速理解業務，並且有能力發現業務當中存在的問題，及時和業務專家反饋交流，在業務方面對業務專家是個協助作用。其實，因為他是跨界的，有時候能夠有很多新發現，業務專家都可能沒有想到，這也表現為卓越的學習能力。

全面的技術能力，因為需要統一規劃設計整個軟體系統，很多大型軟體系統，需要涉及到很多技術領域，如安卓開發，IOS開發，WEB開發，後臺開發，資料庫和運維等等，當然這些技術不一定是團隊裡面最強的，但很多時候，不同角度的思維可能會更有效的解決問題。本人對運維技術也是有涉獵的，對於LINUX命令，我不如公司的運維熟練，安裝監控工具，遠不如他熟練，但有一次他安裝JAVA伺服器，怎麼也搞不好，我幫他一下子解決了，因為他沒有程式設計經驗，JAVA的異常日誌看不懂，對我來說這是很簡單的事情，看了異常日誌，我就找到問題原因了。因為有全面的技術能力，在設計軟體的時候，就能考慮的更全面。其實很多問題都會出在介面的上面，因為技術全面，這些介面上面的問題都可以被及時發現，可能在設計階段就發現了，根本不需要到測試階段才發現。

放權的能力，諸葛亮是一個非常偉大的軍事家，但他致命的弱點就是不能放權，所以自己搞的很累，團隊管理的藝術在於知人善任。我看到打著放權旗號，其實是很昏庸的管理者，底下爛成一團了，自己都不知道，而且把權利放給錯誤的人，搞得團隊是小人得志的氣氛。放權能力和管理者自身的全面能力分不開的，因為能力強，他才能識別團隊當中的英才，並給予重任。我一直認為很多時候一個公司技術團隊領導人的高度，決定了一個公司技術的高度。我的一個朋友跟我講，他們公司CTO水平很一般，但是就是不招水平高的人，因為他怕水平高的人來了擠走他，這讓我想到了水泊梁山的那個王倫，當然也有大度的可以接納良才的，一般這樣的人都是公司重要股東，他自己不擔心有被邊緣化的憂慮。

選拔和培訓屬下的能力，這也是諸葛亮的一個巨大的弱點。團隊管理者必須把招聘當一個大事來抓，團隊質量的源頭需要把好關，發現有潛力的人，能夠激勵他們，培養他們，而且需要有能力營造一個大家學習技術的氛圍，讓大家感覺到來到這個團隊不光光掙了錢，還學到了很多東西。通過團隊技術交流，大家可以充分了解對方的長處，在團隊協作過程當中，可以更加密切，也可以同時發現自己的不足，進行提升。當然這個學習氣氛建立的前提是，你的團隊成員是有強烈學習慾望的，我也遇到很多程式設計師是不思進取的，做程式完成就行，不管完成的質量和效率。作為團隊領導人，需要在招聘環節就發現這種人，對已經在團隊裡面的成員也需要通過程式碼稽核，日常技術會議，發現那些人積極上進，那些人安於現狀，通過制度設計來激勵大家，如果實在不行的，就請出團隊，讓其另謀高就。優秀的團隊領導是允許屬下探索犯錯的，如果不給他們犯錯的機會，你的團隊成員就不會成長和學會獨立思考，但這種錯誤必須是可控範圍之內的，不能給團隊造成重大的損失，這也就是一個平衡的藝術，需要做到恰到好處。

優秀的溝通協調能力，很多時候，在任務安排上面，一個功能調整，哪方需要調整來適應對方，大家都希望自己省事，希望對方調整，這時候就需要團隊領導從全域性平衡出發，找到有利於產品長期發展的解決方案，對需要調整的一方講清楚利害關係。

優秀的產品架構能力，能夠想得很細，想得很遠，尤其一個大型軟體產品，是需要考慮長遠持續發展能力的，不能因為趕進度只顧眼前利益，當然也需要合理安排輕重緩急，平衡好產品開發時間和業務的關係，產品可以規劃好，業務緊急需求的可以優先開發，不急的可以延後開發。在看電視劇《戚繼光》的時候，我知道了戚繼光算定戰這個思想，大仗之前，這場戰役在他的頭腦裡面已經打了無數次了，當開始打的時候，已經是胸有成竹了。

2.    具有產品思維和測試思維的開發人員，具有良好的溝通能力，良好的程式碼風格和做事習慣，有強的產品主人翁意識，追求完美意識，懂得合理安排和規劃時間，有良好的學習主動性，喜歡看技術論壇，喜歡記錄技術心得。

傳統的開發團隊，開發人員只負責按照文件進行開發，具體為啥這樣做，這樣做好不好，都不需要管，在合作當中是一個被動的角色，這樣就需要產品經理把文件寫的很細，什麼類圖，時序圖，驗證條件說明等等，一堆東西。我們團隊最初推行敏捷開發的時候，按照敏捷理論，減少文件，結果IOS和安卓團隊理解完全不同，做出的東西不一樣。一個公司的產品，安卓版和IOS版本有明顯不同，這是不允許的。其實減少文件的前提，是開發能夠從被動角色轉變為主動角色，需要具備產品的思維，即使文件簡單，也能夠理解產品的意圖。特種部隊協同作戰的時候，我們看到他們常常使用手語，非常簡潔高效，但使用手語是建立在團隊成員互相瞭解，能夠密切配合的基礎上面的，這種配合已經變成了一種習慣，一種本能。開發團隊具有產品思維，可以把這種溝通變得簡潔高效，而且開發可以幫助產品發現錯誤，形成互補關係，錯誤如果在設計階段被發現，可以節省很多的成本。沒有產品思維的開發人員，需要更多的溝通時間，你告訴他做1,2,3,4,5，好的可能把5個都做了，差的可能就把2,4落下了，因為他沒有能夠真正理解產品設計的意圖。沒有產品思維的開發人員，在敏捷團隊裡面會成為豬隊友。

我發現很多開發人員認為測試是測試團隊的事情，開發只管寫程式碼，開發團隊為了趕進度，不重視質量，測試團隊發現一大堆BUG，然後又退回給開發，測試指出一個問題，開發修改一個，完全是被動角色。其實軟體開發理論裡面有單元測試和白盒測試，但我看到國內絕大多數團隊，都不做單元測試，很多工作好幾年的面試者，都不知道單元測試是什麼東西。作為創業公司，我們團隊很難招聘到優秀的開發人員，即使經過精挑細選的人員進入公司，也不知道怎麼做單元測試。雖然我想培訓大家做單元測試，但是任務多多，大家根本沒有時間學習這個，其實很多時候，國內的商業大環境就是這樣。個人認為，國內可能也只是超一流的公司這樣做吧。但本人認為，單元測試可以不做，但測試的思想必須是有的。很多程式設計師在做表單的時候，根本不去考慮驗證的事情，表單驗證這個可以簡單也可以複雜，詳細的驗證和提示，可以給使用者很好的體驗，而且降低後臺出錯的概率，當然後臺自己的驗證也是需要的，防止有人使用工具進行提交，繞開前端驗證。很多安全事件，都是因為開發者沒有測試思想導致的，開發者根本不知道SQL注入是什麼，認為程式只會按照你設定的路徑執行。其實一個軟體當中，90%的程式碼，我們都是在防止程式錯誤執行，如果什麼東西都能按照我們設定的路線走，這個世界就變得很美好啦，飛機就不會掉下來啦。微軟要求開發人員做開發之前，做2年測試工作，敏捷開發要求開發者編碼之前，要想好怎麼測試程式。國內我聽到這樣一個故事，畢業學生去面試，能力不強，做不了開發，那麼去做測試吧，測試被當做了一個低端的活兒。據說淘寶測試總監薪水有100多萬，測試是很具有技術含量的，而且現在的自動化測試趨勢，更需要測試和開發的融合。實際上一個優秀的開發人員，不但可以做好開發，也可以做好測試，優秀的開發人員把程式交給測試的時候，明顯的錯誤就已經沒有了，測試團隊只是對他工作的檢驗和補充，協助他發現一些難發現的錯誤。當測試發現了錯誤，作為開發者，需要思考發生的原因，並且能夠發現同類型的問題，這些問題，測試可能還沒有發現。

不當的異常處理方式，沒有命名規則，變數太多，命名不清晰，不注意作用域，大段大段的IF-ELSE迴圈巢狀，導致程式碼可讀寫極差。這樣的程式碼就像一堆胡亂堆放的麻繩，很難讓人清晰的看到來龍去脈，程式碼的最高境界不是把程式碼做複雜，而且使用簡單的方法解決問題，大道至簡，清晰有條理的程式碼，自己和他人都容易發現問題，程式碼風格其實代表了一個程式設計師的思維方式。

主人翁意識在團隊協作當中非常非常重要，和其他團隊成員做對接的時候，需要對對方的工作進行檢查，因為任何人都會犯錯誤，這種二次核查對於減少BUG是很有必要的，而且發現問題應該及時反映出來進行討論解決，而不是抱著反正不是我的錯的思想，是產品讓我這樣做的，做錯了也不是我的事情，協助團隊成員進行核查其實就是一種追求完美的表現，只有在這種相互協助相互督促相互幫助的環境下，產品質量和開發效率才會不斷提升。

很多程式設計師都遇到過同時有多個任務在手的情況，合理安排時間，合理安排輕重緩急，就顯得非常重要。對於一個敏捷團隊這個能力非常重要，敏捷團隊成員不應該不知道自己該做什麼，需要能夠在幾個任務自由切換，如果主要任務因為他人情況停頓了，可以利用這個時間做其它次要的任務，敏捷團隊成員應該是一個多工作業系統，知道合理的安排時間片，及時的應答緊急任務，不急的時候做優先順序低的事情，不應該出現突然忙得要死，又突然閒的要死的情況。開發任務不緊了，可以多學習學習，多寫寫工作總結，總結歸納自己工作當中那些需要做的更好的。有任務就是上陣殺敵，無任務就是刻苦練兵，拓展自己的技能寬度和深度。

沒有學習主動性的人，是不可能成為一個敏捷隊員的，敏捷隊員需要掌握複合型技能，需要有向全棧工程師發展的勇氣和決心，不想當將軍的士兵不是好士兵。一個有學習主動性的人，只要你給他一個良好的環境，他就迅速成長為參天大樹，反之，再多的機會和培訓都是浪費。有學習主動性的人，會積極關注技術論壇，寫自己的技術心得，把這當做自己生活和工作的一部分。

很多程式設計師都是宅男，不善於溝通，我聽到很多取笑程式設計師不會溝通的笑話。善於溝通的產品經理和不善於溝通的程式設計師進行合作，確實會有很多誤解和矛盾。一個善於溝通的程式設計師會從產品經理那裡學習到產品思維，使他們的之間的溝通變得準確和高效，而且他更能幫助產品經理髮現問題，在協助當中會從被動轉向主動。善於溝通的程式設計師可以成為開發額中堅力量，幫助團隊其他成員成長。善於溝通會大大提升開發的效率，把很多問題在開發之前就發現，大大降低開發成本。很多時候，我把任務交給下面開發的時候，我都希望他們能夠講講他們打算怎麼做的思路，但很多情況下，對方都是支支吾吾，說不清楚，我把我的思路講給他，他也只是點頭，沒有啥問題，當代碼完成我稽核程式碼的時候，我發現很多問題，其實這些問題，如果當初他能夠表達出來，我當時就會幫他糾正。因為不會溝通，問題只能在程式碼編寫以後才能發現，又需要花時間去修改程式碼，來來回回時間就這樣浪費了。編碼的效率就在於你在編碼之前能夠想到多少問題，預見到的問題越多，程式碼質量就越高，程式碼反覆修改的次數就越少。其實，善於溝通的程式設計師就是善於思考的程式設計師，你是用手寫程式碼還是用腦寫程式碼，最後就會體現在你的程式碼質量上面。小時候學下象棋，發現高手是不需要看著象棋來下的，程式設計師如果能夠把自己的思路通過圖和簡單語言表達出來，就最終可以實現這種境界。

3.    團隊成員在技能上面需要有一定廣度，不能只有深度，尤其團隊領導廣度是必須具備的，其實在軟體開發當中，很多問題都出現在介面部分，很多時候因為對介面理解的錯誤導致很多BUG出現。如果團隊成員能夠具備一定對方的知識，能夠準確理解對方意圖。