下载掌阅APP，畅读海量书库
立即打开
敏捷理论博大精深，相关实践方法论和工具层出不穷，各大公司都有特定的实践模式。敏捷实践框架并不是精确的工具应用，而是一整套做法和纪律。它能否真正获得成功，强依赖于组织和个人的能力，因此优秀的敏捷教练需要对理论、技术和人性都有相当深刻的认知。
本章会对主流的敏捷实践框架做简单的核心知识回顾，然后展开阐述测试人员应该如何支持敏捷落地，并从敏捷知识中汲取补齐自己短板的理论，消除以往的困惑，积极尝试新的敏捷方法，尤其要拉通非测试专业人员完成有价值的测试活动。
谨记， 单靠专职测试人员自身的努力，无法让敏捷测试取得真正的成功 。
Scrum的概念由日本教授在1986年提出，其框架在1995年公开发布，并在2001年成立了Scrum联盟。通过Scrum框架，人们可以解决一系列的自适应难题，也可以高效并创造性地交付最高价值的产品，它是建立在一系列价值观、原则和实践之上的。据统计，约有70%做敏捷转型的软件团队在采用Scrum框架，它是最成熟、最普及的敏捷工具。
一个典型的Scrum框架如图2-1所示。
图2-1 Scrum框架
Scrum基于经验主义，采用迭代（Iterative）开发模式，逐步把粗糙的想法变成现实。根据产品特征和业务特性的不同，可以选用不同的迭代周期和发布节奏。Scrum的核心原则是 检查、调整和透明 ，工作框架简称 3355。
❑ 3个角色（Role） ：包括产品负责人（Product Owner，PO）、敏捷教练（Scrum Master，SM）、自组织团队负责人（Team Leader，LT）。
❑ 3个工件（Artifact） ：包括产品待办列表（Product Backlog）、迭代待办列表（Sprint Backlog）、产品增量（Product Increment）。
❑ 5个活动（Workflow） ：包括迭代梳理会（Sprint Refinement）、迭代计划会（Sprint Planning）、每日站会（Daily Scrum Meeting）、迭代评审会（Sprint Review）、迭代回顾会（Sprint Retrospective）。
❑ 5个价值观（Value） ：包括承诺（Commitment）、专注（Focus）、尊重（Respect）、开放（Openness）、勇气（Courage）。
Scrum的理论知识丰富，相关经典图书很多，本书就不全面展开，读者可以自行学习。
下面仅从测试角色和测试活动的角度（注意： 负责测试活动的角色不一定是测试工程师，也可以是开发或产品经理等 ），重新挖掘Scrum的精髓实践内容，以期得到更多的启发。
测试团队的负责人或教练，尤其要对这些启发内容多上心，检视有哪些支持和改进项可以逐个落地。
把敏捷理念积极融入测试工作中，本质上就是 既要高质量，也要高效率 。而这样的转变趋势也让团队更融洽，更有激情，形成正向循环。
尊重：团队成员互相尊重，彼此独立，有核心能力
貌似无比正确的“偏虚”价值观，在坦诚的自我检视下，其实能发现不少典型的负面行为。
（1）检视独立性
测试活动交付能否个人独立进行？ 我最常见到的反模式是把测试任务拆解为用例设计、测试执行、自动化脚本执行、测试项目管理这四项工作，由测试部门的四个细分角色去完成，最后由测试项目经理总结并汇报。
对于合适大小的被测模块，显然一个人完成以上四项工作是效率最高的，对于需求理解和用例设计，思路也能够得到贯通。不同的测试角色分工承担，彼此依赖对方的知识和产出，容易产生严重的依赖等待，每个人的专业水平提升也会非常慢。
如果测试范围太大，需要多个测试人员怎么办？ 按特性完成测试交付 自然是最佳分工方案，因为特性就是相对独立的可验证价值的用户需求。
注意：可以把同类技术债的验收测试交给技术比较强的测试人员独立把控。
（2）检视尊重氛围
测试团队内的管理、测试和其他角色的协作，是否体现了不被尊重的态度？
如果有明显的负面氛围，教练/测试主管就需要进行分析和尝试改进，只有在积极情绪下才能更好地激发个人效能。
1）对测试新人和驻场外包测试人员，分配工作时可以有不同的难度和趣味程度，但要多倾听他们的心声，并引导他们通过努力带来变化。切忌不要有“默认没有技术含量的工作都是你的”这种表达，而是多询问：如果你觉得手上的工作简单了，你希望承接什么难度的新任务，需要什么培训？如果你觉得经常测试的内容太简单、重复，你希望尝试什么自动化的方案？
2）项目团队对于测试的分工定位，是否有非测试领域的“杂活”过度分派给测试人员，并引发不满的情况？
敏捷团队的文化体现在个体勇于承担边界任务，我们也鼓励测试人员多承担边界工作，哪怕烦琐，只要是有必要性的，对于测试口碑就有正向作用。但是如果形成“不需要写代码的杂活就给测试干”这类分工逻辑就不太合适了，它会影响测试人员本身的专业发展，比如让测试人员长期做用户投诉反馈的处理工作，或者负责所有版本发布流程保障等。
敏捷组织不鼓励为每一类细分专业岗位都招聘一个全职人力，在没有专业人士支援的情况下，对于暂时无法自动化的枯燥手工任务，有必要根据团队成员的自愿度进行任务分配，或者轮流承担边界任务，这也有利于成员彼此学习，共同为交付负责。
（3）检视核心能力
测试工程师本质上应该有专业门槛，测试主管应确保进入敏捷团队的专职测试人员是有专业核心能力的，这样才能获得敏捷团队的充分信任。如果测试工程师专业资质很弱，就很容易陷入上述“不尊重测试”的反模式。
测试主管和架构师有义务对测试工程师进行核心能力的持续培训和赋能，详细内容可以参考本书第6章内容。慎重选择分配到敏捷特性团队的成员，如果不能胜任，可以采取更换派驻骨干的行动，或者可以通过团队发起验收测试任务来保障要交付的基础质量。
专注和承诺：聚焦Sprint工作和Scrum团队目标
常见的反模式：
1）敏捷特性团队中的测试人员并不是专职人员，他还兼顾其他数个团队的测试角色。
2）虽然是全职测试人员，但是经常被来自其他团队或者自己上司的临时任务打断。
不专注的结果就是承诺的测试交付无法达成，理由还理直气壮：我还有更重要的事情要做。这类反模式对测试人员在敏捷团队的口碑有明显伤害。
测试主管和教练请注意：
1）如果必须给敏捷特性团队分派测试人力，但人数不够全职分派，那就一定要约定投入百分比（建议不低于50%），在分派任务的估算中给予相应考虑，派驻特性团队的人员要做到在核心会议中认真参与和沟通。
2）度量测试人员被非迭代任务打断的次数和花费的时间，如果数据严重应该进行干预，采取保护测试人员不被打扰的行动。
此外，测试人员自身也要注意，既要基于合理估算承诺本迭代要完成的目标范围，也要面向团队中长期目标思考工作的优先级，预留一定的排期时间，不要只顾完成眼前的迭代任务，不去思考为长期的质量或效率提升应该做什么事，这些事通常重要但不紧急。
开放：Scrum团队和干系人同意将所有工作和执行上的挑战公开
对于测试人员而言，开放意味着信息透明化，有困惑就提出来商量解决。
常见的反模式：
1）与敏捷业务、目标有关的会议没有邀请测试人员参加。没有提供测试工作需要的产品信息和技术文档，或者需要特别申请访问权限。
2）产品需求变更没有及时知会测试人员，或者没有主动同步背后的变更原因。
3）随意压缩测试执行时间，但并没有商讨改变测试范围和优先级。后继的迭代中也没有改进动作。
4）测试人员不关心其他岗位人员的工作内容及其重要关切，其他岗位人员也不关心测试人员具体在做哪些技术建设，只要及时完成测试报告就行。
5）团队没有针对质量讨论的氛围，评审完需求和发布时间就结束了，没有预留时间讨论交付质量风险和用户投诉的相关内容。
开放也是双向的，一方面测试人员要主动展示测试各项进展工作，阐述该项工作对业务的价值，另一方面特性团队其他成员也需要公开同步项目关键信息，尊重测试专业意见。要保证各角色都可以轻松获取项目内的所有信息知识，随时看到整个项目的运行进展。
勇气：做正确的事，并处理那些棘手的问题
针对项目进展的风险，以及团队协作的不良关系，测试人员要敢于暴露。
常见的反模式是：测试人员暴露的严重风险被掩盖（不让上级知晓），不通过的测试结论被软磨硬泡地通过，质量事故的责任确认不清。
大家通过开诚布公的商讨，共同承担可能的质量代价（明显违反原则纪律的情况除外），而不是孤立勇于曝光风险的人。困难的问题需要集体合作分担。可以将复杂问题拆解为一个个更简单的问题，按迭代完成，但推迟是解决不了问题的，只会积累更严重的风险。
把复杂的规则可视化、简单化，是鼓励勇气价值观的好窍门。
提升勇气，既可以让团队更加彼此信赖，又可以对自己的专业挑战充满斗志。
充分思考了核心价值观对于测试的启发之后，对于Scrum角色应该各自关注什么测试活动，答案就呼之欲出了。
本节从Scrum的三个主要角色的职责出发，思考哪些活动能有效帮助团队提高产品交付质量和全员质量意识。
PO应关注的测试活动
1）确认产品需求优先级的背后“故事”，是否已同步给测试人员。
需求优先级由PO最终拍板，PO实际上掌握了众多确定优先级的信息以及决策的思考逻辑，这些信息如果能清晰地传递给测试人员，那么对于测试分析和制定策略也会非常有帮助。
2）确保业务产品信息对技术团队能及时更新、合理归档。
尽可能减少由于产品信息没有对齐带来的无效开发和无效测试。有一部分产品反馈信息（包括埋点行为数据）是上市后才能获得的，有一部分信息是客户单独传递的，它们对于测试人员优化测试覆盖策略可能非常有帮助，PO应该保障好这些数据的内部共享。
同时，针对测试人员的质量反馈，PO应判断是否体现了产品设计的不合理，是否有必要作为品质改进需求加入产品代办列表。
3）传递产品愿景和关键词。
虽然愿景对于工程师个体而言很抽象，但是如果团队对产品的未来充满信心，对于产品的独特价值主张能达成共识，那么测试人员就能够从关键词中聚焦质量提升方向，提炼高优先级的确认标准。
SM应关注的测试活动
1）是否有意识地组织质量内建活动，将其固化为好的团队习惯。
如果SM对于质量内建活动不够关注，测试角色可以多加提醒。这些活动包括但不限于：DoR（需求准备好进入开发的标准）和DoD（需求完成开发的标准）中的质量达成纪律、桌面评审（Deskcheck）活动、代码质量评审和用例评审、确认验收测试、发布前的集体缺陷大扫除等。
2）是否能识别测试角色遇到的阻塞、打扰和依赖，并尽快协助处理。
帮忙各个角色（包括测试）搞定上述困难是SM的最核心职责，针对测试角色的干扰有来自领导的与迭代无关的需求、非本项目的任务、测试环境和工具的阻塞、阻塞级缺陷（导致其他测试内容无法执行）。SM一旦判断这些干扰阻塞了工作开展，当天就应商讨对策并尽快解决。
3）是否维护了尊重测试结论、鼓励测试新技术实践的研发氛围。
SM的重要义务是让团队处于互信和尊重的氛围，充满自管理的激情。警惕迫于发布的压力，逼迫测试人员修改测试结论和掩盖风险的现象。如果能够把启发创新的方法引入团队的测试活动中，那就能激发更长久的价值。
团队的知识归档和刷新也是SM的关注重点，其中质量知识和测试技能也占有一席之地。
4）是否在迭代结束后，度量过程质量数据，选择最重要的短板进行持续改进。
有始有终，在迭代结束后召开回顾会议，SM需要让大家对过程质量数据和发布质量进行分析，给出的改进措施一定要以预防为优先，明确下个迭代的改进动作是什么。
TL应关注的测试活动
1）关注测试技术债的偿还。
TL作为技术领导者，在参与了产品规划会后，一定要尽早识别包括测试效能在内的技术债（可以通过缺陷趋势、代码评审报告、静态扫描结果、架构性问题等数据来判断），制定偿还技术债的方案，鼓励开发人员同测试人员一起共建高效的自动化测试工具链，并对工具链选型做决策。
消除测试技术债的成果可能是一个工具，如果开发人员也是该工具用户，可以邀请开发人员做验收测试。
TL需和PO达成共识，在迭代排期中充分考虑预留测试技术债的偿还时间，持续偿还，而不是发现问题严重的时候才仓促做一波。
2）在技术层面把控好质量内建。
质量内建如此重要，需要SM和TL一同承担，SM负责组织和氛围建设，TL负责技术上的把关，包括：
❑组织团队解决疑难问题，完成根因分析，主导修复架构设计上的隐患。
❑评审测试策略，督促持续集成的卡点纪律，组织代码审查和落实代码规范，帮助开发人员养成良好的编码习惯，出现流水线构建问题能确保有人第一时间响应。
3）明确质量保障的投入重心。
TL应该帮助测试人员改进测试方法，参与测试策略和自动化测试方案的评审，回顾迭代过程，优化当前的测试资源投入。
极限编程（Extreme Programming，XP）是由Kent Beck在1996年提出的一种软工工程方法学。XP作为最富有成效的方法学之一，相对于传统工程方法，更强调可适应性而不是可预测性。软件需求的不断变化是可避免的，主动适应变化才是更加现实、更加具有竞争力的态度。
极限编程的价值观与核心实践
XP的基础价值观是加强交流、从简单做起、寻求反馈和勇于实事求是。它采用近似螺旋式的轻量级开发方法，把复杂开发过程分解为一个个相对简单的小周期，帮助客户清楚地了解开发进度和待解决的问题，并及时调整。
XP要求遵循的13条核心实践是团队协作（Whole Team）、规划游戏（the Planning Game）、结对编程（Pair Programming）、测试驱动开发（Testing-Driven Development）、重构（Refactoring）、简单设计（Simple Design）、代码集体所有权（Collective Code Ownership）、持续集成（Continuous Integration）、客户测试（Customer Test）、小型发布（Small Release）、40h工作制（40-hour Week）、编码规范（Code Standard）和系统隐喻（System Metaphor），如图2-2所示。
图2-2 XP核心实践
XP推崇开放式的工作环境，把客户卷入开发队伍之中，强调频繁测试不断整合的价值，希望尽早交付简单产品给用户以获得反馈。XP方法比较适合小团队的开发实践。
更多详细内容，读者可以参阅Kent Beck和Cynthia Andres的《解析极限编程——拥抱变化》。
测试启发
1） 让业务代表或用户代表加入各类测试活动中，越早越好。
充分利用有代表性的客户，帮助我们明确需求的质量要求及优先级，参与早期版本验收测试（尤其是MVP版本，即最小可行产品的版本），尽快反馈能代表用户声音的质量问题。
通过积极的交流，让客户代表非常清楚开发的进度、风险、待解决的质量问题以及背后的困难，同时开发团队也能及时响应商业变化，避免投资浪费。
2） 共享代码所有权。
有些团队比较抵触测试人员获得代码权限，甚至以安全为理由拒绝权限申请。我倾向于支持专职测试人员获得和开发人员相同的代码权限，至少获得阅读和本地编译权限，便于测试人员进行代码理解、精准测试、尝试定位问题等。测试人员有机会和开发人员在同等的信息源上进行技术对话，甚至直接针对代码质量进行规范检查。
3） 可持续的工作投入。
不要长时间加班（工作时间超过40h/周）。据我观察，一些加班严重的团队效率并不高，加班必要性不强，而每天真正高效的工作时间远远低于8h，很多时间都被浪费或者拖延掉了。管理者也常陷入只看工时不看效率的低水平管理模式。
可持续的稳定工作时间，才能形成稳定的迭代会议节奏和准确的工作量估算。企业管理者要寄希望于法定工作时间内的稳定效率。
因此，如果出现大量加班现象，管理者和客户可以一起确定加班的原因，及时采取缓解措施，进行项目进度和资源的调整。
4） 开放的工作空间。
最好所有人在一个开放的空间办公（可以有一些小隔间做私人沟通用途），墙上有大白板用于粘贴各种重要的提醒卡片，列出团队共同的目标和愿景，团队成员随时可以在白板上进行涂写讨论，甚至可以一起在休息间吃茶点交流。
5） 测试驱动开发（TDD）。
XP将单元测试结合到它独特的螺旋式增量型开发过程中，鼓励开发人员先写验收测试通过的代码，再不断补充和重构代码内容，删除冗余代码，并努力保证测试代码顺利通过。这些测试代码就形成了保障质量内建的安全网，同时确保了开发设计从简单开始演进，尽可能避免冗余设计。
对于测试人员，学习TDD的代码可以更好地理解开发人员的设计过程，以及单元测试的完成质量，同时可以把相关测试代码高频率地用于回归测试。
6） 结对编程对质量有什么好处。
结对编程是XP实践中争议最大的一点，实施效果参差不齐。由于个人隐私空间被打破，第一次尝试结对编程的开发者通常不太适应，需要管理者加以推动。而且长时间结对很难保障，每天的结对时间通常建议控制在4h以内。
从个人产出效率来说，结对编程并没有明显的优势，开始时甚至是下降的（因为同时要占用两个开发人员），随着配合越来越默契，结对编程的效率会提升。
但是从设计质量和代码质量角度来评估，结对编程效益明显，因为一个人员在主导编码时，另一个人会对他的设计思路、代码规范、测试质量做评估，及时指出大部分的初级问题。同理，我们也鼓励测试人员和开发人员一起实践结对编程。
用户故事的概念于1998年被正式提出，在2001年开始逐步成熟。目前，市面上有关讲解用户故事方法的著作不少，在Scrum流程中配合使用，效果显著。我们先回顾一下用户故事最核心的知识内容。
用户故事核心知识内容
用户故事用来描述对用户有价值的特性或功能，相对于传统的需求规格说明书，它用简化的形式促进团队交流，降低修改的成本，能灵活地调整以响应变化。通过用户故事的验收标准驱动，让所有敏捷团队成员和干系人，对最终目标达成共识。
用户故事的描述格式通常为： As （特定的用户）， I want （具体场景下实现的某个功能）， So that （获得某种目的/价值）。
用户故事要符合3C原则： Card （卡片，一句话概述内容，能让成员快速识别）， Conversation （通过产品和技术的直接对话，了解背后的需求细节）， Confirmation （验收条件，确保清晰无歧义）。
用户故事也要符合INVEST原则： Independent （彼此独立，相互间松散耦合，尽量减少依赖）， Negotiable （用户故事可以协商，不是一成不变的，需要PO和成员以及客户的坦诚交流）， Valuable （能体现对客户的明确价值）， Estimable （能够被开发团队合理估算的）， Size Appropriately （大小合适，能够在迭代中完成，如果偏大则需要拆解）， Testable （故事有明确无歧义的验收条件，能被明确客观的测试用例验证）。
用户故事从大到小，可以分为 Epic （史诗故事，需求梳理阶段时的宏大目标）， Feature （特性故事，迭代规划的重点目标）， User Story （用户故事，迭代中要完成的具体价值点）。注意，也有些敏捷图书把Epic的规模放在Feature之下，本书采用的是大规模敏捷框架的定义，认为Epic规模更大。
当用户故事太大，我们可以用各种手段进行拆分，但要确保拆分的每个用户故事都有其价值，并可以独立验收。拆分方法包括按工作流步骤拆分，按业务规则拆分，按先简单后复杂或先主线后支线的功能拆分，按探针（即先做调研工作）拆分等。
在对用户故事大小进行估算时，通常采用集体评估的方式，只做相对大小的评估，可参考斐波那契数列，也可利用扑克牌和T恤尺寸等方法进行估算，便于大家对于需求背后的价值和复杂度形成共识。
推荐学习书目：Mike Cohn的《用户故事与敏捷方法》，Jeff Patton的《用户故事地图》。
测试启发
1） 所有用户故事的验收标准是否明确，团队是否对验收测试用例达成一致？
验收标准通常写成GWT的格式：
❑ Given （什么场景或条件下，如在首页新闻的搜索框）
❑ When （采取了什么行动，如输入了品牌关键词）
❑ Then （得到了什么结果，如输出了该品牌直接相关的热门新闻，可以浏览点击）
验收标准可以避免团队成员对需求理解的偏差，帮助测试人员快速掌握测试范围。但验收标准不是验收测试，验收标准定义了用户故事完成的标准，验收测试要基于验收标准，但是验证的具体场景更广，建议每个用户故事验收的测试用例不超过6个。
特性团队对具体的验收测试用例达成一致，最大限度上保障开发人员能更好地进行验收测试驱动开发，这样交付的初版质量也会更高，更容易一次性通过验收。甚至在整个迭代的活动中，验收测试用例都可以作为团队统一的沟通语言，降低不同角色对需求理解的不一致性。
注意：验收测试用例不等于完整的测试设计用例，它通常仅仅是完整用例集的子集，优先级很高。
2） 所有用户故事是否具备可测性？
我们能否明确测试它们的工具方法以及判断测试通过的指标？如有疑问，需要在评审中和文档中获得澄清。
特别要注意需求描述中不清晰的定义，比如性能要增加50%（具体什么场景，什么指标？），安全性要提升（具体哪一项产品规格的安全性，要通过什么工具的安全检查？）。
3） 用户故事估算排期，必须考虑测试完成任务的耗时。
用户故事在迭代中达到“完成”的定义，是必须包含“相应测试任务完成”的。所以在估算时要纳入相应的开发自测和专业测试时间。
针对被拆解的用户故事，我们也需要在迭代中对测试工作量做好评估。故事被拆解后，有利于更加精准地评估测试工作量。从故事验收及回归测试的经验来看，开发工作量在2～3人天的用户故事，其测试验收的效率是最高的，可以在收到版本的当天完成用例集测试反馈，便于开发人员快速修复问题。
如果评估出来的测试任务人手不足，需要采取一定的补救措施，如安排开发人员支持测试、降低非核心功能用例覆盖等。
项目经理需要关注迭代中的工作燃尽图，分析是什么原因导致计划中的测试任务完成过程不太符合预期，比如，测试任务为什么迟迟没有开始，前期测试进程为什么被阻塞，测试工作量估算明显和实际不符合，等等。这个分析过程对于未来的测试速率估算准确性以及提高人员效率，将大有裨益。迭代工作燃尽图如图2-3所示。
图2-3 迭代工作燃尽图
针对客户端版本和重要服务的重构版本，正式发布的准备成本比较高，风险也比较高。我们通常会预留一个迭代做发布前的准备，包含缺陷修复和集中的系统测试投入，如兼容测试、回归测试和核心指标性能测试等。对于这个迭代，建议尽量不安排新功能的开发和测试。
4） 测试技术故事要能识别，合理排期和聪明地拆解。
测试技术故事通常是重要但不紧急的事项，而且不太好通过用户视角来描述其价值和验收标准，因此很容易被PO和团队忽略。测试人员需要主动澄清这个故事对特性团队的长期收益，越早还债，收益越大。
比如，基本接口的自动化测试覆盖，引入更好的性能测试工具和漏洞扫描工具，给看板增加质量告警等。测试技术故事也需要每个迭代能看到具体的成果，避免团队对未来的故事排期失去耐心。
有读者可能会问，有些技术需求很难估算到底需要多少时间完成，怎么办？那我们就用 探针法 拆解它：当前这个迭代只安排该需求的调研分析（我们称之为探针需求），输出关键结论报告，例如技术背景、行业案例、建议的实现方案及其风险等，下个迭代再根据调研结论进行一定开发工作量的技术故事实现。
精益理论来自于20世纪50年代的丰田精益生产方式，在大野耐一的领导下，丰田汽车生产效益迎头赶上了美国同行，相关理论也在世界范围内引发学习热潮。
精益理论的核心是造物先造人，消除浪费和持续改善。每个员工都有机会发现、改进并解决自己工作方式的问题。例如，我们通过减少不增值的浪费缩短交货时间（从客户下订单到公司收到现金为止）。
2009年，精益思想屋由Craig Larman和Bas Vodde提出。它强调管理者使用并教授精益思想，以此哲学思考方法为基础做出工作决策。精益思想屋有四根支柱，如图2-4所示。第一根是尊重他人与团队协作；第二根是持续改善（日文是Kaizen），走进实际工作地来观察，拒绝所有不创造价值的浪费，挑战完美；第三根是流动，为了让价值快速流动起来（价值流），我们需要根据价值来驱动生产，借助可视化看板（Kanban）进行JIT（Just In Time，刚刚好）的小批量生产；最后一根是创新，精益创新模式认为用户痛点和解决方案在本质上是未知的，无法完美预测，需要不断通过验证和迭代，找到真实的痛点和有效的解决方案，因此精益创新的本质就是创造价值。
图2-4 精益思想屋
那精益思想和敏捷理念有什么联系和区别呢？两者是互相渗透和借鉴的关系。精益理论产生的时间更早，在传统制造行业发挥了巨大的作用，给软件行业的敏捷先行者也带来了极大的启发，因此敏捷实践中会大量融入精益的工具、原则和方法。尤其是看板方法深入人心，几乎是敏捷特性团队的必备工具。两者在对员工的充分信任和尊重上的价值观是高度一致的。
但是两者也有本质的不同，如敏捷强调自组织团队，可以依靠个人克服挑战并持续改进；精益强调领导者要具备洞察问题的能力，相信领导者可以带领团队走进新阶段。两者的组织风格差异并无优劣之分。
具体到精益看板方法和Scrum框架，两者也有差异。看板方法没有指明三架马车这类关键角色，也没有固定的迭代周期这种时间盒（Time-Box）的概念；而Scrum框架没有强调在制品数量方面的限制，而是通过估算价值和工作量大小来排期。看板用前置时间（Lead Time）来度量交付效率，而Scrum框架通过“迭代速率”来度量交付效率。
测试启发
1） 优先注重员工的能力发展，探索工作的意义，并经常实地查看。
对员工信任和尊重的态度只是基础，当新时代的年轻人涌入职场，管理者有义务帮助他们揭示测试岗位发展的价值，以及他们所做的工作对用户的价值。理解了所挑战目标的意义，才能更好地调动积极性。
比如，我们为什么对某些用户场景投入大量测试心力，它给业务成功带来多大的成功推力？我们过往的工作得到了哪些用户的真挚认可和反馈？
与此同时，管理者是否对下属的能力发展创造了足够多的实践机会？员工在努力奋斗时，管理者是否有适度的观察和现场指导，还是永远只有几条感谢的消息或邮件？这都是会让领导者更受员工爱戴的重要表现，也是从源头发现可改进之处的高效习惯。
重复那句话，能力发展是敏捷转型三大成功要素中的第一要素。本书第6章还会针对测试工程师能力发展这个话题深入展开分享。
2） 建立价值流视图，控制在制品数量。
价值流视图对整个敏捷团队的日常提效、改进非常有用，自然也对各种测试任务有指引作用。我们把研发测试的整个过程拆解为关键的子阶段，度量各个阶段执行耗时和跨阶段的等待耗时，就可以发现真正低效的地方。
健康的流动速度会让团队有和谐感和成就感。我们重点强调以下注意事项： 小批量、不间断。
如果测试任务估算动辄超过一周，那么我们发现风险的时间就会推迟，改善动作也难以做到精细化。当然测试任务的小批量也依赖用户故事的合理拆解。小步快跑（小测试、天天测）才是健康状态，而不是大步走走停停。由于测试任务可以按用例优先级和测试类型分类，拆解为小批量任务的方法是非常多样的。
在制品（Work in Progress，WIP）数量，在测试阶段是指进入“ 待测试 ”状态和“ 测试中 ”状态的任务数量，它只有低于一个限制值，才能不对需求交付吞吐量带来风险。如图2-5所示，处于“测试中”的任务卡片不能超过3个，否则就会产生瓶颈风险。
图2-5 在制品数量
大于限制值，说明测试人员工作过载。当在制品数量明显异常时，整个团队都有必要停下来，看看什么地方出了问题，什么环节导致测试阶段的在制品数量异常，然后采取改进措施。注意，测试阶段发生任务过载的根本原因不一定与测试环节或者测试人员有关，团队要认真回溯分析。
这也就是著名的丰田精益管理“ 安灯绳 ”实践，流水线中的任何员工发现异常，都可以拉绳停止流水线，然后召集大家聚过来以集体解决问题。这与软件DevOps流水线的管理机制何其相似！
3） 总结常见浪费现象，形成团队敏锐度。
任何不增值的活动，都属于浪费，我们可以列举下面6种典型浪费现象，让团队组织研讨，重点实施清除，大部分浪费现象和Scrum实践要避免的反模式是一致的。
❑ 库存 。这包括尚未完成测试，无法进入可发布状态的所有功能。虽然我们为它付出了大量心力，但是它依然不能随时发布给用户。与其做一堆当前不能发布的功能，不如集中力量保障少数急需功能的发布质量。
❑ 过度测试 。用户不会为过度设计的功能买单。针对过度设计的功能，我们要质疑或者降低测试优先级。对于纳入迭代的特性，由于测试的不可穷尽性，我们也不要过度测试，而是要在有限的精力和拦截严重问题的概率上做好平衡。
❑ 频繁任务交接 。通常切换任务时会带来30%以上的效率损耗。一鼓作气沉浸在心流状态中是效率极高的。按照研发工作流程，确实存在测试与其他角色频繁交接的情况，这时需要多思考减少交接频率和成本的方法。同理，短期项目中测试人员之间的任务交接也应尽量避免。
❑ 多任务并行 。管理者可能认为多任务并行会让员工产生更多的价值，其实这是一个误区，三心二意难以产生高质量的结果，只有真正完成了一个任务才能让价值流往下走。否则各个任务的价值流都会形成阻塞。
❑ 等待 。前面也多次提到，等待不仅不会产生价值，还会降低士气，松懈情绪。对于经常的等待情况，极其有必要做分析改进。
❑ 缺陷 。缺陷属于不必要的浪费，而且可能耗费研发团队巨大的精力。减少缺陷的数量和严重程度，一定是向价值流的上游去推动改进。测试活动左移实践能尽快把缺陷消灭在萌芽之中。
4） 看板的泳道技巧。
我们在敏捷实践中经常会遇到一类难题，一方面要不断开发新需求上线，满足既定目标，另一方面，有些突发的重要工作也是要随时处理的，比如上个版本的缺陷紧急修复。我们如何利用看板的可视化，清晰地管理分工，保证两类工作的价值流都能顺利进行，又不互相影响？
横向切分的泳道就可以帮我们实现这一点。我们把新版本的开发/测试任务卡片放在上面的泳道（宽度约占70%）进行价值流的拉通，代表占当前总工作量的70%左右，再把老版本的缺陷修复/升级维护等工作任务卡放在下面的泳道，宽度约占30%，暗示这类工作量占比约30%（工作量没有这么多的话，优先去完成上面的70%主泳道工作），如图2-6所示。
图2-6 看板的泳道
同理，我们还可以为其他类型的重要技术债准备特定的泳道，比如给专项系统测试（性能、安全等）预留一定比例的泳道空间。
5） 不要把有空闲的测试人员的时间填满。
从看板卡片或者价值流视图来看，管理者经常可以发现有些测试人员在特定时间是比较闲的，于是很有冲动去增加他的任务以填满工作时间，提高团队总效能。这实际上不是好的做法。团队效能还是要看完成需求的吞吐率，与个人空闲与否关系不大。如果刻意让干活快的人显得更忙，就会引发他故意磨洋工的心态，还不如鼓励他利用空闲时间做感兴趣的专业学习。
上面几节的敏捷实践介绍都是以单个团队（独立交付特性的敏捷团队）的视角来描述过程的，这样的团队人数通常是5～9人，建议最多不超过15人。但实际上，知名公司敏捷转型往往涉及大部门的所有员工，甚至跨多个部门，相关全职人力动辄50人以上，甚至高达数百人。因此我们有必要引入大规模敏捷实践框架。对于多个特性团队（8个以上，甚至数十个团队）的联合研发，该如何协调、交付更高层次的价值呢？下面基于行业普及率很高的大规模敏捷框架——SAFe，简单介绍一些基础知识。
SAFe（Scaled Agile Framework）是应用于大型企业的敏捷实践框架，已在众多世界500强公司中实施并获得成功，能够大幅提升生产率、质量和员工满意度，目前该框架已经迭代到5.1版本。
之前介绍的Scrum主要从一线特性团队的视角来阐述具体的工作流程和原则，SAFe则对更高层次的大团队视角进行了拓展，包括项目集层面和项目组合层面。
项目集层面
项目集团队，管理一定数量的敏捷小团队，完成更大的企业目标，向客户交付完整的大型产品、系统或服务套件。相对于小团队敏捷，项目集面临更多的组织挑战，包括愿景和路线图的维护，管理多团队的发布节奏，保障定期集成的质量，清除小团队无法控制的阻碍，面向终端用户部署整个系统，等等。
在项目集团队中，单个敏捷小团队可以分为特性团队（对特性独立交付负责）、组件团队（专门提供某一类架构能力，支撑特性团队的专项团队）。此外，项目集团队还要设立一个系统团队和一个发布管理团队。前者负责项目集全局的系统测试、系统持续集成和开发基础设施。后者负责发布治理权限，面向终端用户交付高质量的解决方案。
为了确保多个团队交付功能的同步，项目集定义了ART（版本发布火车机制），以固定的时间频率（通常是2～3个月）完成一个可发布的增量内容（PSI）。多个敏捷小团队在每个PSI周期之初都要进行一次联合会议，制定PSI的发布计划，澄清各团队彼此的依赖关系和风险，并记录行动措施，更新整个项目集团队的路线图。
项目组合层面
对于更高的企业视角，驱动的技术团队动辄数百人甚至上千人，那就需要定义产品主题（也称投资主题），即能带来差异化市场竞争力的产品/服务价值主张。对此进行决策的是项目组合管理团队，通常由BU层面的决策者在每年做预算时提出。除了投资主题，管理团队还需要确认技术层面的架构跑道，包括现有或计划中的基础设施，满足目前需求而不必过分重构，以及系统级的非功能性需求（如性能、安全、可靠性、行业标准、系统设计约束等）。
明确了投资主题，就从中提取出史诗故事（或者称为篇章，Epic），它是大规模的开发行动，实现投资主题价值。同理，也要从架构跑道中提取出架构实现的史诗故事。
简单理解就是：单个独立小团队的迭代发布是以具体特性驱动，拆解为用户故事进行开发；而项目集增量发布是以史诗故事（Epic，投资主题中抽象出的价值）驱动，拆解为特性给到单个团队进行开发；项目组合发布是以投资主题和架构跑道驱动，拆解为史诗故事给到项目集团队进行开发。
1） 提供项目集层面的专项测试资源。
对于项目集运作的大型产品或者产品集，除了安排在每个特性团队的专职测试人员，还需要考虑安排合适的专项系统测试人员，负责大型系统层面的质量保障，以期达到交付标准。比如系统级的复杂性能测试、安全渗透测试、升级测试和兼容测试等。此外还需要指定持续交付测试的负责人，确保每日测试的自动化测试结果是健康、完整的，在出现风险能及时介入分析。
2） 在ART流程中建立特性合入的质量标准。
在ART指定的集成时间之前，特性团队的版本如果没有达到代码合入主线的质量标准，则不能合入，只能在下次ART集成时提交了。因此，项目集要对各特性团队确认统一的合入质量标准，并在合入前确认特性测试通过的结果。合入后需要进行各项系统测试，确保合入后的整体质量达到系统发布的质量标准。
3） 每个PSI开始的联合会议上，尽可能确认各特性间的测试依赖关系和策略执行风险。
几个月一次的多个特性团队联合会议，是非常难得的碰头脑暴的机会，各特性测试负责人、系统测试负责人、主管和测试架构师，都需要利用这次机会好好梳理，搜集系统测试需要掌握的产品和技术知识。例如：
❑不同的特性测试是否有先后依赖关系，测试次序是否要调整？自动化用例建设是否也需要调整次序？
❑测试设备和环境是否充足，是否影响并行的特性测试，如果影响，应该如何协调？
❑对于列出的风险，是否已有初步对策？如果没有，谁需要保持观察和优先响应？
❑对于项目集团队决策的ART合入和特性发布计划，以及产品路线图，从质量角度看，是否有信心按时完成？
4） 评估项目集的测试技术债（技术需求）优先级。
与特性评估类似，要综合考虑实现工作量和延迟成本，延迟成本越大，工作量越小，优先级应该越高。
测试技术需求的延迟成本与如下几个因素有关：
❑ 商业价值 。需求实现能降低多大的公司运营成本？如能减少多少测试总投入成本？提高多少用户体验满意度？
❑ 时间价值 。实现价值如何随着时间推移而衰减？衰减越快说明优先级权重越大。比如现阶段实现的自动化能力能大幅提高测试效率，但是后期的使用率可能迅速减少了，那就应该提高优先级权重。
❑ 让未来的风险降低或者提升新的价值机会 。比如越能预警发布质量事故的工具需求，其权重就越大。
本章针对主流的敏捷实践框架及其价值观做了核心知识回顾，包括Scrum、XP、用户故事、精益看板和SAFe等，然后分别从测试视角详细分享了值得关注和尝试的敏捷措施。测试人员全身心融入整个敏捷转型过程是非常关键的，这样可以从中获得传统测试理论缺失的知识，通过应对各种意想不到的问题，形成适合自己团队的敏捷新方法，最终打破当前能力域的瓶颈。