如何进一步提高敏捷组织的灵活性和顺畅度?

引言

2015.5.28,携程网宕机,消耗了10几个小时才恢复,每小时的损失高达100万美元。作为随时处于变化之中的互联网公司,发生事故总是难免的,但在这次宕机中对突发事件中响应得不够灵活顺畅,就很难被接受了,据说几位高级总监已经被开掉了。

近年来,不论大型还是初创公司,纷纷引入敏捷软件开发的理念,遍地开花。敏捷在不同的组织中以不同的形态出现,Scrum、看板、甚至精益创业等等,无不围绕快速迭代和改进的研发理念展开。强调需求分拆,时间分拆,进度可视化,利用度量进行改进等实践,来提高组织协作的顺畅度,提高灵活性以满足随时变化的业务需要。老板、销售、产品经理、项目经理、过程改进人员、开发测试人员都能听得懂,然后开始导入,不亦乐乎。

一段时间后,爱思考的管理者就会冒出一些疑问,怎么开了很多会没是觉得配合不顺畅?怎么还是感觉进度不快?质量也没见提高?于是乎,很多人就都会给出分析:比如开站会的姿势不对,比如看板不够漂亮,比如度量手段不完善,比如团队缺乏正能量,等等。总之,都还是强调深化过程改革和意识培养。但现状却是仍然觉得组织协作不够顺畅,以至于对市场事件和业务需求变化不能够及时响应,业务总是觉得一点需求变更就会花很久才能完成,最终客户方的满意度提高缓慢。

刚刚买到一本《如来神掌》,就以为自己真的会功夫了?

意识转变

人的意识转变是很困难的,却是任何行为改变的最重要的前提条件,因此敏捷导入往往要先进行培训,统一认识。第二步才是过程导入,引入Scrum、Kanban等重新建立和优化流程、过程、协作方式等,也称为从管理2.0到管理2.5的阶段。

问:世界上最远的距离是什么?
答:从头到脚的距离。

理论概念容易讲,但是实际做出来却没有那么容易,这之间的gap可能会非常之大。德鲁克喜欢把组织比作一个球队,而我在讲课时也喜欢用一个通俗的说法:好比你是个足球运动员,当你看到球飞过来,脑中已经很清楚该怎么跑怎么接怎么传,可是双腿就是不听使唤,跑不快,一用力甚至滑倒、抽筋。这就是能力不足。

怎么办?需要实际的锻炼,练体能、练配合、练战术、练基本功。对于软件开发来说,要练习的正是如何将“可工作”的软件产品生产出来!

怎么练?你需要请一位教练,同时这个教练必须要拿出一套训练方案给球员。如果一个教练只会用夸奖和感谢来给球员注入所谓正能量,然后就让球员自己去练,这是不够的,因为球员的确不太知道该怎么练才有效。最后球员在场上还是会因为肌肉和技巧水平跟不上,而无法完成技战术的布置。教练可以不必曾经是最好的球员,比如穆里尼奥,但一定有根据自己的经验总结出一套训练方案。

笔者从2007开始亲身实践敏捷开发。当时完全不懂敏捷,就被加入了一个新成立的Scrum团队中摸爬滚打。从一个普通工程师,在迷惑和不断尝试中成长为研发经理和敏捷教练,现在又在进一步传播敏捷给自己的咨询客户。我觉得,除了思维教育和过程管理,敏捷能力建设在敏捷转型中不可或缺。能力的英文是Competence,也包含胜任力的含义。

光有过程管理,不足以生产出“可工作”的软件。光有说教和鼓励,也不足以让大家真正行动起来。从教练的角度,我们相信每个人都是一个完整的人,有能力独立地自我觉察和完成任务,但现实是,对于胜任力和能力这个方面,团队成员往往缺失了很多东西,特别是在IT技术日新月异的这个时代,我更倾向于认为很多人的能力不够完整。

能力建设

