这是鼎叔的第六十三篇原创文章。行业大牛和刚毕业的小白，都可以进来聊聊。
欢迎关注本专栏和微信公众号《敏捷测试转型》，星标收藏，大量原创思考文章陆续推出。
本篇从 Scrum 的主要角色视角，来看怎么支持好质量内建活动，以及理解 Scrum 真正的价值，建立相应的团队文化。
Scrum 三大角色应关注的测试活动
从 Scrum 的三个主要角色，也称三驾马车，即 PO（Product Owner，产品负责人），SM（Scrum Master，教练），TL（技术 leader。也有书上把这个角色称为 team，自组织团队）。
从他们的职责出发，思考：哪些活动能有效帮助团队提高产品交付质量和全员质量意识。
PO 应关注的测试活动
一、确认产品需求优先级的背后 “故事”，是否同步给测试人员。
需求优先级由 PO 最终拍板，那 PO 实际上掌握了众多确定优先级的信息，以及决策的思考逻辑，这些信息如果能清晰的传递给测试人员，那么对于测试分析和制定策略也会非常有帮助。
二、确保业务产品信息对技术团队能及时更新，合理归档。
尽可能减少由于产品信息没有对齐，带来的无效开发和无效测试。有一部分产品反馈信息（包括埋点行为数据）是上市后才能获得，有一部分信息是客户单独传递的，它们对于测试人员优化测试覆盖策略可能非常有帮助，PO 应该保障好这些数据的内部共享。
同时针对测试人员的质量反馈，PO 应判断是否体现了产品设计的不合理，是否有必要作为品质改进需求加入产品代办列表。
三、传递产品愿景和关键词。
虽然愿景对于工程师个体而言很虚，但是如果团队对产品未来充满信心，对于产品的独特价值主张有共识，那测试能够从关键词中聚焦质量提升方向，提炼高优先级的确认标准。
SM 应关注的测试活动
一、是否有意识的组织质量内建活动，将其固化为好的团队习惯。
如果 SM 对于质量内建活动不够关注，测试角色可以多加提醒。这些活动包括但不限于：DoR（需求准备好进入开发的标准）和 DoD（需求完成开发的标准）中的质量达成纪律、Deskcheck 桌面评审活动、代码质量评审和用例评审、确认验收测试，发布前的集体缺陷大扫除等。
二、是否能识别测试角色遇到的阻塞、打扰和依赖，并尽快协助处理。
帮忙各个角色（包括测试）搞定上述困难是 SM 的最核心职责，针对测试角色的干扰有：来自领导的与迭代无关的需求、非本项目的任务、测试环境和工具的阻塞、阻塞级缺陷（导致其他测试内容无法执行）。SM 一旦判断阻塞了工作开展，当天就应商讨对策。
三、是否维护了尊重测试结论，鼓励测试新技术实践的研发氛围。
SM 的重要义务是让团队处于互信和尊重的氛围，充满自管理的激情。警惕迫于发布的压力，逼迫测试人员修改测试结论和掩盖风险的现象。如果能够把启发创新的方法引入到团队的测试活动中，那就能激发更长久的价值。
团队的知识归档和刷新也是 SM 的关注重点，其中质量知识和测试技能也占有一席之地。
四、是否在迭代结束后，度量过程质量数据，选择最重要的短板进行持续改进。
有始有终，迭代完成的回顾会议，SM 需要让大家对过程质量数据和发布质量进行分析，给出的改进措施一定要以预防为优先，明确下个迭代的改进动作是什么。
TL 应关注的测试活动
一、关注测试技术债的偿还。
TL 作为技术领导者，参与了产品规划会后，一定要尽早识别包括测试效能在内的技术债（可以通过缺陷趋势、代码评审报告、静态扫描结果、架构性问题等数据来判断），制定偿还技术债的方案，鼓励开发人员同测试一起共建高效的自动化测试工具链，并对工具链选型做决策。
消除测试技术债的成果可能是一个工具，如果开发人员也是该工具用户，可以邀请开发做验收测试。
TL 需和 PO 达成共识，在迭代排期中充分考虑预留测试技术债的偿还时间，持续偿还，而不是发现问题严重的时候才仓促做一波。
二、在技术层面把控好质量内建。
质量内建如此重要，需要 SM 和 TL 一同承担，SM 负责组织和氛围建设，TL 负责技术上的把关，包括：
组织团队解决疑难问题，完成根因分析，主导修复架构设计上的隐患。
评审测试策略，督促持续集成的卡点纪律，组织代码审查和落实代码规范，帮助开发养成良好的编码习惯，出现流水线构建问题能确保有人第一时间响应。
三、明确质量保障的投入重心。
TL 应该帮助测试人员改进测试方法，参与测试策略和自动化测试方案的评审，根据迭代过程的回顾，优化当前的测试资源投入。
三架马车对于团队的担当 - 树立 Scrum 文化，避免浪费
传统项目管理团队中，甘特图文化盛行，它体现了瀑布型研发团队的 “命令与控制” 文化，事实上，甘特图并不能阻止项目的延期。Scrum 团队只有看到了团队的速度大小，才能判断准确的完工时间，用 “检查和调整” 消除障碍和浪费，这一点和 HR 宣传的 PDCA 模型是高度一致的。Scrum 团队使用 “冲刺” 来定期展示成果和收集反馈，这种方式体现了戏剧化的效果。
把生命浪费在没有意义的工作上无异于犯罪。据统计，我们研发出的产品，有 80% 的价值来自于 20% 的功能，有 85% 的工作花费都被浪费掉了。日本人创造 “Scrum” 概念时，把它和避免 “无理，无稳，无驮” 联系在一起，无理即 “超载”，无稳即 “失去平衡”，无驮即 “无价值”。
在一线团队，严重浪费导致的几种表现有：设定荒谬的目标，期待某个英雄出现拯救大家，负担大而无实际价值，员工充满负面情绪。
那如何让员工减少浪费呢？精益理论告诉我们，那就是一次只做一件事情，效率最高，并且一次性把它做好，交付的东西如果客户不能使用，就不能算 “完成事项”。每一个员工都有权力在流水线出错后，马上按下暂停键，纠正它。每一次 Scrum 站会，SM 都是让大家抛出阻塞问题，并在展会后立即解决问题。
在团队中移除隔板，让大家能互相看见对方。信息表格公开，透明化，让大家都能看到，哪些事做对了，哪些事做错了，能畅所欲言。
为什么米格战机性能更发达，但是总被美军战机击落？就是因为飞行员在座舱的视野很小，导致在采取行动前反应慢。
部门利益和管理者的私心，也有可能阻碍团队信息透明，尤其涉及资料在不同团队的移交，可能发生效率灾难。而头衔越多，越降低沟通饱和度，这就是有的大企业会用简单英文名取代头衔称呼的原因。
团队工作的流畅性源于纪律性，大家扪心自问，难道我们真的一直选择维持糟糕的现状么？
对于 Scrum 的更多理解
部分观点来自 Jeff Sutherland，他是 Scrum 的创立人之一。
Scrum 可以应用在任何领域
Scrum 实践不止给技术团队带来效率的最大化，也适用于其他领域的项目：政府工程，环境保护，教育，扶贫，打击犯罪。
以建筑行业的著名成果 - 大教堂为例，动辄修了一百多年，如果当时采取 Scrum 的团队合作机制，是否会大幅提升修建速度呢？我想是的。我们可以让参与建筑的工作每天开 Scrum 立会，避免各工种的彼此等待依赖，而这是大多数时间被浪费掉的原因。
Scrum 也可以用于孩子的学习教育，可以针对学习目标进行迭代计划，估算任务耗时，定时复盘，提炼教训，明确下一迭代的学习目标，等等。
火腿和鸡蛋的故事
这是 Scrum 培训最常出现的梗。母鸡找猪成立联合公司，卖火腿炒蛋这道炒菜。这个合作是难以持续的，因为双方对于火腿炒蛋这个菜，付出完全不对等。母鸡付出的是鸡蛋，相当于 Scrum 中了解项目进程的利益相关方，而猪是付出的生命，相当于全身心投入 Scrum 项目的负责人。要让 Scrum 团队保持旺盛的精力和长时间的合作，针对全职投入度进行高激励是很有必要的。
评估迭代的开发速率为什么不准？
提前做规划对于很多人而言太有诱惑了，传统研发团队花了大量精力做规划，甚至把实际情况和行动方案抛到了脑后。即使是 Scrum 的迭代短周期的规划估算，都存在不准确的老大难问题，未来也会有专门文章探讨这一点。
下面是一个不确定性圆锥，实际工作量既可能是之前评估的 4 倍，也可能是 1/4，即，最初评估的最大工作量和最小工作量会呈现出 16 倍的差异。但随着项目的推进和完成的工作越来越多，评估的工作量会越来越接近于实际所需的工作量。
在评估会议上，其实每个人都有保留意见，只是不一定会表达出来。建议主持者利用匿名方法搜集各位的意见，避免从众效应和光环效应。注意：让真正做事的人去评估工作量，而不是专家。
PO 和 SM 的职责差异
很多成员认为，PO 和 SM 的职责边界并不是那么清晰，有一定的模糊交集。
我的观点是：PO 决定 “做什么”，SM 主导 “怎么做” 的方式。PO 需要更多产品业务的专业知识，拥有产品的自主决策权，通过和团队充分接触，对最终价值负责。
Scrum 项目的合同变更
基于 Scrum 的敏捷研发，我们对合同中的需求变更是持乐观态度的，这和传统研发痛恨变更的态度完全不同。我们甚至希望合同中的需求变更能给甲方和乙方带来双赢。比如，客户希望在期望时间内增加新的需求，我们就有权根据其需求的点数，扣除原计划要交付的同等大小功能即可。
客户在任何时候都可以终止合同，除了已交付需求的费用，只需要再支付剩余合同需求价值点的一定比例，如 20%。
优秀 Scrum 团队的样子
Scrum 团队人数，8 人以下最佳（开发者），超过 8 人的沟通效率会下降，沟通复杂度是 N*（N-1）。
Scrum 主管是 “仆人” 式主管，经常询问大家：我们如何才能做得更好。他让团队避免互相指责，以免把简单的纰漏搞成 “归因错误”。他通过改良制度，奖励积极行为。
卓越 Scrum 团队体现出超越寻常的特质，自主性（如同突发新闻现场的记者），多功能性（每人都有多样化能力，就像特种部队）！
卓越团队能把快乐转化为绩效，善于 “量化” 快乐，比如在冲刺结束后把感受统计为 “快乐指标”，它和未来的效能是正相关关系。
而人与人的联系越密切，快乐程度越高。因此，有的公司大楼只有一个出入口，厕所也集中在一起，这样就增加了员工交流交谈的频率。
当然，最大的快乐源自完成重要工作的成就感，而不是工作轻松。
Scrum 的 SM 是一个 “聪明的傻瓜”，他知道如何戳破团队自满的 “快乐泡沫”，让团队直面不愿看到的现实。