|
敏捷的诞生之地，并不是如同我们的军用软件开发的组织，而是面向市场业务软件开发的公司。 所以，我们发布和实施GJB5000标准，参照的是CMMI，而不是当时已经诞生的敏捷开发。
而在GJB5000发布之后，开始实施之时，敏捷和CMMI/GJB5000一直都是对立的，两种开发方式哪个更适合我们的软件开发，争议持久不息。 当时，我也持有敏捷难以在实施GJB5000的组织落地的想法。其他的暂且不说，仅仅是敏捷提倡的“用户参与”，在实施GJB5000的组织就难以落地。 敏捷开发的思想，是假设用户和开发人员有一个共同的愿望：开发出一个能够给用户带来巨大价值的软件。 所以，用户是愿意积极参与软件开发中来，愿意向开发人员解释自己的要求和期望，愿意持续验证已经完成的软件功能是否符合自己的需要。 而我们很多实施GJB5000的组织中，开发人员一般不会和最终用户接触，他们要进行需求的沟通只能找系统人员。而系统人员并没有作为用户代表的觉悟，他们只是完成自己系统方案设计，组织产品齐套、系统联试、环境实验、外场实验、阶段总结的工作而已。对于软件开发过程，他们很少过问，不到齐套和联试的时候，他们不关心软件完成了哪些功能，这些功能是否满足要求。 敏捷开发提倡“用户参与”，至少公司的业务人员会作为用户代表多次参与软件需求的讨论和验证，而我们实施GJB5000组织的系统人员只会在软件开发的一头一尾（任务书评审和软件交付）参与；敏捷提倡完成最小价值产品后就进行不断地交付和用户参与的验证，而我们实施GJB5000组织的系统人员没有在软件开发过程中间多次验证软件功能的习惯。 这就是我原来不看好实施GJB5000的组织能够实施好敏捷的主要原因。 但是，GJB5000B中已经明确系统的开发也在其管理范围之内（有关内容可以参考GJB5000B的“组织资产开发”、“需求开发与管理”和“技术解决方案”等实践域），那么系统人员就应该融入到软件开发体系中。如果组织有敏捷开发模型，系统人员要按照敏捷开发模型的要求履行“用户参与”的职责。 试想一下，如果系统人员能够根据开发进程解释需求，确定需求优先级，多次验证和调整需求，那么敏捷开发就能真正地落地了。 当然，这不是仅靠GJB5000B的实施就能解决的问题，更重要的是管理者对GJB5000B的重视，发挥其领导作用，引导系统人员开发思想随之改变才行。特别是对于竞标项目而言。 这正是： 敏捷若是想落地，用户参与必实施 系统人员思想变，军软敏捷方可行 作者简介：王小双，长期从事GJB5000推广、实施、评价、改进的工作，创建《软件工程之思》微信公众号，一直在《软件工程之思》分享GJB5000、CMMI、软件工程的知识和感悟。现致力于GJB5000咨询以及软件过程改进、软件工程能力提升的研究工作。 |
|
|
