聊聊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团队保持旺盛的精力和长时间的合作，针对全职投入度进行高激励是很有必要的。