这篇文章概述了SEI 采购方案在美国国防部软件密集型系统开发中运用敏捷方法的探索，我们识别出了遇到的需要克服的问题和挑战，并记录下来。敏捷的定义：敏捷开发是以一种互动的，增量的方法由自组团队进行的高效率团队合作的软件开发方法，以实惠的成本及时地生产高质量的软件产品，更适应相关干系人对产品的需求变化。

敏捷方法经需要不断与最终用户协同合作，频繁的（2 周-4 周）提交产出物，连续的集成和测试开发。虽然所有的敏捷方法是增量的，但并不是所有的增量的方法的具有敏捷开发的属性。美国政府和国防部从SEI 工作伊始，就一直考虑运用一种能充分发挥敏捷方法优势的新的采购过程。

潜在的困难以及与传统方法的区别

通过对运用过敏捷方法的美国国防部 部门的访谈，总结他们遇到的困难如下：

●采购生命周期：敏捷通常不会在每个里 程碑都有很多可评审的文档，因敏捷会增 量地把最新的产品开发出来，所以验收标 准也需要调整；

●团队环境：敏捷是强调一个动态的、跨 部门、高效的团队。相关的政府部门也需 要了解这一点；

●最终用户参与：敏捷是强调与客户的协 作，而非合同的谈判；

●培训和传授敏捷知识：很多人还是对敏 捷的概念不清晰，所以必须要先对相关人 员做培训；

●里程碑评审，文档记录，度量评价：传 统来讲，政府使用里程碑评审，文档记录 和评价度量来监控和评价沟通进度和审查 软件技术方案。里程碑评审和文档记录的 检查和检查准则可能在里程碑发生之前进 行。这个方法不同于敏捷开发的项目。敏 捷开发的项目，文档记录只要满足技术和 方案的需求就可以，实现文档记录最少化。保证达成最终结果的一些关键点如下：

●与对结果负责的责任人或国防科学委员 会各方确认；

●制定哪些与开发无关的文档，有效去监 督敏捷开发项目；

●同意每个文件的目的和内容；

●确保所有的需求满足指南说明和规定;

●奖励和激励: 敏捷关注团队，这与传统独 立基础的奖励机制相反;

●团队组成: 2 个重要职务是敏捷倡导者和 最终用户代表,敏捷倡导者, 上面描述的, 是能实时回答敏捷问题, 最终用户代表, 不仅代表最终用户，必须能够有权利指挥 承包商。

●文化:做一张简要的典型文化元素表格， 为了适应敏捷，政府将不得不修改他们的 思维方式, 使得他们除了传统的比喻，还 可以从其他角度查看软件的生命周期；

●集成和测试：持续集成和测试形式是在 敏捷团队中完成的。这不同于集成在传统 方法中是在最后的发布环节才做。

美国国防部敏捷和传统元素的对比

敏捷开发运用之路

通过访谈，我们了解到美国国防部推动敏捷开发的两个主要原因：

1、 不少项目存在需要迫切解决的问题 （比如：如果维持现状，不改进效 果的话，可能会取消该项目）；

2、 不少项目需要有快速及多轮的产出 物。

我们还发现可能更令人信服的推进敏 捷开发的理由。2010 财年国防授权法案 第 804 节规定了信息技术系统包括：

（A）早期和持续的用户参与; 

（B）多种迅速执行的增量或版本发布的 能力;

（C）早期利用连续的原型来支持增量的 开发;

（D）模块化的开放式系统。 事实上，敏捷方法比传统的 IT 采购更适用并兼容以上4个方面，支持并适当采 用这些方法，未来的结果会更令人鼓舞。

对于已经使用了一段时间敏捷方法的人而 言，持续改变的动力通常有下面几点：

●当他们提交了一个增加了最终用户所需 功能的新版本时,会产生一种真正的成就 感。

●短时间内他们会看到自己的工作对最终 用户的差异。

●鼓励（经常称赞）：用户提出反馈意见， 来清晰的讨论方法的价值。

●一贯的达到或超过用户期望的能力。

●以前无法在约定的时间间隔提供价值和 成本。

为了运用敏捷开发方法，需要考虑最 好的实践和组织级管理的改变，典型的包 括：

●理解试用人群：我们需要理解组成团队 的人的特征，也要考虑团队本身的特性。 在美国国防部，采用敏捷开发的人，他们 是这个大环境中探索敏捷合作方式的探路 者，基于传统工作方式来执行文档和证据 的提供。只有当完善的支持更多交流和实 施支持机制建立健全后，敏捷方法才能成 功地在美国国防部跨部门中广泛应用。

●理解循环变化规律：变化需要努力和时 间。从我们的访谈中可以看到，经过一段 时间的阶段性的运用敏捷方法后，可以让 员工开始形成这种新的工作习惯。

●理解运用风险：了解团队中的活动，技 能，倡议和价值。

●建立过渡机制来缓解风险：一些潜在机 制参考 CrossTalk 的相关文章，国防新闻 中关于成功运用敏捷方法的节目，以及运 用敏捷方法的优点。

结论

敏捷方法具有响应及时的好处，比传 统方法更能快速调整当前的状态。运用敏 捷方法也要克服障碍，有些人已经在敏捷 的路上，开始积累信息财富来帮助想要改 变的组织。