扫码阅读
手机扫码阅读

聊聊团队如何开始敏捷转型(合辑共15篇)

49 2024-01-30

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

第五个文章专辑终于大功告成,这个专辑《团队如何开始敏捷转型》共有15篇文章,涵盖知识领域非常丰富。

本专辑先从敏捷理念的知识开始介绍,阐述了敏捷宣言和原则对于测试活动的启发,引出敏捷测试的定义。

为什么公司的敏捷转型会失败,为什么敏捷测试会失败?本专辑给出了观察到的主要现象和原因。接下来,引导测试团队对最突出的阻碍和风险进行自我诊断,通过集体脑暴对团队愿景、敏捷测试原则和关键举措达成共识,并持续付诸行动。

接下来,本合辑针对主流的敏捷实践框架及其价值观做了核心知识回顾,包括ScrumXP、用户故事、精益看板和大规模敏捷框架SAFe等,然后分别从测试视角详细分享了值得关注和尝试的敏捷措施。

测试人员全身心融入整个敏捷转型过程是非常关键的,从中可以获得传统测试理论缺失的知识,通过应对各种意想不到的问题,形成适合自己团队的敏捷新方法,最终打破当前能力域的瓶颈。

之前四个合辑可以回看,聊聊提升用户体验的评测方案(合辑共8篇)聊聊团队能力培养与创新氛围(合辑共17篇)聊聊探索式测试理论与实践(合辑共9篇)

Part 1 敏捷测试的定义

聊聊敏捷与敏捷测试

身处敏捷转型之中的测试团队往往陷入更加困惑的状态,一方面交付要快,另一方面质量兜底的挑战并未减少,使得测试人员身心俱疲,甚至成为转型中的消极角色。事实上,鼎叔认为,在转型成功的敏捷研发团队之中,测试人员应该会得到足够多的收益,在工作时应该会更加愉悦舒心。为什么会身心俱疲,问题究竟出在哪里?

那我们先从敏捷理念-敏捷宣言和敏捷原则,开始聊起,并从测试角色的角度理解它。

聊聊敏捷转型为什么容易失败

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

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

Part 2 团队的自我诊断

聊聊团队效能的自我诊断

理解了敏捷知识和失败原因,我们可以开始逐步诊断团队自身,通过集体脑爆,一起制定未来的转型目标。

打造敏捷团队,与打造成功的敏捷产品,有一定的相似性,团队成员对未来愿景能否达成共识,对如何到达愿景的主要措施能否达成共识,至关重要,这是指导未来具体交付行为的指南针。

基于鼎叔的亲身实践,本文将从团队管理者或者教练的角度,推荐一下自我诊断流程。

Part 3 敏捷常见实践框架及测试关注点

敏捷理论博大精深,相关实践方法论和工具层出不穷,各大公司都有特定的实践模式。敏捷实践方法的框架并不是精确的工具应用,而是一整套做法和纪律。

下面的系列文章会对主流的敏捷实践框架做简单的核心知识回顾,然后展开阐述测试人员应该如何支持敏捷落地,并从敏捷知识中汲取补齐自己短板的理论,消除以往的困惑,积极尝试新的敏捷方法,尤其要拉通非测试专业人员完成有价值的测试活动。

谨记,单靠专职测试人员自身的努力,无法让敏捷测试取得真正的成功。

一 Scrum

聊聊Scrum价值观与测试启发

我们先从普及程度最高的敏捷框架- Scrum开始聊起。

通过Scrum框架,人们可以解决一系列的自适应难题,同时也可以高效并创造性地交付最高价值的产品,它是建立在一系列价值观、原则和实践之上的,也是最成熟最普及的敏捷工具。

本文也将从测试角色和测试活动的角度,重新挖掘Scrum的精髓实践内容,以期得到更多的启发。

聊聊Scrum三大角色的质量意识和文化建设

本篇从Scrum的主要角色视角,来看怎么支持好质量内建活动,以及理解Scrum真正的价值,建立相应的团队文化。让我们看看优秀Scrum团队的样子。

聊聊每日站会

每日站会是一线敏捷团队自己的会议,快速同步成员为达成迭代目标所做出的贡献,并对有风险的阻碍采取行动,有利于提升每个成员对项目的认知程度。如果测试人员所在的项目团队没有组织每日站会,一线测试团队也可以自行组织,用很少的时间高效沟通,受益良多。

每日站会是Scrum框架中的重要活动,但也可以在任何非Scrum团队中实践。我们需要充分理解敏捷的站会为什么开,怎么开。

二 XP与TDD

聊聊测试驱动开发

软件缺陷通常是由低质量的代码引起的,但是在复杂项目中,要维护这些代码简直就是噩梦。新加入的开发者想对它进一步修改,更是举步维艰。测试驱动开发,或许能解决这个问题,利用测试构建出高维护性和满足客户需求的软件,它也是XP(极限编程)的核心实践。

