敏捷领导力2.0培训体会

参加敏捷领导力2.0北京站的培训课程，时间为期是三天，在这三天的时间里，从第一天的“一起走进敏捷，深入学习敏捷知识精髓”，第二天的“高效敏捷落地，巧变革有章法的落地法则”到第三天的“经典案例解析，解决敏捷落地的痛点”，总体来说感觉还是不错的，理论+实践经验+工具，应该是不错的搭配。也谈谈这几天的课程收获和思考的问题,总结如下：

首先，关于敏捷的宣言（Agile Manifesto）:

l  Individuals and interactions over processes and tools

l  Working software over comprehensive documentation

l  Customer collaboration over contract negotiation

l  Responding to change over following a plan

基于之前的理解，关于这四条宣言中的over一次觉得有了更深刻的理解；有区别的是之前的理解是基于个别敏捷的“粉丝”或激进者的误读，什么叫“不需要”和“不要”等。敏捷相当于《笑傲江湖》中的“独孤九剑”，无招胜有招，但要看谁来用，并不是人人都可以的，只有风清扬这样的super senior前辈，和令狐冲那样的supersmart晚辈才可以真正用得上“无招胜有招”，才能真正的用上“不要”而将over这样直译过来。我等泛泛之辈只能将其翻译为“胜于”也就是说，对于绝大多数（99.99999%）的团队而言，在敏捷开发中，方法、文档、工具合同以及计划都是必须的，区别在于要让它们的存在更合理有效，不要动辄就是几百页无人愿看的文档。

其次，Be Agile rather than do Agile：

敏捷的本质是要找出开发流程中不合理和浪费资源的内容，并加以改进。只要所做的工作能达到这样的效果的我觉得就是一种适合你的敏捷方法。而并不一定说是必须遵循别人的已有的方法和步骤才叫敏捷。而且往往是公司、人员和项目性质等不同，别人成功的敏捷应用绝大多数情况下是不适合你的。

现在的敏捷开发，往往遇到两个极端:要么很好，要么很糟！这和当年软件企业推广ISO9000或者后来的CMM区别很大。

做ISO9000对于企业来说就是做出一堆文档，装帧漂亮后，放进文件柜，锁好，然后……就没有然后了。所有工程师对这些内容基本上无感。ISO9000毕竟诞生于传统的的机器生产工业时代，用这套老办法来衡量新兴的不断变化的软件企业，实在有些别扭。

然后就有了CMM，CMM（Capability Maturity Model for SoftWare）听着就大气了很多，“软件能力成熟度模型”，不是什么冰冷的“标准”，程序员们看着这个模型就受用很多。一家企业能评上CMM的高级别是件很荣耀的事情。一时间各企业分分大上快上CMM评级。但是在CMM实施过程中很多一线程序员仍然无感。最大的区别就是所在柜子里的有一堆工业标准文档变成了另一堆更有软件特色的标准文档。而且在所有获得了CMM5级的顶尖企业中，某国的软件外包占了很大的比例，而一些无论从技术含量、创新能力或产品品质都属于全球顶尖的企业却只获得了更低的3或4的评级。这是一件很奇怪的事情！

其实，无论是ISO9000还是CMM，他们的核心都是在于“控制”。

管理者们希望通过各种流程、各种规则来控制软件开发过程中的信息、思想、行为，来获得对未来的产品的安全感。

EricSchmidt在《How Google Works》中强调：“ When it comes to communications, default to open. Maximize thevelocity and volume of information flow.”（谈到沟通，最基本的就是开放。这样使得信息流动的速度和数量最大化。）

但在扁平化的敏捷组织中，由于信息的充分流动，有才华的工程师可以有更多的机会给产品直接带来价值，也更容易因为自我实现而被“激励”。其实优秀的工程师就在那里，他们需要的只是一个没有信息围栏的舞台！

现在的世界已经是扁平的世界，充满不确定性！拥抱变化，就是要拥抱不确定性！任何一个管理者都不会认为一个热衷于迷幻剂、不会码程序的文青会成为全球IT界的大神，任何一个管理者也不会认为“一群找不到工作的年轻人”能创立世界上最大的电商企业。今天做游戏软件的公司，明天会去做手机；今天做支付系统的公司，明天会去造汽车、甚至星际火箭。信息围栏除了最终围住了自己的手脚和竞争力、其实什么也围不住。

计算机领域中有个古老而简单有效的算法叫冒泡排序（BubbleSort）。Bubble Sort能够把一个失序的系统重新排序，同时并不需要把整个系统全部推倒重新排序，而只需要系统中的每个对象和自己身边的对象做个比较，根据比较结果来交换位置，这样只需要很少的几轮交换，最后整个系统就象气泡在水中自然而然地上浮那样自然而然地实现了排序。扁平化的工程师文化就象这个Bubble Sort一样，能够把整个组织中各个成员的创新和价值最快地呈现出来。

所以，不管是不是使用敏捷模式，信息的通畅高效流动都是工程师团队在充满不确定性的IT世界幸存的关键之一。管理是作为价值的连结者和传递者而服务于信息流动、服务于创造力。

再次，关于scrum：

Scrum敏捷管理的创始人Jeff Sutherland，是一名程序员：他不仅能码代码，还写了怎么码代码的书。

Scrum的本质就是通过各种Scrum工具实现产品开发的扁平化管理，以最大限度的激发工程师的主动性和创造力。

如何做到“尽量不控制”。这里举两个例子也许可以帮到有此类疑惑的同学。

MichaelJordan时代Chicago Bulls的传奇教练PhilJackson一直有个习惯：他在赛场上很少去请求暂停，即便是球队落后的时候，他往往都是让球员自己去解决问题，除非是球队真的是出现了无法解决的问题。教练做的更多的是观察、协助、服务和启发的工作。

SteveJobs虽然以极强的控制欲著称，但更被称为是个“好教练”，他“鼓励员工互相竞争”，“对于结果，他很苛刻，但总是非常公正”，“总是能让人受益匪浅”。苹果公司采用扁平的环状组织结构，员工的工作都“十分独立，只有很少的微观管理”。或者说，苹果的这种控制，更多的是拒绝平庸，而不是要控制工程师。

软件互联网产品开发风险有很多，根本上就是一个：“不确定性”。面对不确定性，更多地控制动作并不会使它变得更确定。也许正是因为这个优美的不确定性带来了更多的可能性和创造性，所以Donald Ervin Knuth和Eric S. Raymond会把Programming称之为艺术(Art)。面对“不确定性”，有时候不妨“让子弹再飞一会”。直面SDA。

最后，总结：

l  没有敏捷开发，也可能开发出好的产品。应用了敏捷开发，也未必能开发出好的产品。这就像很多企业都在学丰田的精益生产（Lean Production，或称看板生产），但能做到丰田那样的屈指可数。因为你可以学丰田的流水线和管理流程，但你学不到丰田的工程师文化。

l  敏捷应该更注重于激发内在驱动力，而不是对比与传统只是换一种外在的管控方式

l  团队敏捷文化，科室文化是由团队成员的做事风格决定。成员可以自我驱动就可以实现扁平化管理，否则只能集中管理，所以是否可以形成高效的敏捷实践关键在于能不能找到自我驱动的员工，否则都是空谈。三观成型多年的人能通过培训突然就开始自我激励不太现实，培训不是传销。真正优秀的工程师，其实不需要过多的管理。知识体系和经验已经能使自己不断进步。

l  敏捷开发的成功基于扁平化管理和开放的企业文化。是思想的变革。