敏捷教练需要懂技术吗？
在扣题之前我觉得有必要先针对“敏捷教练是否需要懂技术”这个话题进行简单讨论。
我曾亲眼见过一个敏捷教练辅导团队时，当团队提问了与技术相关的问题时，他直接告诉团队与技术相关的的问题需要咨询下技术教练，可我当时听到的明明是一个最基础的技术概念，不需要太多的研发经验，也不需要资深的技术基础。甚至在最后他还不忘补充一句：“遇到问题多想想敏捷的价值观和原则”。我心想：“这个问题和敏捷价值观有毛关系？”。
从我接触敏捷至今我一直坚信敏捷教练是需要懂技术的，至于原因我觉得有如下几个方面：
1、敏捷宣言第一句
敏捷宣言第一句是什么？
“我们一直在实践中探寻更好的软件开发方法……”。所以敏捷从最初就是致力于探寻更好的软件开发方法的，而作为帮助团队利用敏捷方法成长和改进的敏捷教练，如果压根就不懂软件开发，道理如何能讲得通呢？我曾经听过一种观点认为，敏捷教练是帮助团队成长的，问题的解决应该是团队的责任，而不是敏捷教练的责任。好像也有一点道理，但是又该如何与团队对话并帮助团队成长呢？靠高谈阔论，还是靠吹牛？
2、更好的起步
团队在进行敏捷转型时，第一步要完成的工作是团队现状调研和分析。从团队转型这件事本身来说，调研是后续工作的基础，只有清晰了团队的问题和痛点，才能规划出适合团队的敏捷转型方案和路径。而从组织变革八步法的角度看，调研是建立紧迫感的有力手段，让团队认识到问题，才能驱动团队产生变革意愿。
那么回到敏捷教练懂不懂技术的问题上，如果敏捷教练不懂技术就意味着调研时只能问一些偏重流程和管理的问题，问题识别的局限性导致了方案层的产出受到约束。而从团队的感知上来说，会认为敏捷教练就是来提要求的，让我们遵循既定的流程做事，把会议开好就够了。
3、团队辅导
敏捷教练在不断地辅导过程中帮助团队成长和改进，而辅导过程中自然会涉及到很多与技术相关的问题。我同意很多技术问题并不需要敏捷教练亲自解决。但是，懂技术的敏捷教练往往可以与团队建立信任。而信任是敏捷实践融入团队的基础。
另一方面，团队在敏捷转型过程中涉及的很多问题往往都需要敏捷教练的评判。帮助团队清晰工作投入的重点和方向的正确性。比如团队希望引入持续集成实践，敏捷教练至少能够结合团队现状判断实践的导入时机和步骤是否存在问题。而不会认为这个和敏捷无关，团队自己决定就好。
所以，也许敏捷教练不需要自己做太多，但一定要懂适量的技术，从而确保敏捷教练更好的融入并帮助团队实现改进。
敏捷教练需要懂多少技术？
目前，敏捷教练逐步划分为偏向管理方向的敏捷教练和技术方向的敏捷教练。技术辅导是技术方向敏捷教练的本职工作，自然不在本文的讨论范围内。
而即使有管理教练和技术教练的划分，二者也始终会存在很多技能的交叉点。比如技术教练也需要懂一些管理实践，而管理教练也需要了解一些技术知识。那管理教练需要了解哪些知识，又该掌握到什么程度呢？
从宏观上看，管理教练最起码要对研发的基本概念有基本的认知，比如：
1、研发流程涉及哪些环节？各个环节协作的难点和典型问题是什么？有什么好的应对措施？
2、研发团队的各个角色如何合作？技术协作关系是怎样的？
3、常见的软件架构有哪些？优劣势是什么？适合什么样的团队？
而从微观上看，首先需要把研发流程进行拆分：
1、开发阶段的核心实践有哪些？使用哪些工具，解决什么问题？
2、测试阶段的核心实践有哪些？使用哪些工具，解决什么问题？
3、运维阶段的核心实践有哪些？使用哪些工具，解决什么问题？
其次，对典型的工程实践也需要了解其原理以及常见的工具。可能涉及的知识包括：代码分支管理、测试分层策略、代码分析扫描、持续交付流水线、配置管理、环境管理等。
归根结底敏捷教练（管理方向）不需要精通技术细节，但一定要对技术相关的基础理念有足够的了解。敏捷教练懂技术可以尽快与团队建立信任，也有助于敏捷教练从全局视角看待团队遇到的各种问题，以便于更好的制定团队敏捷辅导计划。
我记得曾经听过一个观点认为敏捷教练懂技术会让他陷入技术细节，而不能很好的把控敏捷教练引导团队改进的状态。而我想说，对角色职责边际的把控应该是每个合格敏捷教练必备的能力，不应该让“懂技术”来背锅！
