灵活、改变、学习——日常实施GJB5000体系的几个建议

日常实施GJB5000的难度，远非为了获取等级资质试运行的几个项目可比。

为了获取资质，组织可以付出巨大的代价，支持项目组用最完整的GJB5000体系来管理项目。毕竟试点项目是有限的，这个代价还是可以承受。可是，在获得了相应的等级资质，需要将GJB5000体系推广到所有军软项目上，再不考虑项目的实际情况，一味地照搬体系去做，那只会影响项目目标的达成，而这是管理者绝不愿意看到的。

所以，有些缺乏指导的项目组不知道如何裁剪体系，同时迫于管理者在进度节点上的压力，就只有放弃GJB5000体系，只求快速地完成可用软件的开发。

于是，“两张皮”的现象产生了。

这种现象的产生有教条主义的因素，也有对软件工程原理认识不足，软件工程能力水平低下有关。

敏捷大师罗恩·杰弗里斯在《软件开发本质论》中关于敏捷框架实施提出了几个意见，这些意见对于我们实施GJB5000也同样很有意义。

1. 掌控框架，而不要被框架和掌控

GJB5000体系，是我们管理军软项目的框架，这个框架把软件开发过程划分为20+个过程，每个过程需要我们做好若干实践来完成过程的目标；这些过程目标实现了，那么意味着软件开发有个完美的过程，而完美的过程可以带来完美的结果——软件产品。

但它只是个框架，它给软件开发指明了前进的方向，可是并不意味着你必须按照它给出的实践去做。只要方向是对的，不按照它的道路走，你自己也有可能走出一条捷径来。

实施GJB5000，最重要的是做好每个过程，而无需在意实践具体怎么做。

1. 保持流程的改变贴近团队的实际

世界上没有两片相同的树叶。

同样的，也没有两个完全相同的软件项目。可能是项目背景，可能是运行环境，可能是功能需求，也可能是团队成员……总之，两个项目之间总会有些不同。

而不同的项目，就需要不同的开发流程。一个好的项目管理者应能根据项目的实际情况调整开发流程，使其适应自己的项目。

GJB5000体系是允许对过程进行裁剪的，甚至超范围裁剪（超出裁剪指南的裁剪）经过批准也是允许的。项目管理者要利用好这一利器，定义和调整项目的过程，使之成为软件开发的助力而不是阻力。

项目管理者对开发流程的调整不仅仅在项目策划之初进行，在项目过程中也同样可以进行。

记住，我们的目标是追求适合自己的过程，从而开发出更好的产品。

1. 把学习放在首要的位置

敏捷团队是自组织团队，每个团队成员都很自律且能力超强，即便这样，也会要求他们把学习放在首要的位置。

因为能力出效率，能力越高，遇到问题越容易解决。

比如我们的一些实施GJB5000的组织在遇到竞标项目的时候，总是觉得体系不够轻量级，难以按照体系要求去开发，但是，如果你学会了敏捷的一些先进实践——测试驱动开发、持续集成和验证、自动化测试等技术，这些问题可能就迎刃而解。

实施GJB5000，要把学习放在首要的位置，不断地学习优秀的软件工程实践，学习先进的软件开发和测试技术，这样才能更好地实施。

这正是：

摆脱束缚龙入海，灵活改变花自开

学习提高成常态，更好体系自然来

参考书目：软件开发本质论：追求简约、体现价值、逐步构建，作者：（美）罗恩·杰弗里斯，译者：王凌云，出版社：人民邮电出版社

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