敏捷转型该怎么转？来看看这本书怎么说的吧

简介

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

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

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

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

 

---

本文版权归原做者和博客园共同拥有。做品采用知识共享署名-非商业性使用-相同方式共享4.0 国际许可协议进行许可。 

 

      本文来自： 溪源 | 长沙.NET技术社区。阅读更多精彩好文，欢迎关注长沙.NET技术社区公众号【DotNET技术圈】。