谈开发质量和过程管控

这里站在甲方信息化部门的角度谈下对开发厂商质量和过程的管控话题。

在构建企业私有云paas平台的时候，里面有一个重要的内容就是应用开发框架，这个应用开发框架可以理解为包含了应用技术架构（分层架构，开源组件选择等）和各种规范约束（编码规范，接口调用规范，UI规范）的一个空框架。各个开发厂商都必须遵循同样的一套技术架构来开发应用，这个不仅仅是解决开发的应用能够部署到paas平台的问题，更多的是解决后期的运维和管理问题，也进一步加强了各个开发厂商之间的可替代性。在传统的应用软件招标中往往我们只强调了开发语言和数据库使用什么，而实际应用内部的技术架构，采用的技术组件仍然由开发商控制，对于甲方来说完全是一个黑盒，不利于后期的质量和过程管控。

在paas平台搭建到一定程度后，可以看到企业内部可以复用的各种IT能力逐步成型，这既包括了各种技术服务能力，也包括了业务服务能力。形成了一个很多的可共享的服务能力支撑库。而新的应用系统必须要基于已有的各种IT能力资产进行开发，加强复用，降低重复开发。这也是我们说的后续应用系统开发能够快捷反应，逐步降低开发成本的一个原因。但是很多时候面对开发厂商固有的模式，推动上往往必须有强大的执行力。

平台+应用，一方面是通过平台实现敏捷性和成本降低，一方面是通过平台约束上层应用采用统一的开发框架，技术架构和标准规范，从而加强后续对应用的质量和过程管控能力。

对于开发厂商的研发过程，给出一个最简单的基于CMMI思路的一个研发过程图如下：

那么站在甲方的思路，要加强开发过程和质量管控的最好的方式就是加强对需求方案和验收发布两端的强管控能力，对于研发过程中加强里程碑评审的能力。对于项目管理而言则加强PMO对项目群管理的能力。在支撑域中最基本的配置管理和变更管理是必须的，要注意到甲方对配置管理的层面往往高于单个应用，往往涉及到的是更加全局跨系统的配置和变更管理能力，端到端的需求全程跟踪和闭环管理能力。

对于甲方驱动的研发过程管控能力，可以总结为三大类，具体如下：

可固化：主要是指规范，流程和相关工具的制定和采用。

可管控：主要是值项目管控过程中的评审，决策，沟通汇报，问题风险管理和监控预警机制。

可量化：主要是指研发管理中的基础度量和KPI指标体系的建立

可以讲做好上面三个方面的内容是甲方逐步深入研发过程管控的一个基础。甲方的研发质量和过程管控不是要替代单个应用开发商的研发项目管理和质量管理，而更多的目的是类似CMMI三级一样形成一个适合甲方管理的组织级的过程和管控机制，从单个应用厂商本身的成熟还不足够，更加重要的是组织级的基线和成熟度。

对开发厂商的管控逐步打开内部的黑盒，但是要注意不是完全接管，而是加强关键点的里程碑评审和结构化决策机制。基于这个思路，另外再提下研发过程管控的一些关键点。

对于需求层面，我们要注意往往不是简单的统一需求方案，特别是涉及到跨多个应用系统的方案制定的时候，需要的不仅仅是需求方案，同时包括了技术方案。这个方案会约束高层的的一些总体架构设计和实现思路方面的内容，以防止后续各个应用在实现过程中走偏。

加强对两端的管理，包括需求方案和验收发布两端的管理，而弱化对厂商开发内部的管理，对于开发厂商内部的过程管控只需要加强里程碑监控和评审即可。以做到最基本的闭环管理。对于开发商内部的研发过程重点是制定相应的标准规范和约束，加强QA管控。

配置管理要形成企业级的配置管理库，各个厂商最终的研发过程资产都必须入库，要加强各种配置审计工作，同时源代码配置管理也需要逐步深入管理，方便后续的统一发布和部署流程的对接。而取代原因的开发厂商在验收的时候才一并提交验收资产的模式。

在纵向团队的基础上，可以考虑形成各种横向的联合性质的虚拟团队。包括易用性团队，性能优化团队，技术专家团队，业务专家团队等，以专家团队的方式来解决各个应用可能存在的共享问题，并且在解决后逐步上升到企业知识库中。形成组织级的度量和KPI体系，切实用数据说话，通过数据分析形成持续改进机制。这一点往往是最难的，但是又必须执行，至少需要做到定性+定量的开发商考核和评估机制。

文章来源：人月神话（新浪博客）