大部分的程序员对自己的代码质量要求还是很高很有追求的，但是在一些情况下则会有意无意地产生一些质量问题：
- 需求沟通不彻底，程序员没有完全理解需求文档上描述的内容；
- 工期紧张，有明确的Deadline需要交付产品，程序员根本来不及自测；
- 程序员过于自信，抱有侥幸心理，想着反正还有测试团队，未经自测的代码草草交付了；
这些质量问题如果很多并且延迟到测试阶段才显现的话，项目就会进入极具风险的内耗阶段。测试人员不断地提交Bug，程序员则不得不花很多时间在寻找Bug和解决Bug问题上，从而导致新需求的开发时间和任务更加紧迫，越来越没有时间自测，从而质量更差，陷入恶性循环。
其实在项目质量管理中，为了保证项目质量，我们不得不付出两种类型的成本：
- 第一种是事前进行预防的成本，比如需求的顺畅传递、制定合理的开发计划、编写详细的自测案例执行等；这类成本的花销是防患于未然；
- 另一种是事后为了弥补的成本，比如大量的测试人员介入、发现Bug太多来不及修复从而加班加人等；
经过实践统计，完成相同工作量的事情，第一种预防性的成本投产比要比第二种弥补性的更高更有效果。因此，在项目质量把控中，预防优于检查，一次性把事情做对是成本最低的方式，而管理的重点目标对象则是我们的程序员，而非测试人员。
一、事前防止
在项目开始的时候，项目管理人员就应该为团队明确交付的质量标准。如果这个质量标准很模糊，或者说只要系统能跑就行，那么就会出现各种各样难以界定的质量问题，因为我们缺乏对质量的详细定义和输出口径的一致性认识。
如下是一个成熟的业务线要求的质量标准。
质量标准的定义示例
为了能够让团队认同和完成这些质量标准，我们可以通过如下的活动方式进行。
质量保障手段
当然，产品的交付质量保证是有代价的，理论上付出的代价越多，产品质量就越好。但是不同的业务都是处于不同的复杂的市场环境中的，有的业务刚刚建立，要求交付速度要快，对质量可以放宽限制；有的业务已经很成熟，要求稳定第一。那么，不同情况下的质量制定标准就注定是不同的，这个需要项目管理人员根据具体情况进行定义。
二、事中监控
在有了明确的质量交付标准之后，为了使团队执行方向不跑偏，时刻了解和把控项目的质量，项目管理人员需要一些措施来进行监控。
质量活动图
在如上的活动进行中，每个活动的结果都能帮助我们诊断当前项目的质量情况，它们会对最终交付的质量标准有影响。如果发现这些活动结果数据异常，那就要进一步分析造成的原因，并制定解决方案。比如到了项目测试环节，发现Bug数量激增，进入了恶行循环，那就要看看是否是开发阶段出现了问题：
- 团队是否新人较多？
- 需求是否没有传导到位？
- 开发没有时间自测？
- 自测案例编写有问题，无法覆盖所有变更逻辑?
如果出现了以上问题，项目管理人员就要及时干预，避免进一步陷入恶性循环，比如可以：
- 组织培训，给新人讲解代码和需求；
- 适当放缓推进速度，给开发人员更多的时间进行自测；
- 组织案例评审，或者使用工具扫描单元测试的覆盖率等等；
这些措施也许不是一次两次就能生效的，需要坚持改善，才能将项目质量从深渊中拉出来重新步上正规。
三、事后总结
总结和复盘是任何个人和团队成长的最好方式，当项目上线后，迭代回顾会、Bug分析会都是项目管理人员搜集一手信息帮助改进项目管理工作的重要方式。
在迭代回顾会上，由主持人带领大家回顾这一迭代经历的各种事情，做的好的，做的不好的都要分析其原因和改进措施，记录下来并应用到下一轮迭代中，这也是团队进行磨合的过程。
在Bug分析会上，大家可以对所有的Bug进行分类，看看究竟是什么样的Bug最容易犯，造成Bug的原因又是什么，如此大家对系统代码和业务逻辑也能加深理解，在后面的工作中，带着这些经验再进行项目工作会更加得心应手，提高质量。
最后，搜集下历次迭代的Bug趋势，绘制成趋势图，更有利于项目人员和团队人员清楚质量的发展趋势，并以此预测和准备下一轮迭代的资源。
网友评论