您现在的位置是：首页 >技术杂谈 >聊聊Scrum三大角色的质量意识和文化建设网站首页技术杂谈

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

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

参考前文：聊聊Scrum价值观与测试启发

本篇从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是一个“聪明的傻瓜”，他知道如何戳破团队自满的“快乐泡沫”，让团队直面不愿看到的现实。