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

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

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

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

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

接下来，本合辑针对主流的敏捷实践框架及其价值观做了核心知识回顾，包括Scrum、XP、用户故事、精益看板和大规模敏捷框架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如何在团队中修炼成员的心流。

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

结语：

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

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