那么作为一个敏捷组织,需要哪些方面的能力建设呢?
1.对所用语言、框架、设计模式、范式的掌握。这个不多讲,基本功和经验,同时还有快速学习的能力。前者靠刻意的练习,朝着10000小时去努力。后者靠经验和悟性,对于如此丰富的知识,没人能掌握全部,但有一点必须精通,那就是快速有效的google技巧。
2.框架和架构支持。敏捷的目标在于提高灵活性。我们知道,背着一个大包袱是走不快的。软件也是一样,得把不需要做的事情最小化。基于“在有限时间内做最有价值的事情”,能通过框架、第三方库解决的,尽量就不摇自己重复造轮子。包括ORM、安全防御、依赖管理、缓存管理等等。这对于追求速度,特别是快速产品开发,那么站在巨人的肩膀上可以节约大量时间。
3.模块化,松耦合,化整为零。各种敏捷流派都强调化整为零的好处,其背后的理论可以追溯到排队论和流动管理,这里按下不表。对于软件产品,最基本的原则就是高内聚低耦合,只有将软件进行更精细的模块化,让每个模块可以相互对立,减少依赖,提高设计的可逆性,降低由于提早决策而带来的风险成本。通过分而治之,将复杂问题简化为一个一个的小部分,这样,当改动一个模块时,其他模块不受影响,减少出问题的几率,并且回归测试的成本非常低,可以迅速上线。
4.技术债务和重构能力。“熵”的概念是整个宇宙的公理,软件产品中也存在“熵”的概念,意味着软件的设计和结构会随着时间变得原来越混乱,越来越难进行维护和修改,使得添加新功能越来越慢,越来越不敏捷。在敏捷设计中,良好的模块化与分层设计是通过不断重构获得的,要不断精简和提炼问题域,通过隐藏细节来简化问题。欠下的债,总是要还的(虽然不一定是自己还债:p)。重构能力是还债的关键,只有不再欠新债,才有可能还清旧债(除非你像美利坚一样根本不想还债)。管理者需要了解和建立重构能力,要求团队随时对代码进行调整,保持响应变化的水平。而不是等到代码无可救药的时候去重写整个代码,那么在这段期间之内,响应变化的水平就跌到零了。
5.自动化与持续集成。敏捷强调利用各种自动化手段加速反馈,形成持续集成实践。持续集成能力是整个组织的能力,从上游需求提出到最终上线,能否将一个业务想法分解、实现,再集成到一起,这体现了组织的敏捷性,缺一不可。看看现在代码库中有多少个分支,编写代码与合并代码的时间消耗各是多少?多久能把代码集成到一起?如果服务器宕机,能否快速地重建整个生产环境?
6.工具、电脑与网络的速度。效率如果不高,对变化的响应也会变慢,灵活性自然上不去。看看团队的开发人员,还在用性能低下的电脑吗?启动慢,编译慢,时不时机器狂卡,Windows蓝屏,各种技术网站打不开。写Java的程序员还在用Eclipse?何不试试IntelliJ,效率立刻提高一大截。团队还在用SVN?何不试试GIT,效率立刻提高一大截。团队的精力不应该花在这些无谓的等待上面,别让效率低下的开发环境阻碍了协作的顺畅度。

管理者的行动

为了让IT组织更快地响应变化,居然需要有要建设的能力。那么你作为一个掌握权力和话语权的管理者,你要如何行动呢?

  • 理解。承认自己对编程、对现有技术债务、对程序员思维、对开源世界、对交付能力的不了解。静下心来,找信得过的明白人去理解一下现状。
  • 授权。对于管理者来说,敏捷和互联网时代下应该充分吸收管理3.0的理念,承认组织是一个复杂系统,承认作为一个管理者对于技术的细节了解得很少。那么就在目标清晰的前提下,更多地授权团队来自己找到答案,用什么IDE工具,用什么框架,用什么协作模式。少一些自上而下的控制与流程,多听听基层的说法和建议。让团队自发形成内部约定,团队才更有意愿去执行。在管理3.0时代,能力=技能x纪律。前面说的几项都是技能方面的,但没有纪律做保证,再好的戏也出不来。
  • 培养。在教练和顾问协助下,制定培养方案,可能包括:培训、手把手辅导、编程静修日、代码拉力赛、代码竞技场、内部匠艺师认证等。然后予以支持,移除障碍,营造一个可以让大家按照新的敏捷方式继续走下去的环境和道路。

总之,培训、意识转变、过程改进、导入看板和Scrum等对于实施敏捷转型都是必要但不充分的,是快不起来的。要深化改革,真正挖掘出组织潜力,管理者就需要主动营造成长的环境,并施以营养和抚育,支持团队生长出上面提到的各项能力。只有这样,敏捷才能真正落地,并体现在交付和产出上面。愿大家都跨越从头到脚的距离,达到身心合一的状态。