这是鼎叔的第六十篇原创文章。行业大牛和刚毕业的小白,都可以进来聊聊。

欢迎关注本专栏和微信公众号《敏捷测试转型》,星标收藏,大量原创思考文章陆续推出。

本文聊聊团队的敏捷转型为什么容易失败,以及澄清这个误解:敏捷测试就是自动化测试。

上文聊聊敏捷与敏捷测试,说到:很多人把敏捷测试理解为自动化测试,我认为这个观点是非常狭隘的:自动化测试并不是帮助测试团队敏捷转型成功的银弹,因为:

如果测试分析和设计能力不足,用例质量不高,那么做再多的自动化测试也发现不了问题。自动化主要用来做已有功能的回归保障。
自动化测试收益不一定满足组织预期,有些时候是用来掩盖测试团队真正短板的遮羞布,看着运行数据挺漂亮,可能实际价值很低。
脚本数量越大,维护成本越高,不及时更新就会有杀虫剂效应(就像庄稼长期播撒一种杀虫剂会致使害虫逐渐具有抗药性),导致有效缺陷率也会越来越低。
它解决不了测试团队的低效沟通问题。
它通常发现不了用户关心的体验问题。
自动化测试项目并不会让所有测试人员都受益,很多测试成员在自动化实践中获得的专业提升幅度很有限。
在敏捷理论的大量经典著作中,自动化测试的工程保障内容只占比例非常小的一块。更多方向的价值有待测试团队去挖掘,这也是本公众号各专辑要陆续介绍的。

一个公司的敏捷转型为什么会失败

首先,基于观察到的案例总结一下,一个公司的敏捷转型为什么会失败?最常见的原因如下。

1)高级管理层并没有足够的决心,或者过于乐观/悲观。

转型本身会改变大家的工作流程和习惯,而敏捷又是跨多个不同岗位部门的协作。我们把单一职能部门被称为 “竖井”,即只完成垂直一块的职责,如果没有高级管理者的大力支持,敏捷转型一定会在 “竖井” 之间的高墙阻碍下步履蹒跚。

有些高级管理者对敏捷转型有投资意愿,但是对其价值目标缺乏清楚的认识,虽然邀请了专家顾问主导,转型启动时声势浩大,投资不菲,但是过一段时期没有看到明显的成效,马上就偃旗息鼓了。

2)部分管理者因为权力被触动,在敏捷转型中消极对待。

敏捷原则的落实,需要特性团队自主决策,信息透明,成员平等。原先的管理者需要放弃强力干预的风格,在考核上也做出让权,而且不能利用信息不对等谋求个人的影响力。管理者不管是否在一线特性交付团队,都需要调整自己的心态和工作方式,即从命令者/指导者变为服务者。

无法转变心态的管理者,有可能对敏捷转型的新流程和效果持负面看法。也有可能强行 “加戏”,在转型目标中加入不必要的内容以凸显自己的主导地位。

敏捷转型试点团队以外的管理者,也有可能针对试点敏捷中的小失误,向高管提出抱怨,否定继续敏捷转型的必要性。

官本位的管理者,往往把管理下属的人数作为自己权力大小的体现。在原来职能部门的竖井管理模式中,员工创造的价值是不太透明的。而在敏捷特性团队的模式中,每一个全职人员交付了多少价值,相对是清晰透明的,这样很容易把原来职能团队的人力水分挤出去,导致管理规模缩小。这也是一小部分管理者对敏捷持警觉态度的原因。

3)团队初期充满干劲,但并没有深入理解敏捷。

对于这种情况,通常随着时间的推移,团队会越来越疲乏,转型负责人身心俱疲,员工信心受挫。

团队缺乏一个精通敏捷的有影响力的教练,缺乏一个循序渐进的理解敏捷的过程。负责人可能非常热情,通过各种调研给出了改进现状的各种措施,研发平台也上线了大量提效功能,团队在初期像打了鸡血往前冲。但需要敏捷改进的地方实在太多了,在业务压力下,激情难以持续。利用工具平台提升效率的场景通常很零散,难以统一团队共识,如果大家内心连基础的敏捷原则都没有遵守,再强大的工具平台也无济于事。而且,被设计得越来越复杂的平台,会让员工更加有抵触情绪。

正确的姿势应该是先全员学习敏捷课程,演练基本技巧,明确三驾马车(Scrum Master,产品负责人,技术负责人)的角色职责,从初期到中长期,循序渐进,工具平台仅作为配套支持,从简单功能到进化功能,逐步上线。

