首页 > 其他分享 >团队交付质量如何评估

团队交付质量如何评估

时间:2022-10-17 20:23:34浏览次数:79  
标签:团队 迭代 用户 研发 质量 交付 缺陷 评估

https://mp.weixin.qq.com/s?__biz=MzkwNTI2NjAxMA==&mid=2247483988&idx=1&sn=81712c52876285ebe61387d2d9845c5b&chksm=c0fb1461f78c9d772a4d266c3079e59c080fcab4f96344e5e929687c8607356ce93b30268312&cur_album_id=1979310371207184387&scene=189#wechat_redirect

话题源于一位同事的提问:你认为用什么质量指标可以反映项目交付的一个质量?粗看之下有点蒙,质量指标,什么鬼?再思考一下,哦,原来是说交付质量的事,那不是有很多质量指标么?多数和BUG相关,例如BUG数量、Reopen BUG数、BUG解决时长等等,好像都能体现交付质量啊。仔细想想,草率了,我们衡量交付质量,不能只看这些,质量不应该简简单单地缺陷关联上就可以了。再想想,于是有了本文。

 

01 研发过程质量

 

既然不能只看结果,那我们就从源头开始看起吧。首先是需求质量,想要最终的交付质量高,那么源头的需求质量就不能太低,否则后续的研发活动做的再优秀,也不算好,很有可能一开始就跑偏了。我们需要在需求评审的阶段,从用户使用场景的角度出发,通过提问,把需求逐步澄清,并形成验收条件(以实例化的形式记录下来),产、研、测三方共同确认,形成共识,以保证大家对需求的认知不发生偏差,为后续团队正确的做事提供有价值的指导。根据用户故事的基本特性,做到业务可验收、研发可实现、测试可验证、部署可交付。(可参考:从测试看需求

 

再来看看研发过程的质量体现,对于代码质量,开发自有一套玩法,这里不细说。我们主要从更宏观的角度来看,个人认为有两个指标需要关注:构建成功率和缺陷趋势图。

 

构建成功率能很大程度上反映研发的提交质量,如果经常性地编译失败或者自动化测试不能通过,那么就需要引起重视,尝试去了解原因并找出解决方案,因为构建失败意味着最基本的业务保障都出问题了。

 

缺陷趋势图可以很好地反映缺陷的整体变化趋势和处理缺陷的时效性问题。如下图,大体上可以看到迭代缺陷的变化过程,缺陷在迭代中期被集中消灭的比较多,没有拖延到迭代后期,有利于测试的回归和其他方式的验证,降低风险。(关于度量的思考,可参考:度量平台落地实践

 

 

 

再来看看交付给用户的质量评估,这里主要提两个维度:交付时长和缺陷存留。交付时长体现了团队的交付能力,是否可以在用户期望的时间内完成交付,如果时长太长,用户的满意率下滑,你很难说本次交付的质量很高。因为最终评估标准是用户用上了,才能算好。

再来说说缺陷存留。曾经遇到过一个版本,遗留了30多个问题,测试报告也写测试通过,然后发布上线。虽然那些问题都是小问题,但是这么多的遗留问题,如果让用户遇上了,那会产生什么样的糟糕体验?我们可以允许有部分问题延期到下个迭代修复,但总要有个底线吧。

 

02 用户使用质量

如果仅仅从研发团队的角度来看,上面的那些指标好像也够了。但是,我们常说以终为始,交付增量功能并不是我们的终点,用户的使用才是迭代交付的终点。所以我们在评估团队交付质量的时候,也要把这方面的指标加上。

 

线上缺陷逃逸率:指的是线上发现的缺陷。不论你的研发过程再优秀,如果线上缺陷被较为轻易的发现,我们也很难说交付质量很好吧。虽然可以找很多的理由,但还是希望能够去避免类似的情况出现。

 

用户反馈:这里指的是用户的真实反馈,有机会去听听用户的心声。不要总是自我感觉良好。如果用户反馈使用很不方便,或者难以接受,那么我们的交付质量也不可能太好。这点可以和前面提到的需求质量相关联,因为这是需求质量的最直观体现。

 

数据埋点:如果说用户反馈过于主观,那么必要的数据埋点,有利于我们更加客观的去分析交付质量,比如改版前后比较,新功能的点击率,关键路径转化率,错误率,等等。如果你迭代 的功能没人用,谁比较尴尬呢?要注意的是,埋点数据可能会有延迟,参考这类数据时,可以把时间线放长一些。

 

03 非业务特性指标

 

理论上来说,上面那些指标,已经能够比较客观地反馈出迭代的交付质量了。但是在敏捷的场景下,时间短,任务重。有些在瀑布模式下比较注重的东西被忽略了,那就是非产品特性的质量。最典型的,就是可维护性和可扩展性。在瀑布模式下,我们会比较关注这两类的问题,因为交付时间长,如果不注意,后期的运维难度会很大。而在敏捷的环境中,因为交付任务重,加上敏捷提倡重构,所以研发对于代码的维护性和可扩展性并不会考虑太多(都想着会重构,但往往都没有重构的时间),在迭代中也没有预留相应的时间做技术债务的偿还,日积月累,屎山代码就慢慢产生了。

 

 

 

04 小结

以上,从三个方面讲述了关于团队交付质量的一些个人思考。作为研发侧的人员,我们更多的可能关注的是过程质量,如果你对代码或者研发有些追求的话,还需要关注非业务特性的交付质量。对于结果质量,看团队的追求吧。

 

本次话题就聊到这里,下次我们聊什么呢,敬请期待。

标签:团队,迭代,用户,研发,质量,交付,缺陷,评估
From: https://www.cnblogs.com/ceshi2016/p/16800492.html

相关文章

  • 企业团队知识如何管理?来试试这个办法!
    知识是企业获取竞争优势、保持行业地位的重要武器。企业做好知识管理,不仅可以提高员工的工作效率,还可以把企业的经验和案例形成系统的管理,使员工能够从中学习,少走弯路;通过企......
  • iDataCoding个人信用风险评估项目正式发布
    数据实验楼iDataCoding已发布2周,感谢各位伙伴的喜爱与支持!现在迎来第二个项目上线,欢迎大家体验!​​http://idatacoding.cn/project_main?project_id=2​​个人信用风险评估......
  • 成绩综合评估系统的设计与实现
    springbootmybatisplusmysqlmaven光年前端后台管理框架 ......
  • 企业云原生转型,如何解决弹性、运维和团队协同等问题?
    作者:王彬、杏祉尧、黄枫项目背景贵州酒店集团有限公司于2019年2月28日注册成立,是经贵州省人民政府批准并授权省国资委履行出资人职责的省管大一型企业,全资及控股子......
  • 第二季:9.生产环境服务器变慢,诊断思路和性能评估谈谈?【Java面试题】
    第二季:9.生产环境服务器变慢,诊断思路和性能评估谈谈?【Java面试题】​​前言​​​​推荐​​​​9.生产环境服务器变慢,诊断思路和性能评估谈谈?​​​​Linux诊断原因​​......
  • 持续交付峰会 Call For Papers
    本文首发于​​Jenkins中文社区​​持续交付峰会是一个为期一天的活动,将开源CI/CD社区汇集在一起。这一天将包括主题演讲,项目展示和终端用户的故事,以及BoF会议。与同......
  • 持续交付
    持续交付代表着从业务需求开始到交付上线之后的端到端的过程。做持续交付就是提升整个研发体系效率的关键。配置管理、提交管理、构建和部署发布是持续交付的重中之重,是关......
  • 团队结构现代化
    从组件团队到Spotify模型遗留系统中的团队结构  首先,按照技术或职能(functional)来划分团队或部门,无形中增加了组织壁垒,造成了不必要的沟通成本。因为一个围绕用户构......
  • Python实战—单词量评估
    今天,2019年上半年的四六级成绩出来了你过了吗?点击链接进行成绩查询​​http://cet.neea.edu.cn/cet/​​对于四六级的成绩总是几家欢乐几家愁如果这次没过下次一定要加油鸭!......
  • IT江湖的故事 | 第六章-各岗位间相爱相杀,有鄙视也各显神通,关于销售、售前、研发、交付
            销售小赵跟着师父销售老张经过多次历练,风风雨雨,逐渐掌握了对项目把控的技巧、能够更好地跟进项目进展了。可也开始了对其他岗位同学的“鄙视”,当然IT江湖各......