怎样监控敏捷型软件项目质量？【续】-诊断会

本期话题：怎样衡量监控敏捷型软件项目质量（指标？工具？）【续】

一、背景说明

受诊人：有实体产品的项目一般都有成熟的质量管理体系，成熟通用的标准要求，但软件项目一般偏迭代和敏捷，没找到有成熟的度量体系指标，做为项目经理如何直观的监控到项目的软件产品的开发质量，有哪些好的通用的指标或管理工具。

公司正在认证CMMI4，正在确定项目度量项，暂时制定了工作量、偏差、缺陷几项指标，感觉无法反映出项目产品实际运行的质量情况。

二、补充：

看了一下精华，大家聊的很嗨，简单统计了下，精华里面提到最多的指标是bug数，bug数可以作为一个指标，也可以将bug分为不同的等级来标注。但是即使这样，也无法把bug数与不同层级的开发人员相关联，不过这个不是我要讲的主要观点。

我要讲的是，精华中大部分提到的是质量控制，而忽视了质量保证。

CMMI 是企业实现质量保证的重要部分。

ISO9000 质量保证8个原则 ： 以顾客为中心、领导作用、全员参与、过程方法、管理系统方法、持续改进、基于事实的决策方法、与供方互利关系（摘自高项第三版P314）。

具体的技术层面的实际中，QA QC的作用比较重要。讲些实际的例子：

1. 做过开发的应该知道，每个公司都会有开发规范。这些是从制度上规范代码的一致性，虽然无法保证这样写出来的代码没Bug，但从公司层面，代码一致性及各开发人员相互对彼此代码熟悉对公司有利。

2. 代码走查，代码评审

代码质量的好坏跟开发人员的水平有相当大的关系，大公司可能会严格定义好相关功能及开发逻辑。但小公司一般还是给开发很多自由的空间。

定期代码走查的制度会让相关开发人员知道，我的代码是会有别人来看的，不能乱写，新人还好，都是老人了被人挑错面子上可能没那么好过。

代码评审：在关键模块发布前我们会集中做代码评审。

因为我们发布的东西是给互联网用户使用的，无法预估到使用量。质量差的代码，少量用户就要占用大量资源，并且可能导致上线失败。但一般经过质量评审的代码，极少资源可以支撑海量并发。

3. 公司学习进步机制

技术这块，可能做错过几次也能进步。但这样的进步成本太大，我们会组织相关技术讨论会，将之前踩过的坑拿出来分享，不但如此，直接模拟的方式会让大家更加印象深刻。

A类写法10个用户访问可以拖垮一台中等服务器；

B类写法同样硬件可以支撑上万用户同时访问。

这种对比会让新手或者没踩过坑的成员印象深刻。

4. 完整测试流程

包括自动化单元测试、集成测试、系统测试、用户测试等几个部分

但保证的过程是要将质量暴露在内部。

暴露在用户端基本就失败了，小公司生成不易，如果一直让用户觉得你们做的产品有问题，那么很可能对公司战略造成影响。

结语：

质量控制的同时也要关注质量保证。

讨论内容整理 ：

【以下关于项目团队管理的内容都来自于希赛「PM创造营」群内诊断会，由@小M妹妹 整理，由以下小伙伴分享完成@Jacob@mx-南京-软件@小糊涂仙-重庆-物联网@喵咪咪喵-天津-互联网】