您现在的位置是：首页 >技术交流 >聊聊Scrum价值观与测试启发网站首页技术交流

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

欢迎关注本公众号《敏捷测试转型》，星标收藏，大量原创思考文章陆续推出。

敏捷理论博大精深，相关实践方法论和工具层出不穷，各大公司都有特定的实践模式。敏捷实践方法的框架并不是精确的工具应用，而是一整套做法和纪律。它能否真正获得成功，也强依赖于组织和个人的能力，因此优秀的敏捷教练需要对理论、技术和人性都有相当深刻的认知。参考阅读：聊聊敏捷与敏捷测试。

本专辑后面几篇，会陆续对主流的敏捷实践框架做简单的核心知识回顾，然后展开阐述测试人员应该如何支持敏捷落地，并从敏捷知识中汲取补齐自己短板的理论，消除以往的困惑，积极尝试新的敏捷方法，尤其要拉通非测试专业人员完成有价值的测试活动。我们先从普及程度最高的敏捷框架- Scrum开始聊起。

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

理解Scrum

Scrum的概念由日本教授在1986年提出，其框架在1995年公开发布，并在2001年成立了Scrum联盟。

据说，"Scrum”这个名词源自橄榄球比赛的专业术语-“争球”，原意为通力合作，在场地里传球，体现了配合和信念的一致，目标明确。

Scrum的理念也借鉴了军事训练理论中的“观察-导向-决定-行动”（OODA），它体现了意见反馈的回路，在军事上，反应迟疑是致命的。

Scrum作为源自日本的概念，也借鉴了日本合气道的“破守离”。

通过Scrum框架，人们可以解决一系列的自适应难题，同时也可以高效并创造性地交付最高价值的产品，它是建立在一系列价值观、原则和实践之上的。据统计，约有70%做敏捷转型的软件团队在采用Scrum框架，所以它是最成熟最普及的敏捷工具。

一个典型的Scrum框架如下图所示。

Scrum基于经验主义，采用迭代（Iterative）开发模式，逐步把粗糙的想法变成现实。根据产品特征和业务特性的不同，可以选用不同的迭代周期和发布节奏。Scrum的核心原则是检查、调整和透明，工作框架简称3355：

• 3个角色（Role）：包括PO（Product Owner，产品负责人），SM（Scrum Master，教练），Team（自组织团队）。

• 3个工件（Artifact )：包括产品待办列表（Product Backlog），迭代待办列表（Spring [1] [MOU2] Backlog），产品增量（Product Increment）。

• 5个活动（Workflow）：包括迭代梳理会（Spring Refinement），迭代计划会（Spring Planning），每日站会（Daily Scrum Meeting），迭代评审会（Spring Review），迭代回顾会（Spring Retrospective）。

• 5个价值观（Value）：包括承诺（Commitment），专注（Focus），尊重（Respect），开放（Openness），勇气（Courage）。

Scrum引入了Backlog的概念来衡量工作量，可以根据优先级来交付工作任务。

Scrum的理论知识丰富，相关经典书籍很多，本文就不全面展开，读者可以自行学习。

下面仅从测试角色和测试活动的角度（注意：负责测试活动的角色不一定是测试工程师，也可以是开发或产品经理等），重新挖掘Scrum的精髓实践内容，以期得到更多的启发。

测试团队的领导者或教练，尤其要对这些启发内容多上心，检视有哪些支持和改进项可以一个个落地。

把敏捷理念积极融于到测试工作中，本质上就是既要高质量，也要高效率。而这样的转变趋势也让团队更融洽，更有激情，形成正向循环。

五个Scrum核心价值观给测试带来的启发

尊重：团队成员互相尊重，彼此独立，有核心能力。

貌似无比正确的“偏虚”价值观，在坦诚的自我检视下，我们其实能发现不少典型的负面行为。

一 检视独立性

测试活动交付是否能个人独立进行？我最常见到的反模式是把测试任务拆解为用例设计、测试执行、自动化脚本执行，测试项目管理这四项工作，由测试部门的四个细分角色去完成，最后由测试项目经理汇报。

对于合适大小的被测模块，显然一个人完成以上四项工作是效率最高的，对于需求理解和用例设计，思路能够得到贯通。不同的测试角色分工承担，彼此依赖对方的知识和产出，产生严重的依赖等待，每个人的专业水平提升也会非常慢。

如果测试范围太大，需要多个测试人员怎么办？按特性完成测试交付自然是最佳分工方案，因为特性就是相对独立的可验证价值的用户需求。

注意：可以把同类技术债的验收测试交给技术比较强的测试人员独立把控。

二 检视尊重氛围

测试团队内的管理，测试和其他角色的协作，是否体现了不被尊重的态度？

如果有明显的负面氛围，教练/测试主管就需要进行分析和尝试改进，只有在积极情绪下才能更好地激发个人效能。

