这是鼎叔的第六十篇原创文章。行业大牛和刚毕业的小白，都可以进来聊聊。
欢迎关注本专栏和微信公众号《敏捷测试转型》，星标收藏，大量原创思考文章陆续推出。
本文聊聊团队的敏捷转型为什么容易失败，以及澄清这个误解：敏捷测试就是自动化测试。
上文聊聊敏捷与敏捷测试，说到：很多人把敏捷测试理解为自动化测试，我认为这个观点是非常狭隘的：自动化测试并不是帮助测试团队敏捷转型成功的银弹，因为：
如果测试分析和设计能力不足，用例质量不高，那么做再多的自动化测试也发现不了问题。自动化主要用来做已有功能的回归保障。
自动化测试收益不一定满足组织预期，有些时候是用来掩盖测试团队真正短板的遮羞布，看着运行数据挺漂亮，可能实际价值很低。
脚本数量越大，维护成本越高，不及时更新就会有杀虫剂效应（就像庄稼长期播撒一种杀虫剂会致使害虫逐渐具有抗药性），导致有效缺陷率也会越来越低。
它解决不了测试团队的低效沟通问题。
它通常发现不了用户关心的体验问题。
自动化测试项目并不会让所有测试人员都受益，很多测试成员在自动化实践中获得的专业提升幅度很有限。
在敏捷理论的大量经典著作中，自动化测试的工程保障内容只占比例非常小的一块。更多方向的价值有待测试团队去挖掘，这也是本公众号各专辑要陆续介绍的。
一个公司的敏捷转型为什么会失败
首先，基于观察到的案例总结一下，一个公司的敏捷转型为什么会失败？最常见的原因如下。
1）高级管理层并没有足够的决心，或者过于乐观/悲观。
转型本身会改变大家的工作流程和习惯，而敏捷又是跨多个不同岗位部门的协作。我们把单一职能部门被称为 “竖井”，即只完成垂直一块的职责，如果没有高级管理者的大力支持，敏捷转型一定会在 “竖井” 之间的高墙阻碍下步履蹒跚。
有些高级管理者对敏捷转型有投资意愿，但是对其价值目标缺乏清楚的认识，虽然邀请了专家顾问主导，转型启动时声势浩大，投资不菲，但是过一段时期没有看到明显的成效，马上就偃旗息鼓了。
2）部分管理者因为权力被触动，在敏捷转型中消极对待。
敏捷原则的落实，需要特性团队自主决策，信息透明，成员平等。原先的管理者需要放弃强力干预的风格，在考核上也做出让权，而且不能利用信息不对等谋求个人的影响力。管理者不管是否在一线特性交付团队，都需要调整自己的心态和工作方式，即从命令者/指导者变为服务者。
无法转变心态的管理者，有可能对敏捷转型的新流程和效果持负面看法。也有可能强行 “加戏”，在转型目标中加入不必要的内容以凸显自己的主导地位。
敏捷转型试点团队以外的管理者，也有可能针对试点敏捷中的小失误，向高管提出抱怨，否定继续敏捷转型的必要性。
官本位的管理者，往往把管理下属的人数作为自己权力大小的体现。在原来职能部门的竖井管理模式中，员工创造的价值是不太透明的。而在敏捷特性团队的模式中，每一个全职人员交付了多少价值，相对是清晰透明的，这样很容易把原来职能团队的人力水分挤出去，导致管理规模缩小。这也是一小部分管理者对敏捷持警觉态度的原因。
3）团队初期充满干劲，但并没有深入理解敏捷。
对于这种情况，通常随着时间的推移，团队会越来越疲乏，转型负责人身心俱疲，员工信心受挫。
团队缺乏一个精通敏捷的有影响力的教练，缺乏一个循序渐进的理解敏捷的过程。负责人可能非常热情，通过各种调研给出了改进现状的各种措施，研发平台也上线了大量提效功能，团队在初期像打了鸡血往前冲。但需要敏捷改进的地方实在太多了，在业务压力下，激情难以持续。利用工具平台提升效率的场景通常很零散，难以统一团队共识，如果大家内心连基础的敏捷原则都没有遵守，再强大的工具平台也无济于事。而且，被设计得越来越复杂的平台，会让员工更加有抵触情绪。
正确的姿势应该是先全员学习敏捷课程，演练基本技巧，明确三驾马车（Scrum Master，产品负责人，技术负责人）的角色职责，从初期到中长期，循序渐进，工具平台仅作为配套支持，从简单功能到进化功能，逐步上线。
4）组织架构缺乏激励。
在公司激励制度不足的情况下，有可能出现试点团队很成功，但是并没有得到任何收益，甚至团队被迫解散的情况。也经常发生一旦支持变革的领导离职，敏捷转型就走向沉默的现象。
一个长期支持敏捷成果落地的组织架构非常重要，它的目标就是让敏捷先行者根据收益得到回报，激励其他团队转型，同时也给予足够的自治权。
所有特性团队的内部考核流程也很关键，这和单一职能部门的内部考核完全不同。敏捷团队考核强调的是集体成功导向，个人被团队认可，职能部门管理者（如果有的话）最多保留部分考核权力，让业务成功的特性团队整体上都得到更多的激励，其中受团队爱戴的核心角色应该得到更多的专业晋升机会。
当然，除了这四种主要的失败原因，还有很多其他原因，这里暂且不一一展开。我们进一步思考下面这个问题：
测试团队的敏捷转型为什么会失败？
让我们再从测试人员的角度来看转型失败，又有哪些原因值得更进一步剖析？
1）测试人员没有深入理解敏捷，并利用好它。
不少测试人员认为 “敏捷” 就是个虚架子，给我们徒增麻烦，让本就紧张的交付周期变得更加紧张，加班也会更加严重。
这些都是对敏捷的误解。测试人员没有认真理解敏捷精髓，白白错过了通过它保护自己劳动成果的机会，也可能让自己总是被不懂敏捷的其他角色瞎指挥，最终得出 “敏捷没啥用” 的错误认知。这类错误认知还会让其他负面因素恶化，加速失控。
2）老流程考核还在，新敏捷流程也要搞。
这是很常见的敏捷转型失败原因。测试人员经常诉苦道，原先制定的复杂流程和指标考核一个没少，新敏捷的各种纪律保障和指标又不断增加，感觉在同时打两份工，自然对敏捷行动产生抵触情绪。
敏捷变革应该从试点项目开始，重新塑造交互流程和交付标准，而不是背着历史包袱。尤其是要去除测试人员的 “质量兜底” 心理负担，树立起质量事故的全员担当文化，根据用户反馈数据来调整敏捷交付的质量标准。
敏捷需求和任务分工中，让测试人员的精力得到可持续保障，把测试类任务充分纳入排期（结合需求的优先级），让测试人员得到自主开展工作的充分授权。
3）缺乏技术提升机会，测试人员流失。
因为敏捷特性团队的目标是快速交付产品，而测试人员在其中可能感觉势单力薄，被辅导的机会很少，所以很多人在快节奏下逐步放弃了对测试技术的打磨，最终影响自己的专业晋升，甚至被迫离开团队，去追求更磨练技术的岗位。人员流失又加重了自动化保障缺乏的困境，陷入恶性循环。
快速交付产品的基础保障就是测试技术的高效能，这需要跨特性团队的测试领域负责人（或专家），提供更多的横向拉通和技术辅导机会。所以，测试人员分配到各个特性团队做全职工作，并不意味着原先的测试主管或测试架构师就只能做甩手掌柜。同时，每个特性团队也要在迭代排期中预留测试技术债的偿还时间，并给予较高的优先级。
4）测试变成打杂的。
和上一个原因类似，如果敏捷团队的主导者不重视专业测试的价值，不重视测试类工作，把项目当前低优先级的各类工作去填满测试人员的工作区，必将导致测试人员缺乏成就感。
这种情况也暴露了特性团队并非处于 “平等、自治” 和追求全栈能力的状态，违反 “共同为质量负责” 的原则。对于可以跨角色完成的工作，可以遵循自愿分工，按估算分配的模式。如果现阶段不希望在专业测试任务上花费太多精力，建议不在团队里安排全职的测试工程师，指派组织内的其他测试工程师参与技术评审和验收阶段把关即可。
最后，我们对敏捷测试的认知做一下纠偏：
所有敏捷理论中保护开发活动效能的道理，也适用于测试活动。
测试人员也会面临和开发人员一样的困扰：被频繁打扰、被浪费成果、被怀疑专业度、没有精力完成技术债。
测试活动的任务排期、估算、完成速率、优先级等，也是需要统一纳入敏捷规划中的。
因此，测试团队需要建立信任、自主、透明、共建的敏捷测试文化，真正融入到整个敏捷转型组织之中。