谈开发质量和过程管控

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

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

在paas平台搭建到一定程度后,可以看到企业内部可以复用的各种IT能力逐步成型,这既包括了各种技能效劳能力,也包括了事务效劳能力。构成了一个很多的可同享的效劳能力支撑库。而新的应用体系有必要要基于已有的各种IT能力资产进行开发,加强复用,下降重复开发。这也是我们说的后续应用体系开发可以快捷反响,逐步下降开发本钱的一个原因。可是很多时分面对开发厂商固有的模式,推进上往往有必要有强壮的执行力。

平台+应用,一方面是通过平台完成灵敏性和本钱下降,一方面是通过平台约束上层应用选用统一的开发框架,技能架构和规范规范,从而加强后续对应用的质量和过程管控能力。

关于开发厂商的研发过程,给出一个最简略的基于CMMI思路的一个研发过程图如下:

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

关于甲方驱动的研发过程管控能力,可以总结为三大类,详细如下:

可固化:主要是指规范,流程和相关东西的制定和选用。

可管控:主要是值项目管控过程当中的评审,决策,交流汇报,问题风险管理和监控预警机制。

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

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

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

关于需求层面,我们要留意往往不是简略的统一需求方案,特别是触及到跨多个应用体系的方案制定的时分,需要的不只仅是需求方案,同时包括了技能方案。这个方案会约束高层的的一些整体架构设计和完成思路方面的内容,以防止后续各个应用在完成过程当中走偏。

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

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

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

相关阅读