Navid的质量框架

2022-03-04   出处: BY林子  作/译者:林冰玉

本文首发于个人网站「BY 林子」(https://www.bylinzi.com/2022/01/27/navid-quality-pillars/ )。

Navid Nader-Rezvani ( https://twitter.com/navidnader )根据她在敏捷团队的质量咨询经验,提炼出一个敏捷质量框架,在书籍《An Executive’s Guide to Software Quality in an Agile Organization: A Continuous Improvement Journey(敏捷组织的软件质量持续改进之旅)》 ( https://www.amazon.com/Executives-Guide-Software-Quality-Organization-dp-1484237501/dp/1484237501/ )中有详细介绍。

这个框架从五个维度来描述敏捷质量需要关注的内容,现将这个框架简单分享给大家,如果想了解更多详情,请自行阅读原书。

Navid 提出的质量框架也叫 Navid 的质量支柱(NQPs,Navid’s Quality Pillars):

  • 支柱 1:团队建设和敏捷实践(Pillar 1: Team Development and Agile Practices)

  • 支柱 2:代码质量和架构(Pillar 2: Code Quality and Architecture)

  • 支柱 3:敏捷生产力和质量赋能利器(Pillar 3: Agile Productivity and Quality Enablers)

  • 支柱 4:非功能领域能力(Pillar 4: Agilities)

  • 支柱 5:客户成功(Pillar 5: Customer Success)

支柱 1:团队建设和敏捷实践

图片地址:https://learning.oreilly.com/api/v2/epubs/urn:orm:book:9781484237519/files/images/465806_1_En_5_Chapter/465806_1_En_5_Fig1_HTML.png

这根支柱主要有两部分内容:敏捷全功能团队的建设和标准化敏捷实践的开展,其中包含不同角色的职责培养和人员能力建设相关实践,强调敏捷是一个团队的活动,而质量需要团队来负责。

支柱 2:代码质量和架构

图片地址:https://learning.oreilly.com/api/v2/epubs/urn:orm:book:9781484237519/files/images/465806_1_En_5_Chapter/465806_1_En_5_Fig2_HTML.png

这根支柱从代码和架构对软件质量影响的角度,强调代码的整洁度和架构的模块化有利于采用更优的测试策略和获得更高的质量,提倡静态和动态的代码分析、遵循一致的代码规范等。

支柱 3:敏捷生产力和质量赋能利器

图片地址:https://learning.oreilly.com/api/v2/epubs/urn:orm:book:9781484237519/files/images/465806_1_En_5_Chapter/465806_1_En_5_Fig3_HTML.png

支柱 3 主要是关于采用流水线实现标准化流程和部署基础设施的配置,跟高度的自动化(测试)结合,同时严格执行质量门禁(DoD),以获取更高的效率和质量。

支柱 4:集成各种非功能领域能力

图片地址:https://learning.oreilly.com/api/v2/epubs/urn:orm:book:9781484237519/files/images/465806_1_En_5_Chapter/465806_1_En_5_Fig4_HTML.png

支柱 4 提倡要集成各种非功能领域能力到产品开发过程中,需要团队对所有非功能质量负责。通过定期评估组织的各项非功能领域能力,并根据评估结果排出改进优先级,制定出相应的改进行动项,以实现持续的非功能领域能力的提升。

支柱 5:确保客户的成功

图片地址:https://learning.oreilly.com/api/v2/epubs/urn:orm:book:9781484237519/files/images/465806_1_En_5_Chapter/465806_1_En_5_Fig5_HTML.png

最后一根支柱是确保客户的成功,也就是在整个软件开发过程中时刻要铭记客户的诉求,从提升客户满意度的角度考虑所做的任何一项工作。建议从以下几个维度关注:

  • 客户净推荐值(NPS, Net Promoter Score)影响因素:修复的缺陷数、评价故障恢复时间(MTTR,Mean Time to Recover)、定期处理客户关注的热点问题等

  • 客户参与迭代评审、新特性和关键 bug 的验收、以及必要的探索式测试等

  • 产品升级、新产品的安装等相关的客户体验

  • 影响总拥有成本( TCO, Total cost of ownership) 的主要因素(如:部署)

写在最后

之前有项目借鉴 Navid 的质量框架帮助团队进行持续的质量改进,获得了不错的效果。

该框架里的五根支柱涵盖到了敏捷全功能团队、全生命周期的持续测试、持续集成快速获取反馈、关注业务价值等几个方面,不一定是最完备的,但的确可以作为敏捷团队质量改进的一个参考。

最近在研究质量体系相关内容,对这个框架又进行了研读和分析,因此也分享给朋友们。如果大家有对这个框架的反馈或者其他体系化相关内容,欢迎给我留言。

更多关于 Navid 的质量框架的内容,以及她给敏捷组织质量持续改进的建议,请参考阅读《An Executive’s Guide to Software Quality in an Agile Organization: A Continuous Improvement Journey(敏捷组织的软件质量持续改进之旅)》 (https://www.amazon.com/Executives-Guide-Software-Quality-Organization-dp-1484237501/dp/1484237501/)。

更多关于质量体系化的内容,欢迎参考我的如下文章(点击以下文章标题可直达文章内容):

本文首发于个人网站「BY 林子」
(https://www.bylinzi.com/2022/01/27/navid-quality-pillars/),
转载请参考版权声明 (https://www.bylinzi.com/copyright-statement/)。


声明:本文为本站编辑转载,文章版权归原作者所有。文章内容为作者个人观点,本站只提供转载参考(依行业惯例严格标明出处和作译者),目的在于传递更多专业信息,普惠测试相关从业者,开源分享,推动行业交流和进步。 如涉及作品内容、版权和其它问题,请原作者及时与本站联系(QQ:1017718740),我们将第一时间进行处理。本站拥有对此声明的最终解释权!欢迎大家通过新浪微博(@测试窝)或微信公众号(测试窝)关注我们,与我们的编辑和其他窝友交流。
152° /1520 人阅读/0 条评论 发表评论

登录 后发表评论