大规模敏捷已经开始，再不成为这样的管理者就晚了 ｜ 极客时间

写在前面

你好，我是宋宁，现在在 IBM 做敏捷教练和咨询顾问。今天想和您聊聊“如何用敏捷开发打造一支无往不胜的团队？”

从一线工程师到管理者，从项目经理、Scrum Master，到现在的敏捷教练、咨询师，我经历过研发管理从无序状态到瀑布模式、敏捷模式，对各个管理模式的优劣深有体会，也从各个角度体验过敏捷。

有竞争力的开发者是什么样子的？

我最早接触敏捷，是源于一位做开发的朋友。他就属于那种效率极高的，大家一个礼拜的任务他 2-3 天就能做完，代码质量高 bug 少。最主要的是，他除了写代码以外，有足够多的时间研究新技术，指导其他同事，在团队中口碑极好，后来还研究上了管理，听说这家伙后来做了首席架构师，还兼任团队 Leader。

他有个习惯，每次写代码之前都会仔细想一想需求，想好后先写测试用例代码，再动手写代码。一旦写代码就特别快，一气呵成。

那时我偷偷问他，“你写代码之前还要写测试，多麻烦啊，怎么还能写那么快那么好？”他眨巴着眼睛，一脸坏笑：“代码写得快靠得是思考快，而不是敲字敲得快，构思好了再写不就是记录自己想说的话吗？再者，我先写测试后写代码，磨刀不误砍柴功，好多问题在前面都解决了。”

我再看他写的代码，简洁优雅，顿时羡慕得不得了。他告诉我，“这就是测试驱动开发，敏捷的核心技术实践之一。”他改变了我对程序员的认知，也改变了我对这项工作的认知，原来厉害的程序员不只是撸代码啊。

我一直热衷于探索研发管理的效率、效益和精髓。带着疑惑，加之当时公司也确有敏捷方面的需求，我从此开始研究和实践敏捷开发。刚接触的时候我觉得理念很好，但有些理想化，那时我并没有从内心接纳敏捷。

随着过程推进，我逐步感受到了敏捷带来的好处，尤其在团队管理方面，敏捷为我省去了大量的时间。

以下内容出自极客时间《说透敏捷》，👉点击试读

如何打造一支活力与战斗力并存的敏捷团队？

团队是整个敏捷实践活动的根基，只有团队能有条不紊又高效率的执行敏捷实践中的每一项工作，敏捷才能发挥出它最大的效用。如果团队氛围不好、执行力不高，那即便导入了敏捷实践活动，团队也很有可能做不好。

在做试点准备工作时，我们已根据最适合团队交流协作的方式，对团队的组织结构进行了重组，那么重组后的团队就可以成为一支无往不胜的团队了吗？当然不是，你还需要想办法来唤醒、激发团队，让整个团队更有活力和战斗力。

敏捷试点中最重要的一步便是：打造一支活力与战斗力并存、无往不胜的团队。学好了这关键一步，不管你和你的团队采纳的是哪种敏捷实践，你都能在推进时得心应手、运筹帷幄，你的团队管理能力也会因此更上一层楼。

一起制订社会契约

我先来讲一个做法，叫做“社会契约”（Social Contract）。

什么是社会契约？它本指一个社会里的全体成员，为了更好地生活，定义了一些基本准则，大家一起来遵守。用在团队中，指的就是团队里的行为公约，也就是为了让团队中每个成员都能加强协作、发挥价值，一起来约定的一些基本准则。在工作中，如果有任何成员的行为影响了团队协作，其他成员都可以拿出这个契约来约束他，这样就可以“对事儿不对人”，在处理不良行为的时候更有说服力。

落地社会契约的过程，其实就是团队内部相互认可、磨合和协作的过程。那具体怎么来做呢？我认为可以将团队所有成员都聚到一起，大家一起来制定，只有这样，才能够充分征求每一个人的意见，让大家一致认可，并有充分理由一起执行。

首先，给大家分发一些贴纸，并给所有人 5 分钟的静默时间，让每一位团队成员思考这一个问题：你认为加强协作、达成团队目标，需要哪些行为准则？每一个人都要把自己认为重要的准则写在贴纸上，且一张贴纸只写一条准则。

