扫码阅读
手机扫码阅读

聊聊效能与敏捷的差异

62 2024-01-30

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

敏捷和效能之间的关系

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

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

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

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

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

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

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

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

敏捷无法被度量?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

原文链接: http://mp.weixin.qq.com/s?__biz=MzkzMzI3NDYzNw==&mid=2247484429&idx=1&sn=7637ca3a575839be0559132eb7b4d85d&chksm=c24fb16ff5383879563b30966582d7a987299a6c0660166686697bad2d6de1db252790272dec#rd

《无测试组织-测试团队的敏捷转型》主题探讨。从打造测试的组织敏捷,到敏捷测试技术的丰富实践,从一线团队的视角来聊聊我们是怎么做的。面向未来,拥抱敏捷原则,走向高效能组织。

81 篇文章
浏览 5384
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设 白皮书上线