给经理的一封信：激发敏捷团队的力量！

关键要点

• 想要一个敏捷团队成功就要给他们创造一个适合他们的环境，这是团队经理的责任

• 控制在制品数量，这样可以比对任何需求都说行的方式取得更多的成绩

• 长期来看，尊重队员的反馈需求要比做实际工作更重要

• 团队要获得支持才能达到“共享目标，共担责任”的状态，千万别因为直接进行个人管理而破坏了这一点

• 团队不同，环境不同，要容忍各种不同的工作方式和产出

敏捷并不容易。按理说它是提高效率和促进创新的最有效的办法之一，所以才几乎所有的公司都想采用它。然而事实上很多公司却从来没有享受过敏捷方法带来的好处。为什么要采用敏捷？原因不外乎尽早发布产品、关注最能创造业务价值的核心工作等，还有提高效率和质量，或者提高员工的参与热情。但不管目标是哪个，如果你没有做好一个经理该做的事，你都要承担一无所获的风险，甚至可能会导致团队的冲突和解体。

在我做为敏捷教练指导传统 IT 部门进行转型的经验里，好的坏的例子我都遇到过。敏捷失败最常见的一个原因就是团队的直接领导层不能给予团队最充分的支持，甚至有时候失败就是被这些领导设置的障碍导致的。

通常管理层并不知道他的行为到底对团队和工作是有利还是有弊。为了帮助大家，我准备给大家提一些建议，希望每一个敏捷团队的经理都能看到，包括管理多个敏捷团队的部门经理。

亲爱的经理，以下内容可以帮助你的敏捷团队获得成功：

控制在制品数量和清晰的优先级

在传统的工作模式下工作需求都直接来源于经理（直线经理、项目经理、质量经理等）。工作需求都是被认研究过的，需要的时间是被评估过的，而经理最后也会得到产出——至少是被通知一声说需求已经按要求完成了。但是在敏捷开发中，工作需求和经理之间并不是这样的一种模式。研发团队直接与客户沟通，大家的具体工作内容已经不需要等待指派，也不会事事经过评估了。这意味着经理无法掌控团队正在进行中的每一项工作，而当没有经理充当守门人的时候，某一个队员或者整个团队就都有可能会陷于需求之中而无法自拔。

工作需求可能有很多不同来源，而且通常是非正式的渠道。这意味着不管是从行动上还是心理上，正常的拒绝需求的机制已经无效了，而且通常需求一来就会被要求马上开工。当大家一接到需求就立刻开工时，那些做了一半的需求就会被打断、排后，慢慢越积越多。于是效率开始下降，很多已经开工了的需求无法收尾。之后就会形成一个恶性循环，在这种情况下所有工作都会推迟，每件优先级略高的事都要硬塞进来，令人十分痛苦。

为了避免恶性循环，打造良性循环，你就必须为需求排优先级和做限制，方法是既要在制品的数量，又要只做最重要的需求。要接受这样的现实：不是所有排在队列中的需求都会被完成的。要对你的产品有一个清晰的愿景，要有一个可靠的产品负责人，他在需求补充会议上或做迭代计划时都只会拿出最重要的需求来让大家做。要让团队明白，当他们决定了要完成多少工作之后，他们就要为承诺负责。

不管你们用 Scrum 还是 Kanban，你都要学会观察你的团队是如何限制在制品数量的，帮助他们守住那个限制。这方面的好行为有：

• 把新需求提给产品负责人，而不是直接提给团队中的某个人或者直接贴到白板上
• 问问团队为什么大家现在同时开展了过多的事情？提醒他们清楚的知道当前的状况，鼓励他们遵守最初约定的限制数量
• 用 Scrum 时约束一次迭代的工作内容范围，这样有助于提升效率，减轻压力
• 鼓励团队使用累积流程图（Cumulative Flow Diagrams， CFD）和流动负债图（Flow Debt Diagrams，FDD）来展现他们的工作进度。累积流程图有助于理解随着时间的推移事情整体进展得怎么样了，流动负债图则清晰的展现了未完成工作和已完成工作之间的对比情况，这样究竟是哪里开展了太多工作而导致不能按时提交就一目了然了。

偏离轨道很容易，但要是能马上发现的话回到正轨也很容易。你不加限制的时间越长，回到正轨所需要的时间也越长。

尊重反馈的需求

关于工作有一种普遍而幼稚的观点，就是如果你让一个团队或个人把更多的时间投入到工作上，你就能获得更多的产出。这听起来象是挺合逻辑的，但会间接造成他们没有机会去学习如何能把事情做得更好了。大多数经理只是承认这个观点而已，但几乎没人会鼓励他们的员工把时间花在其他事情上，比如回顾、改进流程、尝试其他解决方案等等。这样加班加点的工作方式会不时的受到经理有意无意的鼓励，结果不久之后团队的工作效率就会因为士气低落和身心疲惫而停滞甚至降低。

