敏捷教練需要懂技術嗎？

在扣題之前我覺得有必要先針對“敏捷教練是否需要懂技術”這個話題進行簡單討論。

我曾親眼見過一個敏捷教練輔導團隊時，當團隊提問了與技術相關的問題時，他直接告訴團隊與技術相關的的問題需要咨詢下技術教練，可我當時聽到的明明是一個最基礎的技術概念，不需要太多的研發經驗，也不需要資深的技術基礎。甚至在最后他還不忘補充一句：“遇到問題多想想敏捷的價值觀和原則”。我心想：“這個問題和敏捷價值觀有毛關系？”。

從我接觸敏捷至今我一直堅信敏捷教練是需要懂技術的，至于原因我覺得有如下幾個方面：

1、敏捷宣言第一句

敏捷宣言第一句是什么？

“我們一直在實踐中探尋更好的軟件開發方法……”。所以敏捷從最初就是致力于探尋更好的軟件開發方法的，而作為幫助團隊利用敏捷方法成長和改進的敏捷教練，如果壓根就不懂軟件開發，道理如何能講得通呢？我曾經聽過一種觀點認為，敏捷教練是幫助團隊成長的，問題的解決應該是團隊的責任，而不是敏捷教練的責任。好像也有一點道理，但是又該如何與團隊對話并幫助團隊成長呢？靠高談闊論，還是靠吹牛？

2、更好的起步

團隊在進行敏捷轉型時，第一步要完成的工作是團隊現狀調研和分析。從團隊轉型這件事本身來說，調研是后續工作的基礎，只有清晰了團隊的問題和痛點，才能規劃出適合團隊的敏捷轉型方案和路徑。而從組織變革八步法的角度看，調研是建立緊迫感的有力手段，讓團隊認識到問題，才能驅動團隊產生變革意愿。

那么回到敏捷教練懂不懂技術的問題上，如果敏捷教練不懂技術就意味著調研時只能問一些偏重流程和管理的問題，問題識別的局限性導致了方案層的產出受到約束。而從團隊的感知上來說，會認為敏捷教練就是來提要求的，讓我們遵循既定的流程做事，把會議開好就夠了。

3、團隊輔導

敏捷教練在不斷地輔導過程中幫助團隊成長和改進，而輔導過程中自然會涉及到很多與技術相關的問題。我同意很多技術問題并不需要敏捷教練親自解決。但是，懂技術的敏捷教練往往可以與團隊建立信任。而信任是敏捷實踐融入團隊的基礎。

另一方面，團隊在敏捷轉型過程中涉及的很多問題往往都需要敏捷教練的評判。幫助團隊清晰工作投入的重點和方向的正確性。比如團隊希望引入持續集成實踐，敏捷教練至少能夠結合團隊現狀判斷實踐的導入時機和步驟是否存在問題。而不會認為這個和敏捷無關，團隊自己決定就好。

所以，也許敏捷教練不需要自己做太多，但一定要懂適量的技術，從而確保敏捷教練更好的融入并幫助團隊實現改進。

敏捷教練需要懂多少技術？

目前，敏捷教練逐步劃分為偏向管理方向的敏捷教練和技術方向的敏捷教練。技術輔導是技術方向敏捷教練的本職工作，自然不在本文的討論范圍內。

而即使有管理教練和技術教練的劃分，二者也始終會存在很多技能的交叉點。比如技術教練也需要懂一些管理實踐，而管理教練也需要了解一些技術知識。那管理教練需要了解哪些知識，又該掌握到什么程度呢？

從宏觀上看，管理教練最起碼要對研發的基本概念有基本的認知，比如：

1、研發流程涉及哪些環節？各個環節協作的難點和典型問題是什么？有什么好的應對措施？

2、研發團隊的各個角色如何合作？技術協作關系是怎樣的？

3、常見的軟件架構有哪些？優劣勢是什么？適合什么樣的團隊？

而從微觀上看，首先需要把研發流程進行拆分：

1、開發階段的核心實踐有哪些？使用哪些工具，解決什么問題？

2、測試階段的核心實踐有哪些？使用哪些工具，解決什么問題？

3、運維階段的核心實踐有哪些？使用哪些工具，解決什么問題？

其次，對典型的工程實踐也需要了解其原理以及常見的工具。可能涉及的知識包括：代碼分支管理、測試分層策略、代碼分析掃描、持續交付流水線、配置管理、環境管理等。

歸根結底敏捷教練（管理方向）不需要精通技術細節，但一定要對技術相關的基礎理念有足夠的了解。敏捷教練懂技術可以盡快與團隊建立信任，也有助于敏捷教練從全局視角看待團隊遇到的各種問題，以便于更好的制定團隊敏捷輔導計劃。

我記得曾經聽過一個觀點認為敏捷教練懂技術會讓他陷入技術細節，而不能很好的把控敏捷教練引導團隊改進的狀態。而我想說，對角色職責邊際的把控應該是每個合格敏捷教練必備的能力，不應該讓“懂技術”來背鍋！