工程化的软件开发管理方法研究

张萍

随着移动互联网、物联网、大数据、云计算等信息技术的发展，人们对软件产品和软件服务日益增长的需求与相对缓慢的开发交付能力之间的矛盾愈发凸显。本文从软件开发的本质属性谈起，从软件项目管理、软件过程改进、软件行业对CMMI的曲解等方面探讨工程化的软件开发方法。

随着移动互联网、物联网、大数据、云计算等信息技术的发展，信息化不断跨越行业间的壁垒，快速开发及交付高质量的软件产品成为企业管理中切实的需求。

一、软件开发属性

软件开发的不可见性是软件的固有属性，不会因软件项目的不同而变化，该属性使得软件的开发难度增加，所以需要有科学的方法去管理软件开发的过程。

二、软件项目管理

提及软件项目管理，不免会提及业内较知名的PMP认证。PMBOK源于软件项目的管理实践，将软件项目管理分解成5大过程组10大知识领域，如图1所示。

PMBOK其实按项目的时序进展，可细分为从制定项目章程开始，到结束项目阶段的49个过程。项目经理要把握阶段并确保每一阶段的交付物，把控好项目节奏，以达到项目完成，相关方满意的双重目标。

三、软件过程改进

广义的过程一般包含：过程、人、技术三要素。我们可以把技术看做武器、工具，对于人，我们要考虑其资质、天赋，而过程我们可以看做为武功秘籍，如图2所示。有天赋的人，拥有了合适的武器和武功秘籍，才能成为百战不殆的高手，软件开发也如此。

软件过程改进，顾名思义，改进的对象是软件过程，目的是使得软件开发过程的绩效持续改进。若是将软件开发过程类比成制造业的产品生产，软件过程改进则可视同为是对产品的生产流水线的设计、建设、维护、升级及优化。

软件开发行业，鲜有国家标准或地方标准，最多有一些国家的推荐标准，为了促进软件开发过程的标准化，更好地进行软件过程改进，我们在积累软件相关活动的经验教训时，形成了不少可以参考的模型和方法，其中最有名当属CMMI（能力成熟度模型集成）了。但企业实践中，不少人甚至从事软件行业多年的工程师都对CMMI都仍有一定的曲解，例如：

（一）将CMMI 视为一种重型软件过程

实际上CMMI 模型首先要求一个软件企业应该自己先定义适合本软件企业的软件过程，并应不断优化改进该过程。但是，我们往往在实践中，为了迎合咨询企业的基于CMMI 模型的“证据验证”评估方法，刻意准备了大量文档化的证据，以致CMMI 被视作必须在软件项目管理中必须满足的某种标准（这一点类似于ISO系列标准的贯标审核）。显然，这是对CMMI 模型目标和使用方法的曲解。

（二）将CMMI作为检验软件过程优劣的标准

由于各个企业所处的环境、目标等方面的差异，过程改进对于不同企业的意义也不一样。所以，CMMI的成熟度等级不适用于脱离企业环境直接横向比较；同样的，即使处于同一CMMI成熟度级别的，也并不能说明这些企业的研发能力一样。

（三）将CMMI 与其他软件过程或者软件开发方法的进行比较

不少人经常会将CMMI 作为敏捷方法的对立面，试图来解释和说明敏捷方法的优势。实际上，这种场景下所谓的“CMMI 方法”已经不是一个过程改进的参考模型了，而是特定软件企业为了满足CMMI 评估需要所定义出来的具体的软件过程。显而易见的，這是再用这个狭义的软件过程的缺点视作整个CMMI 模型的缺点是不合适的。

五、工程化管理软件开发

为了满足工程化管理软件开发的需求，不仅要关注软件项目本身的管理，还要关注软件过程的改进。工程化管理软件开发需要在实践中以系统性的、规范化的、可定量的过程化方法去开发和维护软件，以及把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合，从而有效地为工程化管理服务。

随着业务不断发展的迫切需求，无论信息化系统，还是软件管理方法，模式都需要不断随之演进发展。

去中心化，关注安全，XaaS，即刻运维，即时开发……这些业务和需求的演进，都催生了DevOps的出现，它促使软件开发与其他工程的更集成，更规范。图3是典型的Devops软件持续集成过程。

Devops是一种文化，一种方法论，是工具链的高效集成。它从解决方轮子困局：各项目长期急于赶工，积累大量技术债；以及谷仓困局：各部门重复造轮子，资源共享困难，以业务平台的需求—聚焦数据应用为基础，重点解决业务平台的研发规范化、组件的复用性、共性能力服务化、优化开发测试以及运维流程等痛点问题，将开发和运维打通起来，成为一个大闭环：计划→开发→构建 →测试→发布→部署→运维→监控→数据收集→计划，通过这个闭环，加之开发和运营团队的合作来支持软件产品的迭代开发和持续交付的能力，从而缓解人们对软件产品和软件服务日益增长的需求与相对缓慢的软件产品和软件服务开发能力之间的矛盾，最终达到提高研发效率，实现快速交付等目的。

作者单位：中通服咨询设计研究院有限公司