写完之后，每个人把自己手中写好准则的贴纸贴到白板上，然后将白板划分为不同区域，把内容相似的贴纸归在同一个区域。

接着，会议的组织者逐条给大家读贴纸上每个人写的准则，询问大家是否同意，如果有人不同意，就停下来就此讨论一番，如果讨论的结果还是有人不同意，就放弃它；如果大家都同意，就将该准则保留下来。

这样进行一遍，把大家都同意的行为准则留下来，就形成了团队的“社会契约”。

你要注意的是，“社会契约”做完以后要张贴到所有团队成员都可以看到的地方，以便整个团队时时可以看到它，感受它带来的激励和约束。如果把它束之高阁，那就失去了它应有的效用，你的团队的协作也可能因此出现问题，进而导致敏捷推进的失败。

回顾会议，引导团队的自主性

在试点推进前制定“社会契约”，可以让你的团队形成一个约束和激励机制；那么在试点推进过程中，通过开展回顾会议，你的团队会形成一个引导机制，来引导团队的自主性。

在评估诊断阶段的调研访谈中，你已大体了解到团队的痛点，也根据痛点选择了相应的敏捷方法。那问题来了，敏捷方法里既有管理实践又有技术实践，推进顺序是怎样的呢？

一般而言，作为敏捷教练，我们自己会有一个自认为“正确”的推进顺序。但敏捷实践方法是团队来用的，行为和习惯转变也是团队要做的，而且我们也要打造自组织团队，所以相比你自己单纯地做口头宣讲，按自己的想法推进敏捷，引导团队自行选择和决定推进顺序会比较好，这更容易让团队认可和接受。所以重要的不是“你想”而是“团队想”，回顾会议正好可以完美地做到这一点。

怎么开展回顾会议？其实也很简单。

首先，要选一个大家都方便的时间，把会议时间固定下来。前几次的回顾会议可以由敏捷教练来引导，等大家对会议流程都熟悉了，就可以由团队的组长来组织。

会议开始后，先说明会议目的，接着让大家讨论三个条目：

• 团队工作中做得好的地方是什么？

• 做得不好的地方又是什么？

• 除此之外，有没有什么其它疑问？

和制定契约的会议一样，先用五分钟时间让大家静默思考，然后把每一个点子都只写在一张贴纸上。将白板划分不同的区域，把相似内容的贴纸分区域贴到白板上。

接着一一讨论这些问题。做得好的地方我们在接下来的迭代中就可以保持下去，做得不好的地方大家可以一起头脑风暴到底怎么去改善，并做一些行动计划。对于有疑问的地方大家也可以互相提问，有些是敏捷教练需要阐释的，有些则是团队成员需要解释的。

这里你要注意，回顾会议是有时间盒的，一般不会超过 1 个半小时。在前几次回顾会议中，团队会提很多关于敏捷实践的问题，但我们的时间有限，所以如果问题几句话就能解释明白，通常我会当场解释清楚，否则我会安排专门的时间来和团队解释他们的疑惑，而不会把会议拖得过长，占用过多时间。

你可以看到，这个会议其实也有查漏补缺的功能，可以让你察觉团队成员在哪些方面有疑惑，或者哪些敏捷知识储备不足，后面你可以安排其它时间来帮助团队专门补齐。

以我带过的一个手机银行团队为例。在第一次回顾会议时，团队针对做得不好的地方提出“项目透明度差，只了解自己的工作而不了解其他团队成员的工作”，我就这个问题引导团队思考其背后的原因，之后团队一致认为主要原因是“没有地方和机会了解别人的工作”。我就势引导团队说：“大家觉得可以做些什么事情来改善这个问题呢？”最后大家讨论认为，不如约一个时间，每天定时定点地开个短会来共享一下彼此的工作内容和状态，这不就是“站立会议”吗？我们又一起给这件事情定了一个时间段：下个迭代。我领取了这个改进任务，在下一个迭代中为团队导入“站立会议”。

说到这你发现了没有，通过回顾会议来引导团队思考，所有的敏捷改进就不是我作为“敏捷教练”安排给团队来改进的，而是团队自己思考出来的行动。身为敏捷教练，我只需要将专业的敏捷知识和做法示范给团队即可，团队会更愿意践行自己主动思考出来的行动，这样，整个团队的行为和习惯就会转变得非常顺畅。

