这是鼎叔的第七十六篇原创文章。行业大牛和刚毕业的小白，都可以进来聊聊。
欢迎关注本公众号《敏捷测试转型》，星标收藏，大量原创思考文章陆续推出。
鼎叔的个人专著《无测试组织 - 测试团队的敏捷转型》，https://item.jd.com/14105386.html 。已经正式上市，各大平台热销中，全书有 15 章，30 万字，350 页。本合辑部分内容对应本书的第一和第二章。
第五个文章专辑终于大功告成，这个专辑《团队如何开始敏捷转型》共有 15 篇文章，涵盖知识领域非常丰富。
本专辑先从敏捷理念的知识开始介绍，阐述了敏捷宣言和原则对于测试活动的启发，引出敏捷测试的定义。
为什么公司的敏捷转型会失败，为什么敏捷测试会失败？本专辑给出了观察到的主要现象和原因。接下来，引导测试团队对最突出的阻碍和风险进行自我诊断，通过集体脑暴对团队愿景、敏捷测试原则和关键举措达成共识，并持续付诸行动。
接下来，本合辑针对主流的敏捷实践框架及其价值观做了核心知识回顾，包括 Scrum、XP、用户故事、精益看板和大规模敏捷框架 SAFe 等，然后分别从测试视角详细分享了值得关注和尝试的敏捷措施。
测试人员全身心融入整个敏捷转型过程是非常关键的，从中可以获得传统测试理论缺失的知识，通过应对各种意想不到的问题，形成适合自己团队的敏捷新方法，最终打破当前能力域的瓶颈。
Part 1 敏捷测试的定义
聊聊敏捷与敏捷测试 https://mp.weixin.qq.com/s?__biz=MzkzMzI3NDYzNw==&mid=2247484212&idx=1&sn=7cd7632e56d59c7b8f6eb82f581f330d&chksm=c24fb656f5383f40a7322d1bf1334893b9979e5d42310fcc73547255a0d09c6d132b1a2fef27&scene=21#wechat_redirect
身处敏捷转型之中的测试团队往往陷入更加困惑的状态，一方面交付要快，另一方面质量兜底的挑战并未减少，使得测试人员身心俱疲，甚至成为转型中的消极角色。事实上，鼎叔认为，在转型成功的敏捷研发团队之中，测试人员应该会得到足够多的收益，在工作时应该会更加愉悦舒心。为什么会身心俱疲，问题究竟出在哪里？
那我们先从敏捷理念 - 敏捷宣言和敏捷原则，开始聊起，并从测试角色的角度理解它。
本文聊聊团队的敏捷转型为什么容易失败，以及澄清这个误解：敏捷测试就是自动化测试。
很多人把敏捷测试理解为自动化测试，我认为这个观点是非常狭隘的：自动化测试并不是帮助测试团队敏捷转型成功的银弹。
Part 2 团队的自我诊断
理解了敏捷知识和失败原因，我们可以开始逐步诊断团队自身，通过集体脑爆，一起制定未来的转型目标。
打造敏捷团队，与打造成功的敏捷产品，有一定的相似性，团队成员对未来愿景能否达成共识，对如何到达愿景的主要措施能否达成共识，至关重要，这是指导未来具体交付行为的指南针。
基于鼎叔的亲身实践，本文将从团队管理者或者教练的角度，推荐一下自我诊断流程。
Part 3 敏捷常见实践框架及测试关注点
敏捷理论博大精深，相关实践方法论和工具层出不穷，各大公司都有特定的实践模式。敏捷实践方法的框架并不是精确的工具应用，而是一整套做法和纪律。
下面的系列文章会对主流的敏捷实践框架做简单的核心知识回顾，然后展开阐述测试人员应该如何支持敏捷落地，并从敏捷知识中汲取补齐自己短板的理论，消除以往的困惑，积极尝试新的敏捷方法，尤其要拉通非测试专业人员完成有价值的测试活动。
谨记，单靠专职测试人员自身的努力，无法让敏捷测试取得真正的成功。
一 Scrum
我们先从普及程度最高的敏捷框架- Scrum 开始聊起。
通过 Scrum 框架，人们可以解决一系列的自适应难题，同时也可以高效并创造性地交付最高价值的产品，它是建立在一系列价值观、原则和实践之上的，也是最成熟最普及的敏捷工具。
本文也将从测试角色和测试活动的角度，重新挖掘 Scrum 的精髓实践内容，以期得到更多的启发。
聊聊 Scrum 三大角色的质量意识和文化建设 https://mp.weixin.qq.com/s?__biz=MzkzMzI3NDYzNw==&mid=2247484247&idx=1&sn=058d4f27ce2570f82f046ee7c3702fb2&chksm=c24fb635f5383f23562bf52ada7917d0050996467aae1f2a8f78d6c376ccc84883e96d0fa4e1&scene=21#wechat_redirect
本篇从 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 如何在团队中修炼成员的心流。
本文尽可能摒弃鸡汤类观点论述，聚焦心流形成的本质和现实启发。
结语：
每个团队的专业度和境遇不同，对于敏捷测试的指导需求也不同。敏捷测试的工具箱非常丰富，在一段时期内并不需要同时展开实践，避免负担过大。
本公众号将陆续为大家提供不同细分领域的理论与实操方案，帮助测试团队走向更有生命力的敏捷组织形态。欢迎各位阅读后结合自身需求采取行动。