作为软件开发这样的知识型工作，总是有几乎无限种新东西可以学习，相应的也就有无限种可能的方式来提高效率，而只采用其中的某几种就可以帮你做得更好了。一个团队每隔一两周找个安静的地方讨论一下某种方案是否可行，这样就可以找出大家效率最高的协作方式了。用这种探索不同解决方案的方式开发出来的产品，极有可能比你最初预想的更好。

首先可以做的事情是保证开发的过程中有一些“空档”。空档的意思是有一些没有分配具体工作任务的时间，并且当出现空档时可以由团队或个人来决定这段时间如何使用。有很多办法可以留出空档，比如制定迭代计划时不要按照团队的能力安排 100% 的工作量，或者当同时进行的工作数量达到上限时就不要再启动新的工作了，等等。这样留出的时间非常适合于学习和做尝试。

当有空档时，团队可以选择一些不同的东西去学习和改进。做回顾通常都可以帮你获得一个很棒的开端，因为好的回顾可以帮助团队建立信任，找到更好的合作方法。回顾的另一个好结果是发现新点子，可以尝试改进团队的工作流程和产品。所以当你留出了空档之后，你一定要保证有些团队成员知道如何做好回顾。

还有一种要鼓励团队去做的好行为是让几个团队成员同时分别去设计一下架构或者用户接口等。这样团队就可以比较他们的设计成果并选出其中最好的一个付诸实施，甚至可以将它们整合起来形成一个改进版。通过这种方式你就启发了所有的队员去思考和交流，有可能会获得更好的设计，而做过设计的个人也会得到对他们的设计非常有价值的反馈。相对于获得的学习效果来说，这种作法又安全又不需要什么成本，因为你只不过是让几个队员同时去做了一下设计而已。

另外一种非常重要但常被忽略的反馈方式是，如果一个团队可以与他们的经理沟通把某些问题提高到合适的层面上去，那问题常常可以得到简单而有效的解决。在传统的组织中，往往问题上报给管理层之后就呆在那里没人处理了，这种情况很常见。

可以通过开辟正式和非正式的渠道来让员工和经理沟通问题，这种反馈方式也要大力加强。如果团队借助于经理的一点帮助就可以轻松解决掉某些问题，那团队和经理就都会体会到沟通的益处。如果有些问题经理也没法帮忙解决，那么经理可以把问题再向上级反映，或者动用其他可以动用的资源。

有些公司甚至会有这样的机制，即如果一个经理或者一个团队在一定的时间内无法自己解决某些问题，那么问题就会自动上报到公司架构的上一层。这并不是为了惩罚那些解决不了问题的人，而是一种让上级管理层知道问题的方式，即公司里现在有什么样的问题是没法解决并需要帮助的。不管问题是不是自动上报的，向上级报告问题都是要鼓励的，因为只有大家意识到的问题才有可能被解决掉。

做这些事都需要花时间和精力，但如果你用正确的方式做了，你也会获得指数级的回报。获得反馈和做改进都是敏捷流程的非常重要的部分，你要保证你没有把它们废弃掉。如果你发现团队不做回顾、不尝试新方案或者不和你沟通他们的问题，那么就是时候限制一下他们的“实际工作量”了。

保护和支持“共享目标，共担责任”

敏捷要依靠团队协作。单个人可以用一种敏捷的方式去工作，但只有当敏捷的方式应用于团队工作时，才会显示出杠杆作用。

传统的管理方法关注的是个体角色的清晰设定、针对彼此的个人评定、围绕个人职责与个人义务的组织安排。当采用了敏捷的方式之后管理方法恰恰与此相反。在此引入了团队实践，但每个人的责任仍然和以前一样。

如果给了某些人不必遵守大家的共识的特殊待遇，就会毁掉整个团队。这就等于是告诉这些人，他们不必参加计划会议或回顾会议，他们不必分担大家的工作，也不必承担团队决定的分给他们的个人任务。

当发现团队中有些人的工作方式与大家的共识不同时，你做为经理就要注意千万不要给这些人上文提到的那些特殊待遇。这并不是说你走过去和团队或个人打个招呼说让他们自己解决问题就完事了。你要帮助这样的个人更好的融入团队，或者要求团队负责人和整个团队一起找出办法来解决。有时候你甚至要给这样的人一点压力，让他知道如果大家达成了共识，他就得改变他的工作方式去遵守。

如果你发现你的团队在试图共同解决这个问题，就可以退到一旁了。但只要团队或个人还没有都完全适应共同工作，你就要不断的提醒他们问题还没有解决，他们还要一起继续努力。

