敏捷教练对于效能提升来说是必须的吗？

在一次行业交流中，有朋友问到“过度强调敏捷是否会把自己保护起来，反而降低效能？比如，当提出一个需求，又要考虑排期，又要考虑置换，是不是不如领导一句话直接开始行动更加高效？”我想简单谈谈自己的看法。

研发效能和敏捷可以说是相辅相成的，我们要理解研发效能不仅仅需要高效开发，还要保证需求是有价值的。从度量指标角度来看，既有研发需求相关的交付周期，也有需求发布到生产之后相关的质量和价值以及客户满意度等指标；而敏捷不仅仅包含传统狭义的敏捷软件开发，广义上也要求组织成为敏捷组织。敏捷组织的特征，除了及时响应变化，也是可持续的、有效的、高效的、顺畅的交付和创造价值。敏捷方法和实践就是进行敏捷软件开发、提升研发效能和成为敏捷组织的手段，所以对于效能提升来说，敏捷方法和实践是必需的。如果组织需要敏捷方法和实践方面的赋能、维持和提升，那么敏捷教练也是必需的；但是，如果团队已经在践行敏捷管理实践和工程实践上很有经验，团队可以自我驱动和自我管理，那么就不需要敏捷教练来支持和服务。

问题中提到的“过度强调敏捷”和“把自己保护起来”，这是不相关的。逻辑上来说，敏捷是打开追求卓越的大门，没有止境的持续改进，所以没有过度的说法。另外敏捷的价值观、原则和实践也和自我保护无关，或者换一种说法，敏捷和所有的方法是一样的，都是需要纪律的。回到问题本身，如何提高效能呢？难道仅仅是凭领导一句话：这个需求优先级高，必须赶紧实现，而且要明天上线，还要保证质量？

我相信很多工程师早就有对这种情景的痛苦体会了。这不是直接行动就更加高效的事情。还是要看当下的需求优先级，当下的进度，以及端迭代周期的交付目标，并且思考和判断新提出来的需求为什么这么着急？原则上产品本身要有路线图、短期规划（短周期迭代）和中期计划（4-6 个迭代），在这种前提下，进行有纪律的迭代开发的时候，突然提出插入一个新需求的概率将会大大降低。如果短周期迭代时间足够短（1-2 周），先停止半成品的开发再加入新的需求，成本往往比先完成半成品再增加新需求高。我们建议的最佳的实践是将新增需求、优化需求等排入下一个迭代进行交付。

因此，还是要看如何落地敏捷，有何实操的措施帮助团队和组织提效；并且是系统性的考虑和方法，而不是局部的优化。例如从改进需求的交付周期角度来看，往往是将需求拆分成小颗粒度的需求，进行小批量的分析、端周期（1-2 周）迭代开发和交付；从提升团队的产能角度来看，通常要将团队组织成面向价值流交付的端到端的特性团队，人数在 10 人级别，并通过软件架构的解耦来降低团队间的耦合，提高交付的质量的同时减少不同职能间交接的浪费，从而有效提高产能；从提升业务价值角度来看，按迭代定期获取用户或者市场对产品的反馈，可以加速反馈循环，从而持续快速验证价值假设、打磨产品、提升价值甚至调整方向。

本文整理自《研发效能100问》，原作者 赵卫 敏捷 DevOps 专家 《软件研发效能权威指南》副主编