如果这些敏捷方法应用到军软开发当中会怎样？

最新版的CMMI2.0已经开始拥抱敏捷了!它在很多实践域中都以特殊场景的形式，描述了CMMI在敏捷开发的情况下的应用场景。那么对于实施GJB5000的组织来说，也不妨考虑一下在实施GJB5000的项目中如何引入敏捷方法。

当前比较成熟的敏捷开发项目中，通常使用Scrum管理项目、使用极限编程进行开发、使用看板进行项目的可视化管理。

这里主要谈谈用于项目管理的敏捷方法在GJB5000项目中的应用。

• 看板

看板的作用就是让管理者能够一目了然地看到开发任务的进展情况。

对于GJB5000项目来说，我们是通过甘特图和进度表来实现这个功能的。

但是二者比较起来，看板更加直观、明了，而甘特图或者进度表通常很难给人这种直观的感觉。

所以如此，是因为二者承担的职能是不一样的。

看板关注的只是工程类的任务的完成，它只需要给出这些任务的状态，哪些待完成，哪些进行中，哪些已完成。

而甘特图或者是进度表则是一个项目完整的WBS分解，不仅有工程任务，也有管理和支持类的任务；不仅显示任务的状态，同时又显示工作量、起止日期、责任人、任务依赖关系等诸多内容。因为GJB5000的项目策划和项目监控的很多实践都是通过它来实现的。

所以，如果管理者只想看到任务进展情况，那么通过看板再辅助以燃尽图，是最简捷明了的。在这方面，看板肯定是优于甘特图的。

如果要把看板引入到GJB5000项目中，那么它是无法取代甘特图的存在的，只能在软件项目管理平台当中增加一种任务视图，由这个任务视图来实现看板、燃尽图的功能。

• 每日站立会议

敏捷中的每日立会是以高效的项目组内沟通而著称的。如果这个敏捷方法要引入到GJB5000项目当中，需要考虑以下几个问题：

1）会议的频度应以项目沟通的实际需要决定。如果没有多少需要沟通的事情，这个频度可以和GJB5000项目中的周例会结合起来进行。

2） 站立会议的高效，并不在于是否站着开会，而是主持人能够控制项目会议的走向，不会让交流的内容偏离会议的主题——进行项目进展情况的沟通。同时也要注意会议主旨是交流问题，不是为了解决问题的。对于不能解决的问题，要把它搁置在这个会议之后，另寻时间来解决。

3） GJB5000项目采用站立会议也应当留下会议纪要，以实施项目监控的一些实践要求。

• 迭代回顾会议

敏捷中的迭代回顾会议是在完成一个Sprint任务之后进行的，会议上主要回顾一个上个Sprint中哪些完成的好哪些完成的不好，对于需要改进的地方放入到下个Sprint中。

对于GJB5000项目，也可以在周例会、阶段会议或里程碑会议中加入分析前一周、阶段或里程碑中完成的好和不好的分析，以改进后续工作的项目监控、质量保证、配置管理等管理活动，以及需求管理、设计、实现、测试等工程活动。

• 估算扑克

估算扑克是一种工作量的估算方法，它是以最初的估算时采用的扑克打分而得名。估算的过程与传统的专家估算并无太大的不同，只是估算的对象是一个“用户故事”或者修复一个BUG的任务。

虽然估算扑克对于CMMI所要求的工作量估算应当依赖于规模估算支持并不明显，GJB5000项目采用它进行工作量估算也是可以的。只是要注意产品WBS分解粒度太粗，可能会影响估算的准确度。

这正是：

敏捷方法可借鉴，只是不能全照搬

考虑军软特殊性，融入五千不算难

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