4)组织架构缺乏激励。

在公司激励制度不足的情况下,有可能出现试点团队很成功,但是并没有得到任何收益,甚至团队被迫解散的情况。也经常发生一旦支持变革的领导离职,敏捷转型就走向沉默的现象。

一个长期支持敏捷成果落地的组织架构非常重要,它的目标就是让敏捷先行者根据收益得到回报,激励其他团队转型,同时也给予足够的自治权。

所有特性团队的内部考核流程也很关键,这和单一职能部门的内部考核完全不同。敏捷团队考核强调的是集体成功导向,个人被团队认可,职能部门管理者(如果有的话)最多保留部分考核权力,让业务成功的特性团队整体上都得到更多的激励,其中受团队爱戴的核心角色应该得到更多的专业晋升机会。

当然,除了这四种主要的失败原因,还有很多其他原因,这里暂且不一一展开。我们进一步思考下面这个问题:

测试团队的敏捷转型为什么会失败?

让我们再从测试人员的角度来看转型失败,又有哪些原因值得更进一步剖析?

1)测试人员没有深入理解敏捷,并利用好它。

不少测试人员认为 “敏捷” 就是个虚架子,给我们徒增麻烦,让本就紧张的交付周期变得更加紧张,加班也会更加严重。

这些都是对敏捷的误解。测试人员没有认真理解敏捷精髓,白白错过了通过它保护自己劳动成果的机会,也可能让自己总是被不懂敏捷的其他角色瞎指挥,最终得出 “敏捷没啥用” 的错误认知。这类错误认知还会让其他负面因素恶化,加速失控。

2)老流程考核还在,新敏捷流程也要搞。

这是很常见的敏捷转型失败原因。测试人员经常诉苦道,原先制定的复杂流程和指标考核一个没少,新敏捷的各种纪律保障和指标又不断增加,感觉在同时打两份工,自然对敏捷行动产生抵触情绪。

敏捷变革应该从试点项目开始,重新塑造交互流程和交付标准,而不是背着历史包袱。尤其是要去除测试人员的 “质量兜底” 心理负担,树立起质量事故的全员担当文化,根据用户反馈数据来调整敏捷交付的质量标准。

敏捷需求和任务分工中,让测试人员的精力得到可持续保障,把测试类任务充分纳入排期(结合需求的优先级),让测试人员得到自主开展工作的充分授权。

3)缺乏技术提升机会,测试人员流失。

因为敏捷特性团队的目标是快速交付产品,而测试人员在其中可能感觉势单力薄,被辅导的机会很少,所以很多人在快节奏下逐步放弃了对测试技术的打磨,最终影响自己的专业晋升,甚至被迫离开团队,去追求更磨练技术的岗位。人员流失又加重了自动化保障缺乏的困境,陷入恶性循环。

快速交付产品的基础保障就是测试技术的高效能,这需要跨特性团队的测试领域负责人(或专家),提供更多的横向拉通和技术辅导机会。所以,测试人员分配到各个特性团队做全职工作,并不意味着原先的测试主管或测试架构师就只能做甩手掌柜。同时,每个特性团队也要在迭代排期中预留测试技术债的偿还时间,并给予较高的优先级。

4)测试变成打杂的。

和上一个原因类似,如果敏捷团队的主导者不重视专业测试的价值,不重视测试类工作,把项目当前低优先级的各类工作去填满测试人员的工作区,必将导致测试人员缺乏成就感。

这种情况也暴露了特性团队并非处于 “平等、自治” 和追求全栈能力的状态,违反 “共同为质量负责” 的原则。对于可以跨角色完成的工作,可以遵循自愿分工,按估算分配的模式。如果现阶段不希望在专业测试任务上花费太多精力,建议不在团队里安排全职的测试工程师,指派组织内的其他测试工程师参与技术评审和验收阶段把关即可。

最后,我们对敏捷测试的认知做一下纠偏:

所有敏捷理论中保护开发活动效能的道理,也适用于测试活动。
测试人员也会面临和开发人员一样的困扰:被频繁打扰、被浪费成果、被怀疑专业度、没有精力完成技术债。
测试活动的任务排期、估算、完成速率、优先级等,也是需要统一纳入敏捷规划中的。

因此,测试团队需要建立信任、自主、透明、共建的敏捷测试文化,真正融入到整个敏捷转型组织之中。


↙↙↙阅读原文可查看相关链接,并与作者交流