简介

在9012年的今天，已经很少有人没有听过敏捷了。但敏捷真能解决这样的问题么？毫无疑问不太现实。毕竟中国式敏捷的笑话，也不是第一天出现在世人面前。许多公司都曾经实践过敏捷，却最终由于各种原因无法执行下去，水土不服是这些西方管理思想在国内最常见的问题。

而刘华老师也是在这样的背景下编写了这本书《猎豹行动·硝烟中的敏捷转型之旅》，这本书的出版在敏捷社区掀起了一番波澜。与其他介绍敏捷方法的书长篇阔论的介绍方法论不同，这本书以一个小说体的形式介绍了一个金融公司盛远金融的敏捷转型之旅，这一个个的小故事，既有受挫、又有成长，最终在这家企业中完成了转型，实现了劳动生产力的解放和软件研发实力的腾飞。

这家企业是如何做的？让我们跟着作者的笔触一步步走进这一幕幕吧。

角色介绍

作者引入了几个角色，分别是来自咨询公司的思域咨询公司的咨询顾问王章、曾经在某电商企业担任过管理层的盛远CTO思文、技术经理李俊、资深PMO关杰、项目总监张丽等主要角色。

• 王章：敏捷顾问，有丰富的敏捷实施经验，对新思维、新方法狂热。
• 思文：公司敏捷的推动者，执行能力强，面对困难从不抱怨。
• 李俊：IT部门经理，严谨、沉着，对新思维、新方法保持谨慎。
• 关杰：部门利益捍卫者，对敏捷保持怀疑态度。
• 张丽：敏锐、务实，思维严密。

李俊是一位经验丰富的技术管理者，对项目管理拥有丰富的经验。他总是善于制作严密的计划，并能做到很好的把控。在过去的职业生涯中， 他在客户和业务部门的口碑非常好，他一诺千金，总是能做到按时交付。但是在这背后，却是压榨得最为凶残。团队的流动性也非常大。他是一位瀑布模型的践行者，虽然听过敏捷的概念，但是却认为敏捷是在为不做计划和不写文档找借口。他认为项目成功的关键靠的是强大和严密的计划能力、项目跟进能力和沟通能力，并努力实现客户的承诺。在此之前，他也经历过组织变革，但是这些变革往往雷声大雨点小、要么与实际严重不符，最终并没有带来什么实际的好处。

而作为敏捷顾问的王章，作为盛远金融敏捷转型的实践者，也充分得到了组织授权，感受到了思文对于敏捷的热忱，渴望在这家公司创造一番事业。事实上敏捷很容易获得基层的认可，不仅仅是因为敏捷不写文档，而是敏捷倡导组织间的相互信任、自治以及通过技术手段例如自动化测试来取代繁文缛节的文档。他很快就根据公司的实际情况建立了具体的启动方案，包括全面扫盲、体察民情、教育客户的三大步骤，并获得了思文的认可。

问题剖析

随后，王章给全体IT同事进行了一次全面的培训，从以下四个角度介绍了敏捷转型的具体过程。

• 从传统模式的问题（剖析瀑布模型的适应局限以及给业务部门和IT部门带来的痛点）、
• 转向敏捷（什么是敏捷？它与瀑布模型最大的区别在哪里？具体方法和价值观是怎样的？）、
• 实施敏捷的好处（包括对业务部门和IT部门的好处）、
• 如何开始（具体的行动）

在培训过程种，他也与大家一起总结了各部门的痛点，而在项目做的过程，根据业务部门的需求，虽然会给出估算和计划，但是在项目开始时，却只有预算和目标交付时间是确定的，很多因素都存在不确定性，包括：范围和具体需求、可能的需求变更、人员不可控、估算的准确性、对现有系统的影响、环境搭建等。

这些正是瀑布式模型带来的典型特点，事实上瀑布模型非常适合确定性非常高的项目，而这样的项目几乎是凤毛麟角。面对软件开发过程中的不确定性，需要采取措施管理和适应，真正实现“正确的做事”“做正确”的事。

随后的培训中，王章介绍了敏捷的价值观和方法论，获得了非常不错的反馈，大家都对实践敏捷的过程充满了期待。

万事开头难

作为一家金融科技的公司，对信息安全有着近乎洁癖的追求，因此工具的选型尤为重要，是选择商业软件，还是选择开源软件，往往都需要经历一番波澜。几经周折之后，选择了比较常用的敏捷管理工具，例如JIRA、Confluence、Github、Nexus、Jenkins、SonarQube、Ansible等工具。并建立了一套完整的DevOPS流程。

