一聊聊软件研发质量管理 _头脑风暴

二十八、结束语
管理就是要可衡量。能量化尽量量化。不能量化尽量细化，不能细化尽量流程化。——彼得﹒德鲁克
管理如此，质量管理亦是如此。
对于一个千人规模的研发组织，每天会产生大量的数据，如：代码提交、编译构建、单元测试、自动化测试、环境变更、版本发布等。
如何从纷繁的数据中沙里淘金，提取并加工成对于质量管理有用的信息，从而支撑研发过程改进和管理决策，成为了我们亟待解决的课题。
一、模型建立
通过对一些经典软件质量模型（模型、Boehm模型、模型）的研究，并结合在苏宁金融开展的研发质量管理实践，我们提炼了一套“研发质量评价模型”，其整体框架结构和体系支撑如下：
在不同的领域，有不同的工具支撑整个业务流，比如：项目是通过ITP系统来管理的，它涵盖了立项管理、开发管理、上线管理、结项管理等项目全生命周期。不同的工具通过底层数据进行拉通，形成完整的IT解决方案。
评价模型由产品质量、过程质量、持续改进质量、成果转化质量4大维度组成。通过对维度进行细化，又细分为9个子维度、16个评价指标，全方位客观地评估各研发中心的质量管理水平。
二、模型应用
根据木桶原理，一只水桶能装多少水取决于它最短的那块木板。
研发质量评价模型就是要识别出整个组织的共性问题及能力短板，由SQA牵头驱动组织级的过程改进，进行能力补齐。
1、研发质量评价结果样例
2、雷达图识别短板
通过雷达图，我们可以方便地识别在“缺陷修复”这个指标上整个组织是存在短板的，需要进行专项改进。
3、柏拉图聚焦改进
借助质量工具，我们绘制了柏拉图。根据二八原则，发现流程流转不及时、外部因素无法联调、新员工不熟悉代码这3个原因是导致缺陷修复得分偏低的主要原因。问题的症结找到了，问题自然可以迎刃而解了！
三、模型演进
研发质量评价模型不是一成不变的，它有一个逐步演进的过程。我们的模型已经初步完成了从1.0到2.0的转变。
2.0相对1.0版本，使用探索性因子分析法（EFA）对指标维度进行了重新亲和，使评价维度更为合理。同时，增加了质量保证及质量控制的过程性指标，从而提高了模型评价的实时性和效用。
上医医未病之病，中医医欲起之病，下医医已病之病。从结果性的数据描述，到对过程数据及时分析，最终建立预测模型支撑组织决策。
四、小结
数据是为管理做服务的，但数据本身不能脱离研发实际。庞大的指标体系和盲目的数据分析都是不可取的。
发现问题、解决问题、不断提升组织能力才是研发质量评价的初衷。
任何事物都有两点，即都有优点和缺点、成绩和错误，这是辩证的唯物主义思想。研发过程也不例外，总有做的好的和做的不尽如人意的地方。质量人员通常会用“红黑榜”进行晾晒以达到一定的改进效果。那么反思己身，质量人员在研发质量管理中又存在哪些典型的“红与黑”呢？
五、红：追根溯源黑：头痛医头
质量管理一个重要职能就是要解决质量问题，就好像医生的职责天生就是要解决病人的病痛一样。好的医生通过“望闻问切”详细了解病人的病情，对症下药彻底根治病情；孬的医生往往头痛医头、脚痛医脚，短时间能收到效果，但总断不了病根。
举个例子，近期小Q在审计时发现，很多项目不执行代码评审活动，导致转测质量很差。于是他要求项目组后续整改，必须提供代码评审记录。项目组也很配合地做了“整改”：欺负小Q不懂技术，拿一些其他项目的代码评审记录糊弄一下。小Q也不深究，对改进效果沾沾自喜。

一 聊聊软件研发质量管理

一聊聊软件研发质量管理