开发自测很重要,但推不动怎么办?

严鸿贵,喜马拉雅项目经理


「缺陷」就是个负产出,损耗人力成本,让团队欲速而不达。在 2017 年,喜马拉雅曾经遇见过因为交付质量拖累迭代进度的问题。当时我们的业务量激增,团队规模从 700 人快速扩张到 1500 人,每条业务线的研发团队规模从 10 人变成了 50 人,每个月规划一次版本迭代,可是经常都会延期。
如何提升整个团队的效率呢?作为喜马拉雅的项目管理负责人,我在项目整个生命周期的每个节点都做了许多优化改进,其中让我觉得能够四两拨千斤的措施就是:提升交付质量。
我们从「质量」着手,量化每位开发同学的交付质量,并且持续优化这个指标,2 个月内团队效率就得到了大幅改善,这次实践经验比较成功,在这里分享给大家。

先说我们的采用的核心方法是:推动开发自测。
自测这件事情有多重要?团队里的两位开发同学,一人做自测,一人不做,提交给测试后,前者可能只被测出 1 个缺陷,后者可能多达 10 个缺陷,虽然大家手头的业务量和完成时间是一样的,但是两人的效率显然是不同的,必须予以重视。
曾经有很长一段时间,我们的开发同学会把未经自测的需求直接提交给测试,问题挺多的,大家来回改、来回测,消耗掉很多时间。其实出现很多问题,都是因为开发同学「自以为没有问题」,如果做好自测,问题早就被发现、被解决了,根本没有必要这么来回折腾,毕竟测试团队的职责是质量保障,而非代码审查。
如果我们可以保证交付给测试团队的代码是优质的,不仅能够将测试周期缩短,提高业务迭代效率,而且也能把优质的产品交付给亿万用户。

但是,想要推动开发自测,口头倡导是没什么用的。
很多团队都想推动开发自测,喜马拉雅内部也早就这么提倡过,但是推进情况并不理想,原因在于:光靠说,是很难让每个人改变工作习惯的,必须借助一些项目管理方法,才能把这件事情落实到位。
我们探索了 2 个月,总结了一套推动自测的实践办法,简单来说做好以下三步就可以了。

1、开发自测「任务化」
我们使用 Teambition 的测试管理功能,把开发自测这件事给「任务化」了。在「测试计划」中,测试人员为每个迭代组织好用例,把高优先级的用例指派给开发人员,由开发人员执行自测任务。

创建自测任务,将优先级较高的用例指派给开发人员执行

2、设定可衡量的指标
完成自测后,开发人员将任务状态调整为「已通过」,由测试人员进行复测,如果测出缺陷,测试人员会把任务的状态改为「未通过」,这样就可以按执行人统计出实际的「通过率」。以前我们不知道谁的的正确率更高,有了「通过率」这个数据,一切就很清楚了。

如复测出缺陷,由测试人员将任务状态改为「未通过」

3、数据驱动提升
我们会按迭代查看自测数据,这样可以帮助团队成员有针对性地去做提升,整个团队的工作能力和效率都变得更好。另外,也因为看得到效果,大家的自测意愿度也更高了。

轻松导出通过率、开发总时长、自测时长等数据

这套「自测」方法落地后带来的效果是:交付质量提升50%。
当这套流程落实到位,带来的收益是巨大的。怎样算是有效提升质量?我建议大家直接参考「缺陷数量」。去年第 4 季度,喜马拉雅的开发任务相比第 1 季度是直接翻倍的,理论上缺陷数量也一定会增多,而从数据结果看,整个项目的质量非常平稳,平均每月、每天的缺陷数都没有增多,这个过程是非常不容易的。

试点「研发自测任务化」的产品研发团队,成为了公司内部最敏捷的团队。
通过这一措施,平均测试周期同比试点之前缩短了 1/3 – 1/2,可以保证 2 周跑完一个迭代,而此前需要 3 – 4 周。这套方法成功推动业务迭代加速,该团队也为公司带来了巨大的创收,获得了 CEO 特别奖的殊荣。

最后想说,在整个提升过程中,「协作」真的非常重要。
市面上的研发项目管理工具有很多,喜马拉雅选择 Teambition 的重要原因是,这个工具更重视「协作」,而不是单向记录。
一个需求从提出到交付,涉及到产品、开发、测试、运营等多岗位多人协作,沟通链条错综复杂。在其中自测环节,如果开发和测试同学没有一个可以衔接任务的工作台,沟通成本就会非常的大,每次都需要通过会议去确认测试进展,去拉平开发和测试对于产品质量的认知。除此之外,我们在整个项目生命周期中,各个环节的协作,都需要通过工具去降低管理成本、减少信息传递损耗。

喜马拉雅是中国最大音频分享平台,目前拥有超过 4.7 亿手机用户,位居移动音频市场份额第一。五年公司估值增长超过 1000 倍,成为移动互联网领域成长最快的企业之一。


 

Teambition,让团队协作焕然一新

10 人以下免费使用,立即邀请团队成员开始协作。

button
button