所以说，只要掌握了正确的方法，敏捷的推进并没有想象中的那么难。每个团队其实都有向好转变的原动力，我们只需要将它激发出来，并且告诉他们正确的行为规范，加以引导就好了。

成绩墙与错题集，记录团队敏捷的成长

有了契约的约束和回顾会议的引导，是不是就意味着在试点过程中，会一直一帆风顺呢？不会，你一定还会遇到些小波澜。因为团队也不会一直都正确地思考，也有犯错的时候，比如：

• 团队为了赶进度，省略了部分测试，匆忙上线；

• 迭代中间有业务人员向某个团队成员提出了新的需求，要求加到迭代中，团队成员不顾自己的研发产能，擅自将该需求加到了迭代中，最后却搞不定等等。

遇到类似这些情况，该怎么办呢？这里我不想教你具体的解决方案，而是想教你如何引导团队解决问题的思维。

如果这个所谓的错误并不会带来毁灭性的灾难，比如导致用户大规模投诉，或给公司带来巨大的经济损失，那么我会选择放手让团队去按自己的想法先做一做，即使碰个壁也未尝不可。事后我们再坐下来认真分析到底怎么做才是对的，引导团队想出新的解决方案。有了这样一个试错的过程，团队通常会将经验教训记得很清楚。

另外，配合着团队敏捷试点，我会让团队通过“成绩墙”和“错题集”在敏捷推进过程中记录自己的心情曲线，记录自己的喜怒哀乐，记录取得的成绩和错误，所以这其实也记录着团队的成长。

团队有任何大大小小的进步和成绩，我都会让团队顺手记录下来，贴在一面小小的“成绩墙”上。同样，我们也将自己遇到的问题和坎坷，以及解决方案也顺手记录下来，贴在另一面小小的墙上，构成一个“错题集”。这样团队成员时不时经过它，都会很生动地想起在我们敏捷实践的过程中都发生过什么。在敏捷试点结束的时候，我们也会把试点总结里成功的经验和失败的教训写到这里。

这样做有很多好处，首先团队会一直感觉到敏捷氛围的存在，有精气神儿；其次，以后有团队请我们去宣讲时，我们很快就能找到素材，也能绘声绘色地传达给大家；再次，团队记录的心情曲线、“成绩墙”和“错题集”，这些都是试点结束后在做总结时，记录团队敏捷成长历程的鲜活的素材，是团队敏捷实践的轨迹。

另外我自己在深入进行敏捷实践的同时，接触了很多国内的研发团队，这些团队的规模不等。他们的共同特点是很努力，但也存在很多问题。比如：

• 初创团队，没有任何成熟的管理实践，想到哪里做到哪里，研发管理相当混乱；

• 有的团队已经经历了前期的混乱，想着要正规一些，就倾全公司之力引入 CMMI，导入瀑布流程，导致整个公司流程过重，交付速度受限制，三个月甚至半年才上一个版本，业务部门相当不满意，项目团队成员也怨声载道；

• 有的团队听说现在流行的方式是敏捷，于是拿书来看，自己琢磨，炮制了一套敏捷流程，结果根本不适合自己团队的业务模式。

作为敏捷咨询师，我给上百家公司做过分享和敏捷教练，目睹了各种各样公司在推进敏捷开发过程的疑难杂症，我一直想把自己的经验总结出来，帮助敏捷团队和个人真正解决实践中的痛点，于是我和极客时间团队决定打磨一个把敏捷讲透的课程。

现在市面上有很多关于敏捷的书，会讲一些基础知识和理论，但是敏捷毕竟有很强的实践性，只了解理论是不够的。以我个人的经历来讲，想要真正理解并接纳敏捷，你需要真实的案例来辅助你对它的理解。

鉴于此，我和极客时间团队一起打磨了你现在看到的《说透敏捷》专栏，我将结合实际案例来揭示这些年来自己对敏捷的研究和实践，手把手帮你定制敏捷实践计划。

👉点击「链接」，立即全方位了解敏捷开发。