实施GJB5000A的组织如何管理小软件开发？

实施GJB5000A的组织都有很多小规模的软件要开发，而这些小规模软件开发使用相对巨型的GJB5000A的过程管理模式是否合适，一直存在争议。 实施GJB5000A的组织该如何管理这些小规模软件的开发？ 下面将对此进行一些探讨。

实施GJB5000A组织中的此类小规模软件开发，都是小团队的形式，通常只有一个开发一个测试，而且他们同时负责的不只这一个软件； 而在工作量上面，小软件开发的工程活动的工作量都不大，甚至少于管理活动的工作量； 但在质量需求上，很多小软件的安全关键等级都是A、B级，有高质量的需求。

所以，实施GJB5000A的组织对于小规模软件的管理要做好以下两件事：

1. 控制管理成本

2. 加强质量控制

而要做好以上两点，我们可以从两个方面来考虑： 一个是对开发人员的管理，一个是对流程规范的管理。

• 人的管理

无论是控制成本还是控制质量，都离不开人的管理。 如果开发人员具有较高的水平，能够高质量地完成每个开发活动，那么自然就会节省很多管理成本（根本不需要监控啊），而评审、测试这些质量控制措施的代价也不需要那么多（本身就是质量水平已经很高了，评审和测试也就是查漏补缺而已）。

而要达到这个目标，可以从两个方面努力：

其一：注重软件工程知识培训

要达成成本低质量高的目标，小规模软件的开发团队成员都应该具备超高的软件工程能力。 如果能力不跟，就要注重软件工程知识的培训。

a)工具： 团队成员要会使用组织标准工作环境中的各种开发、测试和管理工具，熟练的使用这些工具，可以减少开发过程中使用 工具 的成本，也会有助于提高开发活动的质量。

b)知识： 团队成员如果不理解软件工程，对每个工程实践的意义都没有一个清晰的认知，就不会懂得如何改进过程活动（哪些活动需要加强，哪些活动需要弱化）； 团队成员如果对组织的流程规范非常熟悉，一切活动都可以顺利进行，避免因违反规范而采取补救措施增加成本。

其二：注重新人能力的培养

一个开发部门的成员必然包括很多新人，新人的能力培养也是非常重要的。 新人的培养有以下几种方式：

a) 传帮带的师徒制： 这是常见的一种方式。 但在很多组织的实际应用中都没有形成章法，没有规定教授新人的时机、内容，最多会在新人试用期结束后有个形式化的评价。 建议在给新人指定师傅的时候就应当指定一个明确的培训目标，如在1个月内具备组织的软件工程能力的基础要求，3个月内能够独立负责某类型软件开发的能力，并且跟踪监控目标的实现。

b) 代码审查： 代码审查既是一个有效的质量控制方法，同时也是培训新人的有效手段。 新人产生的代码必须要由资深的开发人员进行代码审查，审查者在指出缺陷的同时，也向新人传授了经验。

c) 技术交流： 开发部门要经常组织一些技术交流，新人可以借此开拓视野，获取知识，提高能力。

d) 项目总结： 项目的阶段性总结也是新人学习的好时机。 阶段性总结的时候会指出项目开发过程中不足，下个阶段的改进措施等，新人可以从中获益。

• 规范管理

除了提高人的能力之外，对小规模软件开发规范的优化也是组织做好小软件开发管理的重中之重。 我们可以从以下4个方面对小软件管理的规范进行优化。

其一：定义适合的开发模型

小规模软件的开发并不适合常规的瀑布模型，需求、设计、编码、测试，如果每一阶段都需要按部就班地逐一进行，通过正式的评审确认满足要求之后再进入下一个阶段，那必然会将开发过程拉长，增加很多的管理工作量。

敏捷开发模型是适合小规模软件开发的。 即便因为组织的能力不能完美地实施敏捷开发模型，也要吸收敏捷开发中将需求、设计、实现融合的开发模式，并以之为核心建立新的适合小规模软件的开发模型。

其二：引入敏捷开发实践

敏捷开发中的一些实践可以有助于控制成本和提高质量，比如： 站立会议、计划会议、回顾会议、看板、自动化测试、持续集成等。

其三：注重软件复用

软件复用是缺陷去除效率最高的方法，也是提高开发效率的最佳方法。 对于小规模软件开发，如果能够推进软件复用的话，可以极大地控制成本和提高质量。

其四：严控开发的入口和出口

控制开发的入口指的是控制用户需求的变更； 控制开发的出口指的是控制交付软件的质量。 抓好开发的入口和出口，可以控制小规模软件的质量。

本文参考宝玉老师《软件工程之美》中的一些观点。

这正是：

规模虽小质量高，五千照搬未必好

管理规范和人员，引入敏捷求实效

作者简介： 王小双，长期从事GJB5000推广、实施、评价、改进的工作，创建《软件工程之思》微信公众号，一直在《软件工程之思》分享GJB5000、CMMI、软件工程的知识和感悟。 现致力于GJB5000咨询以及软件过程改进、软件工程能力提升的研究工作。