想说爱你不容易——关于在军软开发中应用敏捷模型的几点思考

敏捷自打诞生之日起，就深得大多 程序员 的欢心。

仅仅敏捷宣言中的“工作的软件高于详尽的文档”这一条价值观就值得大多数程序员的拥护。况且，敏捷就是以人为本的开发模型，而重视人的作用就是要加大对程序员的重视，作为程序员谁不愿意拥抱敏捷呢？

受到程序员欢迎的敏捷开发能够及时响应开发，快速交付可用版本，实践中已经有了一些成功案例，甚至包括在一些高可靠高安全需求的软件项目。可是，敏捷开发要真正用于军软开发就要解决一些水土不服的问题。

• 用户问题

敏捷模型中要求有现场客户或客户代表，客户是深度参与到软件开发当中的。而在军软开发当中，软件开发的用户需求大多数都不是来自最终用户，而是来自组织内的系统组。系统组除了提供软件开发的用户需求之外，还有对外协调和沟通的任务、系统设计和开发、联试、试验等任务，系统组像敏捷模型的现场客户那样深度参与软件开发是一件不可能完成的任务。

• 需求问题

敏捷开发不要求形成需求规格说明这样的完整的文档后才开始软件开发活动，它是以“用户故事”的形式提交需求给开发人员，开发人员据此开发。而这个用户故事通常只是从用户使用的场景提出的需求，很难满足关于需求的准确性、一致性、可测量等的原则性的要求。开发人员在拿到这样的“用户故事”后，还需要同现场客户一起落实需求的细节才能进行开发。而一旦现场客户对需求描述不准确，甚至时不时提出一个异想天开的需求，那对于软件开发来说就是一场灾难。

在《重构极限编程——XP的实践与反思》一书中就已经对于敏捷开发的这种没有一个有效的需求确认提出了质疑，甚至把一些敏捷开发失败的案例也归结于此。

对于军软开发来说，即使在前期不形成一个完整的需求规格说明文档，但有效的需求确认还是必须要做的。开发人员和系统组对于“用户故事”（假设军软开发也采用这样的需求表达方式）描述的需求要达成一致理解，对于“用户故事”的需求细节也应由系统组做进一步的确认。形式上可以先不形成任务书和需求规格说明，但需求评审和必要的签署应当是需要的。

• 设计问题

敏捷开发中没有整体架构设计的阶段，架构设计是基于当前开发的需求建立的，随着开发的需求增多，通过重构的方式来不断优化架构。

对于军软来说，多数情况下都是大部分需求已经明确，少部分需求待定。如果是这样的话，就应该先做好整体架构设计，考虑架构的健壮性、可扩展性，减少重构的次数。毕竟重构的次数越多，代价越高。

• 测试问题

敏捷开发没有专门的测试阶段。敏捷开发的测试主要是在功能实现的过程中由开发人员进行的单元和集成测试（这里有借助自动化 工具 实现的持续集成和自动化测试，也有TDD的应用在里面）。一些大厂在实施敏捷开发时也会在代码部署到生产环境之前前先部署到测试环境上由测试人员完成功能测试。

但是对于质量需求、安全需求更加重视的军软开发来说，不仅要考虑测试的敏捷性，更要考虑测试的有效性。

其一，有效的测试不能只做白盒测试不做黑盒测试，有效的测试应当是二者合一，集中两者的优点。军软的测试必须要应用好这两种测试方法，追求测试的有效性，哪怕为此增加测试成本延长测试周期也是值得的。

其二，军软当中的很多嵌入式软件的验证对硬件环境依赖巨大，这对于敏捷的自动化测试、持续集成等理念的实现有巨大的阻碍。

• 文档问题

敏捷开发重视软件功能的实现，不重视文档的详尽与否。但对于军用软件来说，软件的维护性、保障性是非常重要的一环，而要做好软件的维护和保障，文档就是不可或缺的。

在实际的军软开发过程中，可以考虑中间使用简化的文档记录，把形成正式文档的工作放在后期。

所以，军软开发要使用敏捷模型，就一定要把敏捷融入到GJB5000当中，吸收其敏捷思想和部分优秀实践，以优化基于GJB5000标准的原有的重量级的军软开发模式，最终形成高效又高质量、高可靠、高安全的软件开发模式。

这正是：

敏捷谁人不想要，实践问题要思考

融入五千唯正途，军软开发方最好

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