敏捷测试转型 聊聊团队效能的自我诊断

鼎叔 · 2023年05月09日 · 最后由 萌梓萌爸 回复于 2023年05月12日 · 4917 次阅读

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

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

理解了敏捷知识和失败原因(参考:聊聊敏捷转型为什么容易失败 https://mp.weixin.qq.com/s?__biz=MzkzMzI3NDYzNw==&mid=2247484228&idx=1&sn=1e77a57df1af104b297de7c4dd16e87f&scene=21#wechat_redirect),我们可以开始逐步诊断团队自身,通过集体脑爆,一起制定未来的转型目标。

打造敏捷团队,与打造成功的敏捷产品,有一定的相似性,团队成员对未来愿景能否达成共识,对如何到达愿景的主要措施能否达成共识,至关重要,这是指导未来具体交付行为的指南针。

基于鼎叔的亲身实践,本文将从团队管理者或者教练的角度,推荐以下自我诊断流程。

团队代表访谈

空降团队的管理者或者教练需要和有代表性的成员做单独交流,为后面最重要的脑暴会议做准备。访谈对象还可以包括最密切的关键合作方。

单独访谈需要营造放松安全的氛围,主要关心受访者对下列五类问题的真实看法。

1)外部干系人对我们测试角色的最大期望是什么?包括质量上的期望和效率上的期望,哪些专业工作做得不够到位,遗留的风险比较大。哪些工作最需要测试团队的支持(服务)。

2)哪些知识和能力的缺乏,阻碍了我们提升效率和质量?包括业务知识,测试技术知识,培训资源,管理认知等,获取这些信息的渠道如果不通畅,原因是什么?

3)哪些最常见的外部干扰严重阻碍了测试交付的效率?类似,测试人员被迫等待和加班的主要原因是什么,可否规避?

4)测试交付的主要活动成果中,价值偏低的有哪些?这些低价值成果,如果不做会怎么样?测试成员对承担低价值工作的情绪如何?自动化测试的建设,产出价值符合预期么?

5)哪些当前的组织问题阻碍了测试的敏捷转身?包括激励因素,安全感,官僚习惯,部门墙,专家指导,等等。

提炼结果,召开脑暴会议

组织诊断的负责人提前对搜集到的突出问题做归类和提炼,作为现场脑暴会的背景信息。对于意想不到的问题,要做更多的探寻。需要的话,可以结合突出问题相关的历史数据和典型报告,进行分析判断。

准备一个能充分研讨的会议室,预留至少 4 个小时的会议时间,邀请团队核心骨干、角色代表和新人代表参与,请大家带着吐槽和期待前来。脑暴会议要务虚,不要演变为具体问题的辩解 PK 和解决措施评审,也不要变成错误检讨会。

负责人按照一定的会议议程严格控场,但也要安排比较充分的吐槽和讨论时间,最终得出一系列团队诊断和共识成果。

下面是个人推荐的引导做法,可以根据脑暴会的时长对产出目标及数量进行裁剪,或者分两轮来研讨。

阻碍我们测试人员提高交付效率的典型事件有哪几种?评选中最严重的 TOP5 阻碍事件。
为了达成业务和管理者的期待,测试团队面临的最典型风险有哪几个(种)?评选出 TOP5 风险。
针对测试团队的能力现状做 SWOT 分析(优势、劣势、外部机会,外部挑战),各选出 TOP1-3(不超过 3 个)。
基于以上讨论,畅想一下,测试团队未来 3-5 年后应该是什么样子?用一句话描述团队发展的愿景。大家投票确认共识,未来会把愿景写在公共区域。
团队向着正确的愿景方向前进,在进行敏捷转型实践中,应该遵守什么敏捷原则?从测试团队关心的角度进行投票,选出 TOP5 敏捷测试原则。
综合以上的分析,为了向愿景进发,未来一年团队要完成的具体举措是什么?不超过 3-5 个挑战举措,可以是降低 TOP 风险的,可以是提高测试效率的,也可以是提高专业品质的。

TOP 举措的跟进

会议结束后,如果无异议,负责人可以用史诗故事的描述方式(类比产品需求概念中的大型完整需求,可以拆解为多个具体特性和故事场景)把 TOP 举措,也包括团队愿景描述,录入团队工作空间或 WIKI 里,让所有成员随时可以看到。将来可以进一步把这个史诗故事通过充分研讨拆解为子举措、个人目标、阶段性目标等,排期跟进完成。

诊断脑暴会的成果示例

为了方便读者理解诊断分析后的最终共识成果长什么样子,本文提供一个具体的输出案作为参考,相信会对多数测试团队有所启发,但具体到每个团队,还需要根据自己的个性化痛点和诉求进行调整。

测试团队转型愿景示例

成为业界领先的高效能游戏测试团队。