我们常说的TDD,通常指细节层面的UTDD(单元测试驱动开发),以测试驱动的方式编写开发。行业还有一个概念- ATDD(验收测试驱动开发),指在较高层次(特性功能层),以测试驱动的方式构建系统。前者保证内部质量,后者保证可见的外部质量。

聊聊极限编程与测试启发

极限编程(Extreme Programming,XP)是由Kent Beck在1996年提出的一种软工工程方法学。XP作为最富有成效的方法学之一,相对于传统工程方法,更强调可适应性而不是可预测性。软件需求的不断变化是难以避免的,主动适应变化才是更加现实,更加具有竞争力的态度。

三 用户故事

聊聊用户故事与测试启发

用户故事的概念于1998年被正式提出,在2001年开始逐步成熟。目前,市面上有关讲解用户故事方法的著作不少,在Scrum流程中配合使用,效果显著。我们先回顾一下用户故事最核心的知识内容,再看对测试团队有哪些启发。

聊聊用户故事的估算和拆解

对于Scrum和用户故事实践的最大难点,我相信是如何估算用户故事的大小,如何拆解它?过大的用户故事会带来一系列的沟通复杂度和潜在质量风险,最好的用户故事是不超过2-3开发人日就能够完成的。本文重温行业经典的估算和拆解方法,并从测试人员的角度思考它。

四 精益看板

聊聊精益看板和测试启发

精益理论的核心是造物先造人,消除浪费和持续改善。每个员工都有机会发现自己工作方式的问题、解决问题和进行改进。我们通过减少不增值的浪费缩短交货时间(比如,从客户下订单到公司收到现金为止)。而缺陷其实是一种不必要的浪费,从精益理论中我们可获得不少测试启发。

五 大规模敏捷

聊聊大规模敏捷框架和测试启发

知名公司敏捷转型往往涉及大部门的所有员工,甚至跨多个部门一起进行敏捷开发,相关全职人力动辄50人以上,甚至高达数百人。因此我们有必要引入大规模敏捷实践框架,对于多个特性团队(8个以上,甚至数十个团队)联合研发,该如何协调,交付更高层次的价值呢?

下面基于行业普及率很高的大规模敏捷框架-SAFe,简单介绍一些基础知识,并分享鼎叔相关的测试感悟。

Part 4 敏捷团队的内功修炼

任何团队的敏捷实践要想真正获得成功,都依赖于组织和个人的能力,因此优秀的敏捷教练需要对理论、技术和人性都有相当深刻的认知。

聊聊敏捷实践的“个体与交互”

敏捷宣言有重要的一句话:个体和交互胜过过程和工具。作为工程师,我们眼里往往只有后者-过程和工具,因为通过它们能实现看得见的价值。可能因为我们大部分是计算机科学或软件相关专业,而“个体和交互”更多关注于心理学和行为学,导致这块是敏捷实践上最难以改进的“软”地方。

在鼎叔尝试在各个团队进入敏捷新举措时,具体流程方案和技术实现从来不是难题,难的是不同角色的心理防御和互动技巧,这确实需要不同维度的修炼。

聊聊敏捷教练领导力

教练术对于敏捷团队的核心角色,尤其是Scrum Master和TL,都是最重要的修炼能力。对于敏捷技术团队的leader,教练领导力更是提升领导口碑的关键实践型技能。前段时间参与了教练式领导力的培训和研讨沙龙,下面从敏捷团队中的领导者角度,来分享下研讨的收获及感悟。

聊聊“心流”的修炼

“心流”Flow,就是在工作/学习/生活中的一种高效忘我状态,这个过程能带来显著的幸福感和成就感。本文先介绍积极心理学的“心流”理论,来自Mihaly Csikszentmihali,再谈谈教练或leader如何在团队中修炼成员的心流。

本文尽可能摒弃鸡汤类观点论述,聚焦心流形成的本质和现实启发。

结语:

每个团队的专业度和境遇不同,对于敏捷测试的指导需求也不同。敏捷测试的工具箱非常丰富,在一段时期内并不需要同时展开实践,避免负担过大。

本公众号将陆续为大家提供不同细分领域的理论与实操方案,帮助测试团队走向更有生命力的敏捷组织形态。欢迎各位阅读后结合自身需求采取行动。

原文链接: http://mp.weixin.qq.com/s?__biz=MzkzMzI3NDYzNw==&mid=2247484346&idx=1&sn=479db5fece61937437a598c50565c886&chksm=c24fb6d8f5383fce28074877b5faa74b14b152093e656c007c6394a4b76b344a770a99480df8#rd

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

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