引言
2015.5.28，携程网宕机，消耗了10几个小时才恢复，每小时的损失高达100万美元。作为随时处于变化之中的互联网公司，发生事故总是难免的，但在这次宕机中对突发事件中响应得不够灵活顺畅，就很难被接受了，据说几位高级总监已经被开掉了。
近年来，不论大型还是初创公司，纷纷引入敏捷软件开发的理念，遍地开花。敏捷在不同的组织中以不同的形态出现，Scrum、看板、甚至精益创业等等，无不围绕快速迭代和改进的研发理念展开。强调需求分拆，时间分拆，进度可视化，利用度量进行改进等实践，来提高组织协作的顺畅度，提高灵活性以满足随时变化的业务需要。老板、销售、产品经理、项目经理、过程改进人员、开发测试人员都能听得懂，然后开始导入，不亦乐乎。
一段时间后，爱思考的管理者就会冒出一些疑问，怎么开了很多会没是觉得配合不顺畅？怎么还是感觉进度不快？质量也没见提高？于是乎，很多人就都会给出分析：比如开站会的姿势不对，比如看板不够漂亮，比如度量手段不完善，比如团队缺乏正能量，等等。总之，都还是强调深化过程改革和意识培养。但现状却是仍然觉得组织协作不够顺畅，以至于对市场事件和业务需求变化不能够及时响应，业务总是觉得一点需求变更就会花很久才能完成，最终客户方的满意度提高缓慢。
题图中少年星爷，刚刚买到一本《如来神掌》，就以为自己真的会功夫了？
意识转变
人的意识转变是很困难的，却是任何行为改变的最重要的前提条件，因此敏捷导入往往要先进行培训，统一认识。第二步才是过程导入，引入Scrum、Kanban等重新建立和优化流程、过程、协作方式等，也称为从管理2.0到管理2.5的阶段。
问：世界上最远的距离是什么？
答：从头到脚的距离。
理论概念容易讲，但是实际做出来却没有那么容易，这之间的gap可能会非常之大。德鲁克喜欢把组织比作一个球队，而我在讲课时也喜欢用一个通俗的说法：好比你是个足球运动员，当你看到球飞过来，脑中已经很清楚该怎么跑怎么接怎么传，可是双腿就是不听使唤，跑不快，一用力甚至滑倒、抽筋。这就是能力不足。
怎么办？需要实际的锻炼，练体能、练配合、练战术、练基本功。对于软件开发来说，要练习的正是如何将“可工作”的软件产品生产出来！
怎么练？你需要请一位教练，同时这个教练必须要拿出一套训练方案给球员。如果一个教练只会用夸奖和感谢来给球员注入所谓正能量，然后就让球员自己去练，这是不够的，因为球员的确不太知道该怎么练才有效。最后球员在场上还是会因为肌肉和技巧跟不上，而无法完成技战术的布置。教练可以不必曾经是最好的球员，比如穆里尼奥，但一定有根据自己的经验总结出一套训练方案。
笔者从2007开始亲身实践敏捷开发。当时完全不懂敏捷，就被加入了一个新成立的Scrum团队中摸爬滚打。从一个普通工程师，在迷惑和不断尝试中成长为研发经理和敏捷教练，现在又在进一步传播敏捷给自己的咨询客户。我觉得，除了思维教育和过程管理，敏捷能力建设在敏捷转型中不可或缺。能力的英文是Competence，也包含胜任力的含义。
光有过程管理，不足以生产出“可工作”的软件。光有说教和鼓励，也不足以让大家真正行动起来。从教练的角度，我们相信每个人都是一个完整的人，有能力独立地自我觉察和完成任务，但现实是，对于胜任力和能力这个方面，团队成员往往缺失了很多东西，特别是在IT技术日新月异的这个时代，我更倾向于认为很多人的能力不够完整。
能力建设
那么作为一个敏捷组织，需要哪些方面的能力建设呢？
- 对所用语言、框架、设计模式、范式的掌握。这个不多讲，基本功和经验，同时还有快速学习的能力。前者靠刻意的练习，朝着10000小时去努力。后者靠经验和悟性，对于如此丰富的知识，没人能掌握全部，但有一点必须精通，那就是快速有效的google技巧。
- 框架和架构支持。敏捷的目标在于提高灵活性。我们知道，背着一个大包袱是走不快的。软件也是一样，得把不需要做的事情最小化。基于“在有限时间内做最有价值的事情”，能通过框架、第三方库解决的，尽量就不摇自己重复造轮子。包括ORM、安全防御、依赖管理、缓存管理等等。这对于追求速度，特别是快速产品开发，那么站在巨人的肩膀上可以节约大量时间。
- 模块化，松耦合，化整为零。各种敏捷流派都强调化整为零的好处，其背后的理论可以追溯到排队论和流动管理，这里按下不表。对于软件产品，最基本的原则就是高内聚低耦合，只有将软件进行更精细的模块化，让每个模块可以相互对立，减少依赖，这样，当改动一个模块时，其他模块不受影响，减少出问题的几率，并且回归测试的成本非常低，可以迅速上线。
- 技术债务和重构能力。“熵”的概念是整个宇宙的公理，软件产品中也存在“熵”的概念，意味着软件的设计和结构会随着时间变得原来越混乱，越来越难进行维护和修改，使得添加新功能越来越慢，越来越不敏捷。欠下的债，总是要还的（虽然不一定是自己还债：p）。重构能力是还债的关键，只有不再欠新债，才有可能还清旧债（除非你像美利坚一样根本不想还债）。管理者需要了解和建立重构能力，要求团队随时对代码进行调整，保持响应变化的水平。而不是等到代码无可救药的时候去重写整个代码，那么在这段期间之内，响应变化的水平就跌到零了。
- 自动化与持续集成。敏捷强调利用各种自动化手段加速反馈，形成持续集成实践。持续集成能力是整个组织的能力，从上游需求提出到最终上线，能否将一个业务想法分解、实现，再集成到一起，这体现了组织的敏捷性，缺一不可。看看现在代码库中有多少个分支，编写代码与合并代码的时间消耗各是多少？多久能把代码集成到一起？如果服务器宕机，能否快速地重建整个生产环境？
- 工具、电脑与网络的速度。效率如果不高，对变化的响应也会变慢，灵活性自然上不去。看看团队的开发人员，还在用性能低下的电脑吗？启动慢，编译慢，时不时机器狂卡，Windows蓝屏，各种技术网站打不开。写Java的程序员还在用Eclipse？何不试试IntelliJ，效率立刻提高一大截。团队还在用SVN？何不试试GIT，效率立刻提高一大截。团队的精力不应该花在这些无谓的等待上面，别让效率低下的开发环境阻碍了协作的顺畅度。
管理者的行动
为了让IT组织更快地响应变化，居然需要有要建设的能力。那么你作为一个掌握权力和话语权的管理者，你要如何行动呢？
- 理解。承认自己对编程、对现有技术债务、对程序员思维、对开源世界、对交付能力的不了解。静下心来，找信得过的明白人去理解一下现状。
- 授权。对于管理者来说，敏捷和互联网时代下应该充分吸收管理3.0的理念，承认组织是一个复杂系统，承认作为一个管理者对于技术的细节了解得很少。那么就在目标清晰的前提下，更多地授权团队来自己找到答案，用什么IDE工具，用什么框架，用什么协作模式。少一些自上而下的控制与流程，多听听基层的说法和建议。让团队自发形成内部约定，团队才更有意愿去执行。在管理3.0时代，能力=技能x纪律。前面说的几项都是技能方面的，但没有纪律做保证，再好的戏也出不来。
- 培养。在教练和顾问协助下，制定培养方案，可能包括：培训、手把手辅导、编程静修日、代码拉力赛、代码竞技场、内部匠艺师认证等。然后予以支持，移除障碍，营造一个可以让大家按照新的敏捷方式继续走下去的环境和道路。
总之，培训、意识转变、过程改进、导入看板和Scrum等对于实施敏捷转型都是必要但不充分的，是快不起来的。要深化改革，真正挖掘出组织潜力，管理者就需要主动营造成长的环境，并施以营养和抚育，支持团队生长出上面提到的各项能力。只有这样，敏捷才能真正落地，并体现在交付和产出上面。愿大家都跨越从头到脚的距离，达到身心合一的状态。