随后开始挑选第一个实践项目，【信鸽】。这是一个计划工期为8个月的项目，但是由于公司项目的典型特点，需要由PMO进行需求调研和业务分析，等来到李俊的项目研发团队手中，已经只剩下六个月的时间。而李俊这边由于项目的特殊性，已经腾不出额外的资源，最终只能招聘到一位临时软件工程师，事实上这时已经只剩下不到五个月的时间。

但是这个项目依然没办法按照敏捷的流程拆分迭代周期，主要是由于项目的需求文档由许多个条目组成，每个条目就是一个功能，但是仅仅按照功能进行拆分，几乎无法独立开发、测试和上线交付事实上拆分出来的东西，单个部署都没有业务价值。而且前期采用瀑布模型进行需求、设计而后面的开发、采用敏捷，最后的测试采用瀑布模型，显然这样的效益确实有限。

最终这个项目只能采用瀑布模型继续开发。需求文档的完成和签署花了三个月，然后在花一个月涉及外部文档，两个月开发、一个月完成测试，一个月用户验收测试，然后上线，正好赶上8个月的时间。

然而现实是残酷的，最终项目延期三个月结束。

越挫越勇

虽然经历了一轮挫折，但是却并未让年轻的咨询师就此放弃，他想起了曾经学习了解过的极限编程，同时又引入了kanban的精益软件管理的工具，然后将其引入到项目中。然后让李俊的项目团队采用看板的来跟进新功能需求的研发和流程的日常优化。

而随着日常流程优化这种常规功能的研发的逐渐开展，也让团队成员对于敏捷有了更深刻的认识，在新项目开发过程中，李俊的研发团队将Scrum引入其中，完成了一次原本看起来不可拆分、不可妥协的功能开发，并获得了公司高管的认可。

在后面的项目研发过程中，又经历了几次不同的挑战，但是也让敏捷的产品研发过程逐渐在公司生根发芽，逐渐发展状态，最终成为公司的常态管理形式。

总结

成功的项目千篇一律，失败的项目各有不同。

无论是互联网公司还是传统的软件公司，为了创造独特的产品、服务或成果而发起各种不同的形式的项目是行业的普遍选择。

如果说项目的成功与否，取决于组织的管理形式本身，实际上也取决于项目经理对项目的掌控力。优秀的项目经理不仅具备的优秀的专业技能、行业知识和软实力，让他能够灵活的驾驭各种不同类型的项目还能游刃有余，而普通型项目经理却往往耗费了大量资源，最终还会让项目陷入一座又一座的泥坑不可自拔。

对于软件研发型项目经理来说，选择合适的开发模型，似乎是首要考虑的问题。当然，毫无疑问，最为深入人心的项目开发流程，莫过于瀑布式模型。这是一种种增量式开发模式，历经从计划=》需求分析=》软件设计=》软件编码=》软件测试=》软件部署=》软件验收的各个环节。各个环节间既相互依赖，又可能相互迭代。

一环套一环，很更容易就陷入死循环的怪圈。例如，我们很容易就想到瀑布模型存在的以下缺点：

1. 项目前期耗费大量的时间进行需求调研、编写了一大堆写完就过期的文档。
2. 软件交付时，大量层出不穷的bug和需求变更。
3. 客户对软件更改和研发的脑力支出并不认同等。

我也经常听到项目经理们的吐槽。尤其从医疗行业的项目经理那里听到了最多的吐槽。在过去若干年的发展过程中，医疗信息化领域的发展特别快。但是由于医疗卫生行业涉及的领域太广，所以让标准化产品的研发过程变得非常困难，现在依然有许多医院的信息化系统都是以定制开发为主。而这些实施定制化开发软件的公司，承受的巨大压力常人难以想象。不同的院系、不同的医生对需求的不同理解或者各种需求上的变化，总是让开发者来回倒腾而无可自拔。上次就听说长沙某大型HIS企业的技术总监，为了给客户填坑，直接倒在了医院的办公室中，还好处理得当，不然还不知道会带来什么后果。

除了HIS领域外，制造业甲方爸爸也擅长给乙方掘墓。他们的技能是甩锅。由于流程众多、涉及的人数广，所以要确认需求是一件非常困难的事情。这种情况下，除了绞尽脑汁应付其中，根本没有更好的办法。关键是他们中许多人还被免费软件的迷魂药给迷晕了头脑，总是认为软件开发不过是简单的码格子，肆意的扩大需求范围、更改需求，开发出大量华而不实的功能，让程序员们费力不讨好。

这些项目也是采用瀑布式开发模型的典型，试图通过前期严密的需求调研、功能设计和验收流程让客户尽可能少的变更需求，实际上却很难真正做到完全可控。所以项目很难避免不延迟，最终给公司带来了不小的负担。

在这样的背景之下，似乎敏捷是一缕曙光。

但究竟该怎么实施。这本书给出了一点参考。