扫码阅读
手机扫码阅读

聊聊Scrum三大角色的质量意识和文化建设

47 2024-01-31

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

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

原文链接: http://mp.weixin.qq.com/s?__biz=MzkzMzI3NDYzNw==&mid=2247484247&idx=1&sn=058d4f27ce2570f82f046ee7c3702fb2&chksm=c24fb635f5383f23562bf52ada7917d0050996467aae1f2a8f78d6c376ccc84883e96d0fa4e1#rd

《无测试组织-测试团队的敏捷转型》主题探讨。从打造测试的组织敏捷,到敏捷测试技术的丰富实践,从一线团队的视角来聊聊我们是怎么做的。面向未来,拥抱敏捷原则,走向高效能组织。

81 篇文章
浏览 5375
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设 白皮书上线