何勉谈大型敏捷团队的管理
个人简介 何勉，ALU（阿尔卡特-朗讯）某重要大型通信设备的软件开发团队负责人，有丰富的软件设计、开发和项目及团队管理的经验，上海贝尔最早的敏捷开发的实践者及推动者，正致力于团队向敏捷开发的全面转型。
敏捷中国大会是国内敏捷技术领域最高水平的大会。今年的敏捷中国大会（AgileChina 2009），以Pragmatic Agile为主题，参会者以高端开发者和技术管理者为主，融合管理和工程实践，推广全面敏捷之路。
1. 何勉先生您好
您好，顾全
2. 我们今天简单的跟您做一个采访，您在Agile以及开发方面有很多经验，今天想跟您聊一聊有关，尤其是在团队以及组织方面要为敏捷做出什么样的改变以及做出什么样的努力，这样一些问题？首先您能做一下自我介绍吗？
你好，我叫何勉，我是从事软件项目管理、团队管理以及产品相关的一些管理的工作。从2003年开始我开始做特征驱动开发，然后从今年年初我们在团队中开始全面的大规模的引入敏捷软件开发方法，包括他的管理实践和工程实践。
3. 那么您认为如何做到这个团队的自组织呢，因为很多人认为做到团队自组织是个很漫长而困难的过程，不知道您是不是同意，然后在具体的做法上有什么经验或者教训可以跟大家分享呢？
我觉得团队自组织的确是一个很漫长的过程，中间会有很多的误区和困难。但是我觉得还是要去分步骤去做这件事情，特别是在一个大型的组织当中，我们这件事情不可能一蹴而就。首先对于我们，我们是希望去分三步走去做这件事情，比如说第一步，我们还是希望发觉真正有意愿的团队，从组织的层面能够给他足够多的帮助。但是我们也在这一阶段就需要这个团队做出承诺，就是我们给他们帮助更多的支援，比如说培训、咨询这方面的，但是我们需要他做出承诺将来可以分享他们的经验。这时候我觉得这个组织要准备接受改变，提供比较宽松的环境，而且它也不应该去设置一个真正的框架或一个敏捷的流程说你应该怎么样做，应该怎么样做，但它可能会有一些最简单的限制条件，因为敏捷在很多的时候还是被误解的。比如说他限制的条件是你应该是迭代交付的，你应该是保证质量的，而作为一个团队，这时候你需要有接受改变的勇气。在第二阶段，我们希望在第一阶段团队实践的基础上更多的去推广，这个更多的推广我们包含向更多的组织、更多的团队去推广，也包括向更大范围去推广，也就是说更多的业务部门。在第一阶段我们可能还是仅仅局限于一个研发的或者开发的部门，这时候我们需要推广到产品定义部门，市场和Solution的部门，甚至于如果对于一个设备制造商还要包含生产和产品的发布，第二阶段会有很多困难，因为在第二阶段的团队他可能困难比第一阶段要来的多一些，因为这时候公司能够提供的资源会更少，因为它的规模更大了嘛。所以我们不能忽视这种困难，就要求在第一阶段已经取得成功的组织他们要履行他们的承诺，分享自己的经验和分享自己成功的故事，给那些刚刚走向敏捷道路的人以更多的勇气。然后，作为在第一阶段已经实施的团队，我们这时候不能停步，我们需要持续的去优化，因为你在第一阶段可能有选择的进行了一些实践，这时候我们需要从各个纬度，比如说在第一阶段我们可能在管理、在计划方面已经做到了，到第二阶段我们就可以在技术方面，比如说你的驱动开发，你的可执行的需求这些方面取得了一些进展所以需要持续的优化过程。而真正我想一个组织要想在敏捷方面取得很好的效果是需要走这些端到端的全面的业务敏捷的，这就是我们第三阶段要做的事情。要能打破组织中间的隔阂，然后实现组织内部真正的端到端的业务敏捷，这时候是特别特别需要勇气的。因为任何一个组织都有自有的工作方式，自有的文化，甚至于是自有的利益分配，这时候你需要一个组织有这样的决心、这样的意志、这样的勇气去做业务流程的全面调整。也只有做到这样，我们觉得才能真正的实现一个组织在商务上的从敏捷得到它应有的回报，总体上来说这是我们希望分步去做的，我们希望去契合一个组织的意志和作为一个工程师或者一个团队的意愿来实现敏捷价值的最大化，取得商务上的成功。
4. 那么在这样的一个敏捷的团队里面，各种各样的角色、各种各样的不同级别、不同背景的人在一起工作，他们其实还是要遇到很多的挑战，那么您认为是不是每个人都适合在敏捷团队工作，您相信这一点吗？
我相信绝大部分人适合在敏捷团队的工作，我同时也相信并不是每一个人都适合在敏捷团队里面工作。但是既然我们选择了敏捷，我们就要义无反顾的去走，不能因为某一些人，而这些人是绝对绝对的一小部分，他不适合敏捷的开发，我们就对此有所怀疑。正如《从优秀到卓越》这本书说的，我们让适合的人上车，让不适合的人下车，这时候可能是壮志断腕组织不得不做得一些牺牲，即使这个人很优秀，但是为了整体的利益我们是不得以的选择。
5. 其实这样的话也有可能将他放到了真正其实他所适合的地方，对他也是一个推动？
我相信是的，另外我也相信在执行的过程中，有些本来看来不适合的人实际上是适合的，当我们有更多的成功的故事去分享，他有些人会加入到这些成功的进程当中去的，所以，我相信不适合的人是绝对绝对的少数。
6. 当然各种各样的敏捷团队也有成功的、也有不太成功，很不成功或者失败的，那么您觉得，就您的观察成功的团队和他的成员需要怎么样的一些特质？
首先我们不说从成员上去看，因为我们假设每一个人都是有追求卓越的机会的，我们说从团队的组织上去看，成功的团队和不成功的团队。但是我觉得还是需要一个领导，需要一个领导似的人物去把这个团队搭建成一个精益的或者敏捷的环境，我觉得这是必要的。然后，但我也觉得你需要了解自己，也需要理解敏捷。了解自己就知道你真正想要的是什么，理解敏捷是真正的理解敏捷的价值，敏捷的原则，而不是仅仅的照搬，或者局部的去搬一些敏捷的实践就号称我们敏捷了。至于失败，我觉得我看到的一些典型的失败就还是对价值的违背，如果我们一定要用一个词来形容，我们会说scrum bad，比如说因为他不理解这些价值和原则，说我们做Scrum，但是我们没有standup meeting。我们做agile，但是我们每个迭代没有测试，那么这些都是对一些基本原则的违背，所以我认为这个是失败的主要原因。
7. 就是说学到了形没有学到神？
对，完全同意。
8. 我也觉得要想成功一定是要真正拥抱敏捷背后的理念，因为这个agile process本身还是比较简单的？
我们说简单，但简单不意味着容易。我们说跑马拉松很简单，只要跑42点几公里，你如果跑42公里再回来就是双程马拉松，都很简单。但是简单不意味着容易，这是个很艰苦的工作，需要更多的坚持和勇气。
9. 说得非常好，其实在敏捷团队中因为会有一个role sharing角色这种共享的要求在，尤其是在现在的一些大型的组织机构中，它会有很详细、很明确的分工。那么有一些人他们也希望自己的职业发展是专心于某一方面的，那么如何能够在这样一个敏捷的环境中平衡这两点，或者处理之间的这个冲突呢，您认为有冲突吗？
我认为有一定的冲突，首先差异是绝对的。但是在这种绝对差异的前提下，因为组织中一般有所谓的knowledge area，我觉得这个可以被接受，但是什么时候不可以被接受？就是当你的knowledge area划的太细的时候，这时候就会产生很多的副作用。第一，我们需要有系统的思维，当你对你的周边不了解的时候，你在本系统内部或者本area范围内部也很难处理好这个问题。第二，当你的knowledge area的划分使你变成一个限制，你进行任何项目都必须把很多人组织到这个团队里来，而这些人可能每个人的工作量都很少，这样就增加了沟通的成本和沟通的渠道。而且每个人可能因为在每个项目中所承担的工作都很少，他就不得不被分到多个项目中去，不得不频繁的切换项目的context，这样是一个有很多副作用的行为，所以我觉得在这里面需要一个平衡。我们承认knowledge area差距，但是我们也希望大家更多的扩展，比如说我们承认做硬件驱动开发的和做上层应用开发的是有差别的，但是我们希望在上层应用之间能够有更多的共享。事实上我认为敏捷的很多实践在这方面是提供了帮助的，比如说它的结对编程，如果一个团队很多人能去结对编程，这种knowledge share会更快的发生所以敏捷要求更多的知识共享，敏捷也支持更多的知识共享。
10. 那么其实在很多敏捷团队中，比如说我自己的敏捷团队中很多人我都认识，刚刚毕业的学生，那么你对他们在这个职业发展方面有什么样的建议吗，他跟普通的传统项目中发展是不是有不同呢？
我上次说，首先，如果一个刚毕业的学生加入敏捷团队，我要恭喜他，因为他有了这样的机会在短时间之内很快的可以build knowledge。因为一个人学习的速度不完全取决于，甚至不主要取决于他有多努力，而取决于他的环境，在敏捷开发环境下，我们造就了这样一种环境，使每个人都可以向其他人去学习，实现了集体的学习，实现集体的卓越。所以说，我们希望通过整个系统或者整个组织去拉动他到一个高的水平，而不是为这个组织设定一个绩效标准，而把组织中的高手向下拉动到这个绩效水平之上，所以我必须要恭喜这些新进入敏捷团队的学生，他们有这样的机会也希望他们珍惜这样的机会。
11. 然后有一个我觉得是众说纷纭的问题，就是有关敏捷团队中的各种绩效考评，我个人其实也对这一点完全没有把握说是不是应该做，有一些人我认为他们可能是相对比较激进，他们认为在敏捷团队中不应该做各种绩效考虑，那您是怎么看的？
我个人属于比较激进的一类，但是在一个组织中，它有这样那样的限制，我只说我个人的观点。我认为在敏捷组织中不应该有绩效考评，绩效考评应该是针对团队去做的，当然人是有差距的，人的技术层次是有差距的，我支持对这种差距设定等级，也就是他的技术的level。但技术的level不应由他的绩效决定，而是由他实际达到的技术水平，可以由专家评审委员会来评定，可以由大家公认的推举，可以因为他的资历，我说的资历就是他成功的经历所积累以及多方面的因素来决定他技术的level。但技术的level不应该去跟你的项目的绩效相关。事实上在敏捷中，我们假设的是每一个成员都愿意为组织付出他的努力，这是他的一个价值观的基础，所以在这时候我们再去对个人进行所谓的绩效考评，事实上会损害组织的一个motivation也好，一个士气，这也仅仅是我的个人的观点。但是我觉得这是从上世纪50年代或者60年代，不管是德鲁克或者戴明他们提出来的，也是说了绩效考评或在设计绩效标准对团队的伤害，我们今天再次讨论这个问题也不过只是重温大师们当时的语言。
12. 但是有一些人会说，那这样的话，这个敏捷团队是不是就属于共产主义大锅饭了？有人会有这样的问题，那你如果只是进了就可以，那这里边会不会有人的确他就不愿意工作或者是？
首先如果能在大锅饭吃的很好，山珍海味大块吃肉，大碗喝酒，何乐而不为呢？至于你说有人不愿意为这个东西付出，我觉得没有这样的担心。事实上你把人假设成一个什么样的人，你的团队里的人就真正会变成这样的人，而且事实上在敏捷中，我看到的是一些敏捷中的规则，团队的规则，它会产生一些社会压力，然后敏捷的实施会避免这种情况的发生。最后一步我们刚才说到让适合的人上车，让不适合的人下车，这就是我们所说的如果真有这样的人，我们会让他下车，而说我们团队会让他下车，他融入不了这样的团队。
13. 也就是说这个团队会有一种类似挤出的这样一个效应？
对，这个词很好。
14. 可能大家如果合作很愉快，有一些人会受到这种伙伴压力？
对的，所以一种社会压力，对于刚才说我们说他还会分技术的等级，我是希望创造一种工程师的文化，创造一种对技术卓越的一种专注或者一种氛围。
15. 但是同时又避免了很多恶性的竞争？
是的，我们只承认技术，我们不承认靠那种恶性的竞争产生的绩效。
16. 然后您认为如果要在整个组织中推动敏捷，应该是自上而下，还是自下而上，哪种方式更好呢？
其实刚才说转型的步骤时候我也提过，我想是两个方向都要同时做，在不同阶段可能需要采取不同的方法。我们说了公司的高层或者决策层往往是有这样的意志的，业务的敏捷，当然如何实施，他们可能不见得真的完全了解，或者做到心中有数。而且作为一个工程师，或作为工程师团队，我们有实现和最大化自我价值的意愿，所以不管是我们都要利用好这个意愿和意志，所以我们只需要自上而下，也只需要自下而上，但在不同的阶段需要用不同的方法。比如说我觉得最早不适合自上而下，或者自上而下的方式值得商讨。在最早的时候，自上而下如果我们是强制去说你必须今年做到敏捷，这个我觉得不是个有效的方法，但最早的自上而下我觉得应该是创造一种氛围，传播一种价值和理念，而且在公司的各种认可的体系当中，也要体现我有这样的决心，而这是后来我们刚才说了，不应该去通过施压的方式来实现，这时候他应该做的就是发觉有意愿的团队，并帮助他们实现，然后传播这种成功的故事让大家加入到成功的进程当中来。当然这是我引用了Dave Thomas关于《程序员的修炼》里面的一句话，他说让别人加入到成功的进程当中去往往是最容易的一件事情。所以我觉得在最早我们更多的应该是自下而上，但不是说没有自上而下，而是自上而下的方式应该是更温和一点的。我觉得需要一些组织的意志、一些组织的强制在里面的，这时候是需要自上而下的，当然这时候也需要团队的配合，但是也有自下而上的成分，但是以自上而下为主。所以我们觉得，继续要自上而下，两个方向都需要在不同的阶段有不同的策略。
17. 因地制宜
对
18. 那么还有一个问题就是说，您认为要实施敏捷，一个组织他在文化上应该是怎么样？因为组织最终的落脚点还是要在组织文化上，它有哪些东西可能是不适合需要，而需要做出很多改变的？
我觉得文化上面，这个问题我没有很好的思考过，但如果今天要回答一些我能想到的，第一个他需要结果driving的，面向结果而不是面向过程的；第二个，要有一个信任的文化，他应该不管是以下对上还是以上对下都要信任和透明。我想尊重也是非常需要的，需要工程师与工程师之间的尊重，工程师与工程师之间的合作，工程师与管理者之间的尊重，工程师与管理者之间的合作和信任，我想这些都是需要的。在一个缺乏信任的组织中，我相信是很难去推动敏捷的。
19. 我们今天的问题也就大概快结束了，最后想问您一个比较俗气的问题，可能很多人都会问的，如果让您给大家推荐一本有关敏捷或者Scrum这方面的书，您觉得会推荐哪一本最好？
我觉得《敏捷开发艺术》这本书，但它主要是讲XP的一些事情的，这本书非常好，它从理念到实践都比有较好的介绍。当然如果说通用一点，我觉得还是希望大家不仅仅关注一些技术的书，可以看一些比如说精益思想、系统思考、第五项修炼，这类讲究系统思考和精益思想的一些书，我觉得还都是一些比较好的书。
20. 谢谢您
谢谢