案例久其软件 CMMI V2.0助力久其软件八项提升

最近久其软件通过CMMI V2.0五级评估，从2002年第一次CMM评估算起，这是久其第五次评估了。

作为一家技术型的企业，久其一直致力于提升自已的技术水平和研发能力。公司在成立早期，在只有数十人的时候，就接触到CMM先进的管理思想，逐步将CMM和后来的CMMI模型实践践行到产品开发和项目管理过程中，可以说，CMMI体系和久其的几代软件平台彼此见证，又相互促进。

在CMMI实践中，久其也走了一些弯路，但是在摸索中我们走出了自己的路，让CMMI在久其研发模式下落地。虽然还存在各种问题和挑战，但我们今天取得的成就验证了CMMI的价值。

久其软件的研发模式特征

今天的北京久其软件股份有限公司（股票简称：久其软件；股票代码：002279）已经是一家中国领先的管理软件供应商。主要面向政府部门和大型企业集团提供电子政务、集团管控、大数据、互联网等综合信息服务及行业解决方案。

可以说久其面向的客户都是信息化应用程度较高的群体，具备如下特点：

1)业务复杂且多变

客户项目基本都是“产品研发+大规模定制”的模式，一般70%的产品功能是相对标准化、可复制的模块，30%需要根据客户的行业特点、业务特征、管理风格、应用系统运行生产环境等因素进行客户化定制。

2)项目实施面临的环境复杂多变

项目要面临复杂的生产运行环境，需要具有多种环境适用性、兼容性，同时还要面对复杂的应用集成，实现与客户现有系统或其他应用开发商的第三方系统集成等等。

3)客户对交付项目的过程管控相对较强，参与度较高

基于上述情况，公司在研发管理上基本采取的是产品型或平台型研发和客户化定制研发两种方式，客户化定制开发项目也是基于内部的产品平台面向具体客户开展的定制开发。这两类项目分别由不同的研发团队来承担，即产品或平台研发团队和客户化定制交付团队，因此需要在两个团队之间建立例行化、规范化的沟通机制，而资源的长期紧缺又要求公司从战略角度精简研发过程以提高效率，比如从强化产品总体设计、简化功能详细设计、简化文档模板和某些要素等方面。

结合公司业务模式的不断变化，多年来研发过程也在CMMI的多次改进、评估轮回中不断改进，体系的不断完善也为久其带来了可喜的变化。结合当前研发特点，CMMI特别是2.0的导入给我们带来下面八个方面的变化：

培养了公司研发团队和客户化定制交付团队的规范意识，加深了研发团队、客户化定制交付团队对标准化研发过程流程和相关项目管理知识的理解；

统一了研发团队之间、研发团队与客户化定制交付团队之间沟通的交流语言（术语、文档模板、内容表述和事项分解的粒度等）；

基于CMMI的过程改进，以及CMMI过程体系相关的工程规范、管理架构，为久其软件引入其他的管理体系（如ISO9000、ISO20000、ISO27001等）及其他行业相关规范（如安全集成、安全开发等资质标准）提供了一个全面的、标准化的框架体系和蓝图。对于这些体系和行业规范，公司不是另起一套流程、文档和规范体系，而是想方设法将其融入到CMMI过程和规范体系中，成为不断探索细化CMMI过程改进体系蓝图的“佐料”；

过程改进资产和最佳实践库是进行CMMI过程改进留给我们的一大财富，加速公司内部知识的分享和传播，特别是，我们将应用系统开发过程形成的组件、技术预研的成果等也视为最佳实践库的一部分，并着手专门建设公共组件和共用技术研究成果制件库，将之融入公司内部的研发平台中，大大提高了公司内部成果复用比率，降低了研发成本；

通过规范需求采集和客户化定制交付团队与产品研发团队的沟通渠道，在过程改进外部咨询顾问的指导下，我们将敏捷开发模式引入研发过程中，成功建立起敏捷开发与CMMI流程框架融会贯通的研发体系，并且在产品开发团队实践了“特征驱动的敏捷开发”的理念，使整个产品研发交付更具计划性、更有节奏和组织性，大大提高研发管理过程的效率，也改变了研发团队之前认为CMMI过程改进只是“一整套规范的文档体系”的陈旧认知，认识到过程改进不是套给研发团队的约束和枷锁，而是有效研发实践的有益参照；

通过过程改进活动，我们在公司的研发团队与培训部门之间建立了有效的沟通机制，将过程改进流程框架、工程规范、最佳实践范例等知识的培训推广纳入到公司培训部门的年度例行工作计划中，通过跨部门的沟通机制，研发团队也可以就当前流行的、与产品研发管理有关的技术、业务和管理专题与培训部门提前沟通，由培训部门组织专人准备相关的培训材料对产品研发团队与客户化定制交付团队进行更有针对性的培训；