有的团队会承担多重责任，因而有多个需求列表，结果反而无法达成团队的一致目标。有的需求就被忽略了，公司的优先级和工作任务之间的联系也越来越难以跟进。有些事情本来希望他们能解决的，却偏偏没有得到解决。“共担责任就是没有责任”这是常常挂在直线经理或项目经理嘴边的一句歪理。如果你那么做，你就再也不会相信一个团队会一起承担责任，然后你就真的会看见大家都不承担责任了。

要对团队有一个清晰的目标和期望，就必须要让每个成员都忘掉他们本来的职务而全心全意的投入到团队工作中去。而且你也不能把团队的这个成员和那个成员做比较。要期望团队能自己决定他们的工作方式，鼓励团队成员遵守他们达成的共识。

让团队成员自己管理自己，你就是在帮助他们创建一个拥有自主权和遵守承诺的工作环境。与当初你说一件事他们就做一件事时相比，他们会更加主动的去解决问题和按时提交工作成果。这种自主管理也会带来其他的好处，比如在团队里会有更多的相互学习和信息分享。团队成员一起更可能会有正确的信息来做出正确的决定，这比经理或团队负责人单独拍板强。

没有相同的团队

不同的团队会有不同的个性、技能和技巧，他们要与不同的客户打交道，做不同的解决方案。他们都是有过不同的经历而演进成现在的状态的，所以每个团队自己喜欢使用的工具和流程也常常不同。而团队经理们常常采用的方式却是就假定所有的团队都有相同的工作条件，期望他们会在相同的阶段有相同的产出，并且要使用相同的工具、技术和流程。这是一个特殊而又常常发生的阻碍敏捷流程的反馈周期的例子。如上文所说，没有了反馈，很多敏捷的好处也就没有了。

为了全面提高生产率你可以希望所有的团队都遵守相同的原则，提供标准化的工具让团队去自行选择，也可以衡量整个部门或公司的生产率。但通常你最好不要试图强迫团队去使用某个具体流程，或强迫团队使用并非自己所选的工具，或比较不同团队的内部指标。

有很多的行为是比团队选择的工具或方法更重要的。当你让他们在某些事情上做出决定的时候，你应该对你的团队有如下预期：

• 与合作方和客户紧密合作。 要清楚的了解产品的愿景和客户对质量的期望只能通过直接而反复的沟通。转述总是一种浪费，透明有助于创造信任。没有任何理由来让你的团队和合作方保持距离。
• 保留并展现他们自己的指标 团队可以通过跟进指标来更好的理解怎样有效怎样无效。如果指标由团队自己管控，而不是由经理来管控，这样的指标就会更加有效，所以放手让他们去决定衡量什么和如何衡量吧。而且让指标透明有助于合作，可以在团队和合作方之间增进信任。
• 练习持续改进 当团队可以通过他们自己的指标了解自己的工作表现时，他们持续改进工作流程的步骤就简捷了。一点一点的实验，一点一点的改进，成果就会累积起来。当他们的工作表现得到改进之后，士气也会得到振奋，他们看到是他们自己的努力促成了有益的改变时，会觉得既有趣又有成就感。

除此之外，你就要认真倾听你的团队对你述说了。如果你问得恰当，他们就可以解释清楚他们碰到的障碍是什么。帮助他们解决掉他们自己解决不了的问题，这通常是你该做的有助于提高产出的正确的事。

结论

希望你花了这么多时间读到这里之后，你已经对接下来要去尝试些什么有了一些想法。问题不会一下子都解决掉，但如果你不断尝试，我保证你会慢慢的看到非常好的结果。

对于那些总是忙得团团转的经理来说，我帮你把文章内容总结成下面的列表，你可以打印出来，每天提醒自己一下，直到你已经把它们坚持做下去了：

• 控制在制品数量，这样可以比对任何需求都说行的方式取得更多的成绩
• 长期来看，尊重队员的反馈需求要比做实际工作更重要
• 团队要获得支持才能达到“共享目标，共担责任”的状态，千万别因为直接进行个人管理而破坏了这一点
• 团队不同，环境不同，要允许各种不同的工作方式和产出

你尝试做过什么来帮助你的团队创造更多价值？

欢迎在 Twitter（@dahlbj）上与我联系，也可以直接在原贴下面留言评论。

关于作者

Johan Dahlbäck是一位对高效开发软件有着极高热情的工程师。他有丰富的团队领导和项目开发经验，并且多次作为敏捷教练指导团队采用敏捷的开发方式。他对数据库和网页开发有着丰富的经验，对软件开发和运维中的变数也有着深刻理解。通过与不同的团队和公司合作，他获得了大量关于改进团队合作和软件交付的实战经验。Johan 从 2009 年开始成为了使用敏捷开发方法的狂热分子，也帮助各种规模大小不同的公司成功地完成了敏捷转型。

参考英文原文： A Letter to the Manager: Release the Power of Your Agile Teams

感谢夏雪对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。