请选择 进入手机版 | 继续访问电脑版

湖南新梦想

 找回密码
 立即注册
搜索
热搜: 活动 交友 discuz
查看: 97|回复: 0

互联网项目如何做好质量管理(二)

[复制链接]

3425

主题

3825

帖子

1万

积分

论坛元老

Rank: 8Rank: 8

积分
13492
发表于 2022-8-8 16:37:45 | 显示全部楼层 |阅读模式
 [url=]质量管理[/url]的方式方法
  那怎么来做好质量管理呢?从我自己的理解,我梳理了十大要点:
  一、明确目标
  项目有项目的目标,质量管理,同样有质量管理的目标。
  对于质量管理来说,目标包括目的和标准。质量管理需要有明确的目的;质量管理需要有明确的标准。
  1、质量管理的目的
  学过PRINCE2的朋友可能都知道,P2的7大主题之一就有质量主题。质量主题的目的是定义并实施项目用来创建产品并验证其符合目的的方法。
  质量是产品、人员、流程、服务和/或体系的特质和其内在固有或外在赋予特点的综合,显示其达到期望或满足陈述的需求、要求或规格的能力。
  质量的焦点在于产品达到要求的能力。
  所以说,进行质量管理的目的要清楚,而且也不言而喻,就是为了使得产品达到所设定的要求的能力。
  2、质量管理的标准
  谈到标准,仅从公司的角度来说,我想每个公司都会有其自身的质量管理体系。所谓质量管理体系就是项目/产品或组织的一整套质量标准、步骤和职责。这里我想分研发期的标准和正式上线发布的标准。
  (1)研发期的标准
  研发期的标准,是在符合整个公司的质量管理体系下,由项目组根据实际情况来定义的一个标准。
  之所以要定这个标准,是因为项目在研发期的时候,因为项目有大量的系统功能要进行开发。从[url=]项目管理[/url]全局更优的角度出发,不太可能做完一个版本就绝对稳定一个版本。这是由[url=]互联网[/url]产品或游戏项目本身所决定的。尤其是游戏项目,系统与系统之间才存在强耦合,强关联或依赖关系,就更没有办法在项目初期、中期做到绝对的质量稳定。
  项目经理需要有一个清晰的认知,迭代目标的制定,就是为了交付质量更加可靠的版本。所以,我们评判一个版本的质量达标与否,不是仅仅只看这个版本的bug修复情况,是看的整个全局,包括但不限于需求的实现完整度、资源的合入情况、开发的深度参与、体验问题的修改、bug的修改。
  (2)上线的标准
  上线的标准,通常是指要满足正式发布时,需要满足的标准。但这些标准并不是等到产品正式上线的时候才会进行,而是从项目立项之初就从多个阶段来进行保障。
  鹅厂的质量管理体系(以游戏项目为例)称之为TDR评审指引及标准。TDR的全称是Technical Design Review,称作[url=]技术[/url]设计评审,分别有TDR1、TDR2、TDR3。针对项目的不同阶段,侧重点不一样。
  TDR1,策划(产品)重点是游戏的设计方向、核心玩法、题材包装等;美术重点评审的是游戏的整体定位风格及各细部风格是否已经确认完成,是否符合产品定位,是否有高品质同类产品的竞品供对比参考;程序重点评审的是系统架构设计是否合理。通常是在项目正式立项并确定时。
  TDR2是根据不同的游戏品类所需要,主要是针对程序的技术设计评审。大多是在demo版本开启的时候进行。
  TDR3重点针对的就是程序、[url=]测试[/url]、安全和政策。程序重点评审的是客户端和服务端的性能、适配、CPU和内存、crash率、弱网这些主要指标;测试则重点评审的是客户端性能基线、内存消耗、CPU占用率、帧率、适配、弱网、crash率、服务器性能、容错容灾;安全方面,重点评审的是客户端安全(是否加密)、游戏逻辑安全、敏感词接入等;政策主要是版号、备案、实名制。
  到TDR3的时候,基本上是需要对外测试(上线)的时候,要达到这个标准,才能申请资源进行测试。
  二、确定范围
  这里的范围是指质量管理的范围。
  具体到某一个版本来说,在版本正式进入开发阶段,是需要确定范围的。也就是说要明确清楚具体做的需求是哪些,范围确定了,才更好从源头狠抓需求的质量。对于质量管理来说,[url=]需求管理[/url]做的好与不好,也是直接影响质量管理的好与不好。
  项目经理需要抓源头,让需求输出的质量更高,进而最后交付的版本质量也会更高。比如我们曾经就出现过典型的案例,某个需求输出本身的缺陷:需求逻辑不清晰,前后后有矛盾。这样一来,需求评审的时候就直接暴露出来这个设计缺陷。假设需求直接进入开发,则对质量的影响就更大了。所以,从需求源头开始,就需要对需求的质量进行管理了。
  当需求的源头明确了,对开发和测试来说,目标则会更加的明确。关于需求的源头,抓需求质量的输出,在需求管理的篇幅里面有详细介绍。
  三、对需求进行测试和评审
  对需求的测试,是[url=]软件测试[/url]领域里面提到的一个重要策略。但这对测试资源的依赖或要求是非常之高的。事实上,很多互联网项目或游戏项目,没办法做到对需求进行测试。
  但为确保需求理解的一致性,需求评审在整个研发流程里面是必不可少的。不管需求的体量如何,在需求正式进入开发阶段,需求评审是必选项,而且相关负责人都需要参与。
  作为项目经理,不要认为需求评审(或宣讲)会耗费很多时间,不如直接发给开发人员进行方案的设计和工作量的评估。如果这么想了,质量管理做起来会非常的痛苦。因为这样做之后,很有可能会导致信息的不对称,使得执行时出现理解的偏差,结果做出来的产品不符合预期,引发各种问题。
  所以,需求评审,则可以有效地保障需求功能点的遗漏,减少开发过程中的补丁,让整个设计在源头更加完整。
  四、狠抓设计方案和WBS
  质量是设计出来的,不是测试出来的。每个需求或版本对应的需求评审完成之后,需要和团队达成共识。一些大的需求或者复杂的系统,在正式启动编码时,需要输出详细的设计方案。这是和团队达成的共识。
  或许写设计方案会耗费一定的时间,但这对整个质量管理来说至关重要。设计方案的输出,不仅仅只是输出,更需要进行论证和设计方案的评审。这是非常重要的环节。
  对于设计方案,在项目启动之初的时候,我们还会请部门的一些专家一起进行论证和评审,目的就是确保设计框架没有大的缺陷。
  设计方案评审确认后,是需要输出详细的工作量评估,也就是WBS。在做WBS的时候,我们有一个要求,即输出的详细工作量评估需要细化至0.5-2d的颗粒度。通常都是0.5d、1d,如果分解的任务里面,确实是有2d的工作量,还需要做特别的说明,否则就需要重新评估。
  之所以要细化,是因为颗粒度细化的越细,说明具体执行人员对需求的理解和思考就更到位。结合设计方案,对需求的细节开发就更加有利。
  正所谓磨刀不误砍柴工,多花些时间在设计方案和详细的工作量评估上,远比需求评审完直接开干而有利于质量管理。
  五、接入一切可能的辅助工具
  很多公司除了质量管理体系标准,还会有各种辅助工具,用来更好的辅助和发现代码的质量。
  代码健壮性、可扩展性越高,代码的质量就越稳定,产品的质量也就越稳定。
  对于我们来说,在项目启动之初,就会考虑接入公司的各种工具,比如代码扫描工具、crash上报平台、日志上报系统。
  在有利于质量管理的前提下,我个人是倾向于尽可能的接入。当然并不是为了接入而接入,需要思考是不是真的对质量管理有利。
  代码扫描工具,可以在编译阶段就发现各种告警、报错,便于开发人员及时处理,防止出现大规模[url=]单元测试[/url]时出现异常。
  日志上报系统,接入上报平台之后,还需要项目侧进一步完善日志打印,这样有利于问题的排查。当出现一些问题,尤其是一些偶现问题的时候,有比较健全的日志系统,就方便快速定位和排查,并深入地解决。
  辅助工具,不一定是每个公司都会有的,那如果是一些没有这个条件的,可以考虑搭建一个或者找一找开源的工具。
  辅助工具,除了公司已有的以外,如果是有条件的项目,还建议提前搭建[url=]自动化测试[/url]工具。
  自动化测试工具的构建,是有利于节省测试资源,并提前发现问题的。对于互联网产品或游戏项目来说,大多是增量开发。
  此前已经开发完的需求或功能,在搭建自动化测试工具之后,我们可以在版本自动构建阶段就使用自动化工具跑起来,提前发现问题,保证版本质量的稳定。



回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

QQ|Archiver|手机版|小黑屋|湖南新梦想 ( 湘ICP备18019834号-2 )

GMT+8, 2022-10-3 13:47 , Processed in 0.040035 second(s), 19 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

快速回复 返回顶部 返回列表