敏捷转型一直以来在各类组织中都有着颇高的人气。什么是敏捷，为什么要敏捷，敏捷转型对我的组织有何效用……？在对待敏捷这个话题上，大家都能七嘴八舌地说出很多看法。然而，正是由于同学们对此话题都略知一二，让敏捷之路在一个组织中推行存在着或多或少的困扰乃至阻力。

俗话说，擒贼先擒王。想要在一个组织中推行某种规则或体系，最有效的手段往往是从意识形态入手，统一大家的认知。通俗地说就是打好“广告”。不过，打广告是需要成本的，你的受众为什么相信你？为什么为你的想法买单？（如果你本身就是老板本身则不适用这个问题。。。）这些问题都是需要考虑的。作为倡导者，你需要的是高质量的信息，足够严密的逻辑，令人信服的事实数据等。

下面给大家分享两个敏捷转型的小故事，希望大家在理解敏捷的基础上，能用生动有趣的实例引领团队进行成功转型。

美国911事件爆发后，美国国家安全问题被提上最高议程。于是，FBI 档案管理信息化系统 项目于2006年启动，预算4.51亿美元，计划3年时间交付。最开始，此项目决定采用传统瀑布式软件开发方式。而经过4年的开发周期，费用花去4.05亿美元后，工作缺仅完成一半。无奈，此项目被迫终止 。

为何瀑布式的开发在软件项目研发领域并不能提高项目相应的成功率，反而会带来效率上的负面影响？我们需要从瀑布开发及软件产品的特质说起。

传统的瀑布式开发模式，需要对整体计划进行周密的安排，前后项的依赖关系，都在项目前期做了安排。如果中间有任何环节出现了变更，其后续改动的成本会很大。而软件项目的特质是其功能的更迭速度快，需要在快速的数字化世界中不断满足用户的需求。对于需要一开始就做好计划，按部就班开发的瀑布方式，很难再适应新环境的需求。

                                                           瀑布式开发模型 - 图片来自网络

从传统瀑布式开发的项目管理工具 - 甘特图的起源也能看出，其最初于1910年被美国陆军军械部部长亨利·甘特发明后应用于一战的战场。应用场景符合需要明确掌控全局活动，且有固定部署的项目。

                                                                   甘特图 - 图片来自网络

回到刚才FBI的信息化项目，如果我们要引入敏捷，需要怎么做？实际这个项目最终结果是怎样的？

之前搁浅的FBI“哨兵”项目，后续聘请了一位首席信息官，在他的带动下，引入了敏捷中的Scrum研发模式。他将原有项目团队的人员遣散了90%，仅留下10%的人员参与到重启后的项目中。在他的带领下，整个团队仅用了12个月及3000万美元就完成了之前团队耗时4年及4亿美元才完成的剩余50%的工作。不得不让人惊叹于究竟是怎样的方法能带来如此天翻地覆的改变？！

这位首席信息官的名字叫作Jeff Sutherland, 他发明了scrum的研发模式，并在多个大型组织中取得了不错的成绩。Jeff Sutherland在接手FBI的“哨岗”项目后，随即运用Scrum的方式开始了迭代。他带领团队整理出项目所有需求并打印出来(上千页) ，并运用80/20法则，明确20%的高优先级需求能创造80%的价值，从而确定了每项需求的优先级(1100项需求) 。

                                                   功能优先级排序及版本规划 - 图片来自网络

确定固定的迭代周期，采用1-4周作为一个迭代周期（sprint冲刺）。在固定周期中，团队成员可以做好工作规划，对单个sprint中可完成的功能形成较为准确的预期。一次做一件事情，减少长周期中可能出现的过多并行工作造成的效率损耗以及过多的潜在需求变更风险。

在做完backlog grooming及sprint plan之后，团队进入开发阶段。在此阶段中，每天组织站立会议对昨天做了什么，今天计划做什么以及存在什么问题及风险这三个问题进行同步。每个迭代完成后对本迭代的输出交付物进行团队展示，并做回顾反思。对在本迭代周期中，做得好的方面，有待提升的方面都可进行分析，最终形成文档，作为组织过程资产留存。

                                                               Scrum流程 - 图片来自网络

为加深大家对scrum的理解，我们再来做一个简单的案例分析。

J公司为一家软件研发公司，M公司为一家建筑企业，他们计划就“建筑公司管理信息系统”进行合作。合同金额为1000万美元，交付周期为20个月。大家可以想想，按照传统的瀑布式开发及采用scrum的方式开发，会有什么不一样的结果？

假设按照A，传统的瀑布式研发，则在最初制定计划时，就会根据合同框架，按照周期20个月来推进。最后很大可能存在成本超期及进度延后的风险，可参照FBI“哨兵”项目。时间越长存在各种变更的潜在风险就越高。

J公司采用了B方案，scrum的研发模式，他们是怎么做的呢？首先，增加合同附加条款，如果建筑公司想要在任何时间终止合同，只需要支付剩余合同价值的20% 即可。对于建筑公司而言，这种方式很大程度上减少了项目投入的风险。软件研发J公司为何有如此的底气做出这样的承诺呢？

我们还是回到scrum的核心来看。J公司通过梳理优先级，持续快速迭代，保证每次冲刺结束时都能交付当前backlog中最有价值的需求。每个迭代结束后通过项目展示，相关干系人共同验收，及时提出反馈，并在下个迭代中考虑对重要变更进行处理。最后，在经历了3个迭代周期（4周一个迭代）后，M公司认为所开发的信息化系统已能满足其需求，不需要再继续进行开发，因此，在支付了3个月的成本及剩余合同价值的20%以后（320万美元），最终M公司以远低于计划的成本（1000万美元）及远少于计划的开发周期（20周）结束了合同。而对于J公司而言，他们的平均盈利率也从原来的15%提高到了60%，绝对一个双赢的结果。

如今，越来越多的组织在引入敏捷的概念，希望通过敏捷转型为组织赋能，从而提升自组织效率。对于敏捷的倡导者及执行者而言，在领会了敏捷方法的核心价值理念后，需要实践、实践、再实践。相信每个组织都能找到最符合自身发展的敏捷方式。

对项目管理话题感兴趣，可关注知乎专栏“项目管理の日常”

转载请注明出处，感谢。