通过公司内部EIP系统的建设，我们将基于CMMI过程体系的研发项目管理框架融入整个公司的管理过程中，实现了与公司的年度经营计划、预算与绩效管理、财务核算与成本管理、组织培训与人力资源管理有效衔接，建立了研发管理与公司高层的信息沟通渠道，从而补全了公司高层对公司全面经营状况的信息拼图，也为研发项目及研发过程改进提供了必要的数据基础；

通过内部DevOps体系的建设，我们建立一整套规范的CI/CD流水线体系、自动化测试体系、版本分支与合并管理体系、配置管理体系等研发过程的基础设施和工程规范，比如在产品线内以及产品线之间复用CI/CD流水线、建立基于通用测试用例库（如安全性、兼容性（数据库、操作系统、中间件、浏览器等）、性能和负载、底层平台接口测试等）之上的自动化测试，等等，使普通研发人员不用关心应用系统版本的构建、打包、集成、多运行环境适配和基准水平的代码规范检查、安全性构建和基本功能的测试等内部大量重复的、繁琐的事务性工作，能够更专注于应用功能的交付和客户价值的实现，大大提高了内部工作效率，减少了低级错误出现的概率。

久其软件推动CMMI过程改进的几点体会

久其的CMMI之旅是一场知行合一的实践，模型不是过程、不是标准，让它能够真正发挥作用不是一件容易的事。我们的体会可以总结成12个字：

行胜于言、实事求是、善事利器

行胜于言

一切的管理体系只是提供一个过程框架，其丰富的内涵必须自己在实践中探索（正如德鲁克所言，管理是一种实践，其本质不在于知而在于行，其验证不在于逻辑，而在于成果）。例如：我们在对CMMI的DAR（决策分析与评估）这个实践域的理解之前就没有深入，只是表面的理解为在过程管理中有会议决策或者电子审批单这种形式的决策审批流程，满足监管公司经营和研发各个环节的目标即可。但其实在深入进行CMMI2.0过程改进期间，我们发现之前公司经营管理和研发过程管理的角色、决策权限、岗位职责都没有定义的特别清晰，没有明确各相关方应该执行的动作，导致在研发过程的决策评估环节降低了效率并增加了研发成本。通过2.0的实施改进，我们把DAR的活动集成到所有决策分析与评估过程当中，对各职能以及研发部门的角色划分、岗位职责及权限分配进行了全面改进和优化，由点到面，建立起体系化、标准化的决策评估体系，降低了经营过程中的风险和成本，提升了研发效率。

实事求是

过程改进没有唯一正确答案，必须结合实际情况具体分析、具体确定最佳实践，真正实现基于业务价值来驱动过程。比如敏捷开发，之前有研发团队片面理解Sprint模型设定两个星期迭代周期的建议，不管大产品小产品、大团队小团队死板地设定两个星期的迭代周期，由于团队规模很大、某些业务需求难度复杂度较高、阶段目标短时间难以理清等问题，造成研发团队内部花大量时间沟通澄清问题、测试团队频繁做重复测试、交付团队觉得每次发布的版本基本不可用，从而产生大量的内部扯皮和抱怨。后来根据不同产品的特征，设置不同的迭代周期，比如对于团队规模大、复杂度高的产品设置两个月一个迭代周期，对于团队规模较小、功能边界清晰的产品设置一个月一个迭代周期，并配套相应版本分支和合并策略，从而大大缓解了团队内部紧张局面，使研发工作组织更为从容。

善事利器

工欲善其事必先利其器，持续有效的过程改进一定要有好的工具和方法，方能事半功倍，打造出优秀的产品。比如针对BI产品数据分析展现应用场景多、复杂度高带来的测试复杂和工作量大的问题，我们就建设了BI产品线自动化测试用例库，基于对用户的数据分析展现场景，进行抽象和全面化，梳理出约2300个测试用例，并且自研测试工具，实现测试脚本的自动执行，可以快速直观给出测试结果，大大提高测试效率，保证了数据正确性。这样的例子还有很多，比如EIP内部信息化管理平台功能的不断完善、基于Jenkins流水线管理等等，这些都为我们的过程改进和产品质量提供了可靠保障。

今天久其软件面临着新的挑战，为了客户，我们会不断学习、创新，我们会持续过程改进，会让我们的客户在每个改进中受益。

（文章来源：老丛讲桌，作者久其过程改进小组）

文章源于网络，如有侵权或者不当，请告知删除