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

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

近期，TesterHome社区小道消息播客直播间邀请了鼎叔，与大家一同探讨了测试团队管理、敏捷转型等方面的内容。节目音频完整内容在“阅读全文”可以获得。

相关文章：聊聊如何理解“无测试组织”，聊聊鼎叔的新书《无测试组织-测试团队的敏捷转型》

敏捷和效能之间的关系

Q：我在想我们以前有敏捷开发，然后其实敏捷测试也是流行了一段时间，就目前整个市场或者说整个互联网公司里面，敏捷到底是怎样一个情况呢？那效能是不是也能直接等于敏捷呢，这个能帮忙解读一下吗？

A：首先，我先说一下，大家容易和敏捷混淆的一个词，叫做“效能”，因为我现在也是做效能负责人，那效能跟敏捷是什么关系，我觉得一个非常重要的概念是：先有敏捷的理念价值观和行为，然后效能只是敏捷效果的一种呈现。

那怎么样才能提高效能呢？我认为就是从各种情况来说，最大概率地拥抱敏捷理念、价值观和相应的做法的团队，提高效能的动作就是事半功倍。

所以我们有时候把它混淆起来说敏捷，好像做敏捷做效能是一回事，其实是你先真正的贯彻了敏捷，才能够真正把效能长期做好，或者说效能做好的概率要比不敏捷的团队高很多。这是我经过多年地思考这个概念，所得出的个人解读。

我也看过很多的团队，他们干的事情更多是纯工程视角，或者是老板导向，因为他没有真正拥抱敏捷的价值观、流程、方法论，那他做的这些工程只能起到短期的效果，就是一下子把指标叠上去，老板一看我砸人是对的，结果过了一两年团队离职，然后指标不但没有上升反而下降，然后团队最终解散，这种例子大家看到非常多。我认为其实最本质的失败，就是你并不是从敏捷的角度去修炼，而是直接从工程的角度强拉起来的一个效能平台。

那反过来说，当然你有了足够多的敏捷实践，最终作为软件团队当然会输出一些效能的度量工具与工具链等等，这是一个必然会输出的结果。但是不同的公司不同的focus，不同的成熟度，输出工程方面的效能成果的力度和节奏肯定是不一样的。

所以说，我觉得两者之间会有一个先后关系，效能的比重在整个敏捷体系当中，是浮动的，不是说我要拿出一个特别牛逼的效能平台才证明敏捷成功，所以这是一个误区，我也看到有的大公司一说做敏捷效能，然后就砸了很多人，去做很庞大的框架设计，很庞大很复杂的效能产品，这也是一个非常大的误区。

我觉得在做这个事情之前，你的主导的团队，骨干团队、架构师或者是owner，你要先深入地学习理解，深入地碰撞整个研发流程的敏捷观，你再去做这个工程项目的事情，这才会事半功倍，否则就是事倍功半。

敏捷无法被度量？

Q：关于度量，我们知道效能可以通过量化来衡量，但敏捷是否可以被量化呢？它看起来更加感性，没有明确的量化指标。敏捷是否意味着无法被度量？

A：敏捷当然是可以被度量的。虽然敏捷宣言中的表述更为感性，缺乏具体的量化元素，但这并不意味着无法量化。关于敏捷度量，我认为它甚至可以作为一个单独的话题进行深入讨论。

在我与很多技术高管沟通中，我发现效能走偏的最主要原因是脱离了人。工具虽然可以自动化抓取一些数据，但如果脱离了人的配合，工具的实际应用效果会很差。相反，如果首先研究人与人之间的关系，然后找到关键的度量指标，再从高层次逐步拆解到日常中间指标，效能的方法就更容易成功。

在敏捷转型中，量化是至关重要的。不管你之前说得多么激动人心，你来到一个新团队，你可能很牛，拥有丰富的经验，但如果最终效果无法量化并展示给团队领导，那你很可能会被视为无法产生实际效果的人。高层管理者需要看到敏捷转型的具体成果，而这些成果必须是可度量、客观的。

因此，我的观点是，首先要明确你要做什么，确保团队能够在这一过程中感到满意和舒适。一开始可能会有一些不适应，但随着时间的推移，团队会越来越适应，最终变得更加顺畅。这也是敏捷转型成功的标志。

成功的敏捷转型会带来核心指标的变化。如果你找不到这些核心指标或无法理解它们，可能说明你并不了解敏捷，只是在执行表面工作。因此，挑选合适的敏捷措施，并有匹配的衡量指标是关键的。在我的书中，我还将详细探讨度量指标的选择以及建立有效的度量体系的方法。一些看似全面而有趣的指标，如果不能从核心指标拆解出一个因果关系的方法论，就很难被高层管理者认可。

总的来说，正确的敏捷不会让团队变得越来越痛苦，相反，它会让团队越跑越快，每个人都能感到舒适。

为什么有些公司的敏捷转型会失败

Q：在敏捷测试中，特别是针对传统测试团队，如何进行敏捷转型？为什么有些公司在敏捷实践中失败？

A：首先很多公司的敏捷确实失败了，但是失败的很多原因，说句实话说一千道一万，但是终极原因就是：实施敏捷的团队的人尤其是带头人其实并不拥抱敏捷。

带头人并没有想正儿八经的去研究、理解、实践，而只是为了提高KPI的绩效就搞一把，搞完以后就撤。或者是得到我的想要的东西，后面我就懒得坚持。带头人没有把敏捷真正作为他言传身教的一部分，这才是最关键的核心。

当然背后还有很多因素，比如说是办公室政治，或者是有的团队实践了以后带来的效果影响到别的团队的口碑，就会有一些团队之间的负面的PK，就是不是很健康的竞争，导致了一些负面的评价，这都会有。

然而，不能因为一些团队失败就贬低敏捷，毕竟敏捷被广泛认可，并由许多软件工程大师推崇。正确的做法应该是理解敏捷的核心价值观，将其作为一种文化和方法论，而不仅仅是为了达到表面的绩效目标而应付。

那敏捷的三驾马车就是产品负责人、技术负责人、还有一个Scram master就是所谓的教练，但是测试团队往往被忽视了，所以为什么骂敏捷比较多的比例其实是测试团队的，是因为测试团队觉得我原来一个月发布一次我就很辛苦了，你现在双周就要发布一次，那我是不是更辛苦，问题老板说你辛苦的时候我也没有给我加班费，也没有允许我降低质量标准，我还是要测那么多东西，所以这就属于没有真正从意识上抬高大家的认知，以及方法论上并没有做相应的调整。

那这种怎么解决呢？解决这个问题的关键在于整个大团队的成功，必须有管理层的支持和敏捷弹性，同时测试团队要有深刻的敏捷理念，取得局部成功，提升个人水平，并影响他人对测试团队的看法。逐渐改变整个公司需要时间，但通过局部成功和口碑的提升，可以逐渐影响研发团队。

在敏捷转型中，管理层的认可和全员的动员至关重要。自上而下的转型需要制定详细的转型计划和执行一系列活动，并进行结果的复查。