说明:愿景立足于团队自身,是对团队未来 3-5 年的美好状态的憧憬。对愿景的描述不需要具体,业务大方向通常是长期稳定的,但业务具体规则和项目计划则每年都会变。从多年经验来看,敏捷、高效能、转型、业界领先、一流、品质、测试技术、用户体验、价值等关键词被愿景选中的概率比较高。

确定愿景的目的是从信念上把大家拉成一股绳,面向未来长期合作、共同奋斗。

敏捷测试原则示例

1)必须优先处理超过 48 小时的测试环境阻塞事件,公布原因和处理措施。

2)在所有新增测试需求被接受前,必须给出需求方理由、针对的风险等级,以及测试成本。

3)应该将所有质量审批流程设计为并行,不能串行,非关键角色审批可以忽略。

4)对于所有紧急的加班测试及发布版本,需给出必须紧急发布的充分理由。

说明:敏捷原则就是一句话说清楚如何操作的共识,需要是跨不同场景都能适用的抽象指导。因为工作场景五花八门,洋洋洒洒写一堆细化规则反而无法传播主旨。既然是原则,一定是挑选最典型的痛点,通过严格执行来落实敏捷价值观。

补充:我们也可以挑选几个价值观的关键词,作为敏捷测试原则的进一步提炼,方便所有成员牢牢记忆,比如:“show me the code”,流程去中介,拒绝浪费,少发报告,单测先行,劳逸结合,等等。

本专辑还会提炼更多的敏捷测试知识点,可以作为自己团队敏捷测试原则的候选。

重大举措示例

示例一:重点参与三个试点项目敏捷转型,测试交付效能提升指标达成,梳理出敏捷测试相关的通用总结。

示例二:针对敏捷原则刷新现行的所有测试流程规范,通过评审并在团队中宣导和常规执行。

说明:重大举措相当于团队要完成的年度史诗故事,制定后还需要多次讨论其实现方案,里程碑,考核指标,拆解到个人的分工,等等。举措描述也要符合 SMART。相关的辅助工作如调研和培训,可以纳入拆解出来的子举措中(相当于一个个特性需求的实现)。

可以通过敏捷研发管理系统去跟进落实所有相关的大小举措,这和普通产品需求研发的管理过程没有什么不同。

测试团队 SWOT 分析示例

优势:分层自动化测试平台比较完善,工程师普遍掌握自动化测试技能。

劣势:线上低级漏测情况严重,经常被质疑用例设计能力不足,测试占用周期太长,没有时间提升自动化覆盖率。

外部机会:客服部和试用用户平台愿意配合测试部,完善漏测问题的快速分析和验证,参与灰度测试活动。

外部威胁:黑盒执行团队人力比同行庞大,效率较低,管理层考虑大幅收缩编制。

说明:SWOT 分析是我们在明确愿景之前对自己的深刻剖析,分析的结果就是让高价值的长板更长,并集中力量补齐阻碍我们达成愿景的关键短板。

TOP 风险示例(针对测试交付)

业务交付风险:智能语音产品没有明确的质量验收范围,可测试场景数量巨大,导致交付周期长,而且线上吐槽不断。

团队发展风险:自动化测试建设口碑平平,核心工程师兴致索然,离职风险加大。

说明:最典型和严重的风险,也是制定年度举措的重要输入,因为除了一定要建设的成果,也有一定要防范的危险,否则业绩目标就可能功亏一篑。而 TOP 风险可以从业务交付视角和团队内部健康发展视角来提炼,内外需兼顾。

鼎叔经常在敏捷转型的启动会议上,把导致转型彻底失败的风险摊开,做个 “事前追悼” 的思维碰撞:

请每个与会者都说一说,如果我们按照商议的计划去执行,一年后测试团队敏捷转型仍然惨败,那最有可能的导火索是什么?

这个问题可以更直接的激发员工深入思考本质风险,找出值得纳入举措的遗漏点。以下是可能的导火索示例:

领导朝令夕改,放弃转型计划,不提供资源支持。
一线测试人员仍然独自背负着质量兜底的责任,拒绝拥抱敏捷,甚至大量离职。
测试人员的专业水平跟不上,无法支持整个特性团队的每日持续测试。漫长的测试周期和强硬的通过标准,间接影响业务发布节奏的达成。

需要更多武器?

有了诊断结果和行动目标,如何为各位读者输送合适的强力 “武器”,提升关键能力,帮助愿景的达成?

每个团队的专业度和境遇不同,对于敏捷测试的指导需求也不同。敏捷测试的工具箱非常丰富,在一段时期内并不需要同时展开实践,避免负担过大。

本公众号将陆续为大家提供不同细分领域的理论与实操方案,帮助测试团队走向更有生命力的敏捷组织形态。欢迎各位阅读后结合自身需求采取行动。

共收到 1 条回复 时间 点赞

感谢分享,收获良多。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册