美国军工敏捷开发指南

美国军工是如何实施敏捷的呢？我会花点时间写几篇文章跟大家聊聊。今天先介绍美国国防部发布的DoD IT项目的敏捷使用指南，好比武功秘籍先讲修炼心法，相信这些敏捷导入考虑对5000组织会有借鉴意义。
美国军工敏捷背景
2017年对美国军工软件采购来说是重要意义的一年。美国国防部（DoD）发布了敏捷采购法案（Acquisition Agility Act），改变了以往软件采购模式，鼓励快速使用新兴技术，快速响应变化，通过增量反馈减少浪费，增加武器系统的互用性。
软件定义装备是美国军工的共识，1970年20%的装备功能是由软件实现的，到了2000年，这个比例已经增加到80%。虽然有了些进步，但是无论从成本到进度，DoD的数据都让人郁闷：48%的项目在实现IOC（initial operational capability - 初始可操作能力）之前，至少有2次预算追加。进度更是槽糕，平均延时21个月，有12%的项目IOC交付延时达四年以上。国内的军工可以自行对照此数据，说多了都是眼泪。
十多年前，DoD开始将目光投向如火如荼的敏捷革命，逐步开始军工软件的敏捷尝试，希望能够改变软件开发的现状。2009年，DoD发布了敏捷采购过程（见下图），军工朋友好熟悉的感觉有没有?

不久，DoD发布了IT项目敏捷实施手册，其中给出了11条敏捷实施指南。
1.敏捷转型决策
导入敏捷之前，首先确定组织内哪些项目的全部或部分适用何种开发模式。需要考虑和分析的因素包括：项目需求和技术的稳定度，关键安全要求，可用资源，组织文化，客户和干系人的承诺和参与程度等。在此基础上确定适用于敏捷的项目类型，通过引入敏捷实践增加项目成功的概率。
2.选择适用的方法
敏捷方法不是0和1的选择（要么不选，要么全选），需要在众多方法中识别并选择出合适的实践。在实际操作中，往往需要把不同的方法结合在一起，包括传统和敏捷的结合。重要的是找出适用于项目独特性的开发过程。
3.新开发和集成
敏捷不只适用于新开发项目，所有软件密集系统的开发，如IT系统，嵌入系统和控制设备等，都可以借助敏捷。敏捷通过前期增量、频繁交付，干系人的持续介入完善产品质量。不论是新研项目还是维护项目，敏捷原则都可以帮助我们提升产品质量和用户满意度。
4.“完成（Done）”的定义
传统项目的完成（Done）往往意味着所有代码已经通过测试，相应交付文档全部完成。在敏捷中，完成的含义则由具体场景决定。在迭代计划中，清晰定义“完成”的标准并达成共识。
5.敏捷培训和敏捷教练的使用
敏捷项目成功的一个重要因素是整个团队都有敏捷经验，业界数据显示，敏捷失败的主要原因是团队成员缺乏敏捷经验，这个团队不仅包括开发，也包括管理。基于这个原因，项目计划应该识别敏捷培训需求并制定敏捷培训计划。对一个没有经验的团队来讲，聘请一位好的敏捷教练可以推动敏捷导入过程。
6.分布团队
团队成员分布各地不是最优项目模式，但有时是唯一模式。它大大增加了敏捷难度，在这种情况下，好的沟通、协调工具是成功的关键因素之一。
7.大项目的规模化敏捷
大项目往往包含多个子项目，团队间的沟通策略可以决定项目成败。在选择项目过程（可能是多个过程）和沟通策略时，一定要确保和项目特点一致。
8.组织内部的敏捷
IT项目不再仅是单一部门的事，不同部门、组织的有效协调变得至关重要。仅在项目中敏捷，而组织不做改变不可能有成功的敏捷转型。项目计划应该列出所需外部资源以及相应的协议，及时和相关团队、管理人员沟通、协调是管理的关键活动之一。
9.敏捷的风险管理
风险管理是敏捷开发自带的有机体，频繁沟通，频繁计划调整，需求优限级的选择都增加了项目的透明度。根据项目规模、安全要求、可用资源，团队需要形成一个正式或半正式的风险缓解方式，所有成员都应该是活跃的风险规避、缓解的参与者。
10.敏捷合同
对于不确定性较高的项目，DoD需要使用不同的合同方式。经验证明，小规模合同往往能增加项目成功概率，另一方面，合同条款要鼓励合作关系。
11.CMMI和敏捷
CMMI已成为竞标军工项目的标准要求，敏捷和CMMI的关系往往被许多人误解。二者其实是互补关系，敏捷完全可以在CMMI组织内推广落地。
我一直强调价值驱动的敏捷（或叫其他名字）开发，形似神不似的敏捷比比皆是。不是把坐着开会改成站着开会，用贴纸把任务放到板上你就敏捷了，你的武器库不仅只是Scrum，XP等一些经典敏捷套路，而是所有能帮助你解决问题的做法都可以融入到你的“敏捷”中去。在军工项目上，不会有类似互联网的敏捷，一般往往是计划驱动+迭代的模式。CMMI/5000就是要成为敏捷的安全网，二者的结合会带来意想不到的效果。(来源:老丛讲桌)