1）对测试新人，对驻场外包测试人员，分配工作时可以有不同的难度和趣味程度，但要多倾听他们的心声，并引导他们通过努力带来变化。切忌不要有“默认没有技术含量的工作都是你的”这种表达，而是多询问：如果你觉得手上的工作简单了，你希望承接什么难度的新任务，需要什么培训？如果你觉得经常测试的内容太简单重复，你希望尝试什么自动化的方案？

2） 项目团队对于测试的分工定位，是否有非测试领域的“杂活”过度分派给测试，并引发不满的情况？
       敏捷团队的文化体现在个体勇于承担边界任务，我们也鼓励测试人员多承担边界工作，哪怕繁琐，只要是有必要性的，对于测试口碑就有正向作用。但是如果形成“不需要写代码的杂活就给测试干”这类分工逻辑就不太合适了，它会影响测试人员本身的专业发展，比如让测试人员长期做用户投诉反馈的处理工作，或者负责所有版本发布流程保障等等。

敏捷组织不鼓励为每一类细分专业岗位都能招聘一个全职人力，在没有专业人士支援的情况下，对于暂时无法自动化的枯燥手工任务，有必要根据团队成员的自愿度进行任务分配，或者轮流承担边界任务，这也有利于成员彼此学习，共同为交付负责。

三 检视核心能力：

测试工程师本质上应该有专业门槛，测试主管应确保进入敏捷团队的专职测试人员是有专业核心能力的，才能获得敏捷团队的充分信任，如果测试工程师专业资质很弱，就很容易陷入上述“不尊重测试”的反模式。

测试主管和架构师有义务对测试工程师进行核心能力的持续培训和赋能，详细内容可以参考“聊聊团队能力培养与创新氛围（合辑共17篇）”。慎重选择分配到敏捷特性团队的成员，如果不能胜任，可以采取更换派驻骨干的行动，或者通过团队发起验收测试任务来保障要交付的基础质量。

专注和承诺：聚焦Spring工作和Scrum团队目标

常见的反模式是：

1) 敏捷特性团队中的测试人员并不是专职人员，他还兼顾着其他数个团队的测试角色。

2) 虽然是全职测试人员，但是经常被来自其他团队或者自己上司的临时任务打断。

不专注的结果就是承诺的测试交付无法达成，理由还理直气壮-我还有更重要的事情要做。这类反模式对测试人员在敏捷团队的口碑有明显伤害。

测试主管和教练请注意：

1) 如果必须要给敏捷特性团队分派测试人力，但人数不够全职分派，那就一定要约定投入百分比（建议不低于50%），在分派任务的估算中给予相应考虑，派驻特性团队的人员要做到核心会议的认真参与和沟通。

2) 度量测试人员被非迭代任务打断的次数和花费的时间，如果数据严重应该进行干预，采取保护测试人员不被打扰的行动。

此外，测试人员自身也要注意，既要基于合理估算承诺本迭代要完成的目标范围，也要面向团队中长期目标思考工作的优先级，预留一定的排期时间，不要只顾完成眼前迭代任务，不去思考为长期的质量或效率提升应该做什么事，这些事通常重要但不紧急。

开放：Scrum团队和干系人同意将所有工作和执行上的挑战公开

对于测试人员而言，开放意味着信息透明化，有困惑就提出来商量解决。

常见的反模式：

1) 和敏捷业务和目标有关的会议没有邀请测试参加。对于测试工作需要的产品信息和技术文档没有提供，或者需要特别申请访问权限。

2) 产品需求变更没有及时知会测试，或者背后的变更原因没有主动同步。

3) 随意压缩测试执行时间，但并没有商讨改变测试范围和优先级。后继的迭代中也没有改进动作。

4) 测试不关心其他岗位人员的工作内容及其重要关切，其他岗位也不关心测试具体在做哪些技术建设，只要及时完成测试报告就行。

5) 团队没有针对质量讨论的氛围，评审完需求和发布时间就结束了，没有预留时间讨论交付质量风险和用户投诉。

开放也是双向的，一方面测试人员要主动展示测试各项进展工作，阐述该项工作对业务的价值，另一方面特性团队其他成员也需要公开同步项目关键信息，尊重测试专业意见。各角色都可以轻松获取项目内的所有信息知识，随时看到整个项目的运行进展。

勇气：做正确的事，并处理那些棘手的问题

针对项目进展的风险，以及团队协作的不良关系，测试人员要敢于暴露。

常见的反模式是：测试暴露的严重风险被掩盖（不让上级知晓），不通过的测试结论被软磨硬泡地通过，质量事故的责任确认不清。

大家通过开诚布公的商讨，共同承担可能的质量代价（明显违反原则纪律的情况除外），而不是孤立勇于曝光风险的人。困难的问题需要集体合作分担，也可以拆解为一个个更简单的问题，按迭代完成，但推迟是解决不了问题的，只会积累更严重的风险。

把复杂的规则可视化、简单化，是鼓励勇气价值观的好窍门。

提升勇气，既可以让团队更加彼此信赖，又可以对自己的专业挑战充满斗志。