Scrum团队为什么由指派任务变成领任务

敏捷开发团队（Scrum团队）在每天开每日站会的时候会领取当天的任务，这个实践在敏捷开发中叫做sign-up-for-tasks即领任务。这个实践源自极限编程，在1998年，极限编程最早期的介绍中提到了，“指派任务”和“领任务”是传统方式和极限方式的一个显著区别。

领任务是指，团队成员在任务卡上写上自己的名字，或者贴上自己的照片，表明这个任务，由这个成员来负责。 领任务的活动通常在开展每日站会的时候进行。领任务的方式体现了团队自组织的工作方式，传统模式下的经理指派任务是命令和控制的工作方式。

                                                                                                                    --《Scrum中文网》

为什么要领任务呢？

熟悉传统开发的同学应该知道，团队成员每天会收到你的组长或者经理的邮件。邮件内容大致：请某某某完成某某某功能。情况好的时候，可能还会加一个完成时间点。传统方式是任务的指派，由团队成员处理并提交到测试。但是转型敏捷之后，为什么会要求有“指派任务”变成“领任务”呢？

解答这个疑问，需要了解两个概念：推和拉。

传统模式下的经理指派任务的方式，是我让你干什么，你就要干什么。这里潜意识下包含的信息为：我不关心你的能力是否可以应付这个难题，不过我觉得你可以处理，你就可以处理。套用现在比较时髦的话“我不要你觉得，我要我觉得”。这种集体意识下，往往也不容许团队成员反驳，而且你会被集体心流干扰，时候你也不清楚当时为什么答应经理接下了这么高难度的任务。

这是“推”。

一辆火车如果要跑的快，跑的稳，发起动力的车厢不会放在车尾（因为放在尾部才需要推）。老话讲，火车跑的快，全靠车头带。由推转变成“拉”的状态，首先这是理念上的改变。

领任务就是拉的状态。由团队成员在已经评估好的任务中，挑选当下适合自己并且满足整体开发需要的任务。（这里评估好的任务是开发团队共同给出的评估）。

动作由“推”转到“拉”的另一个优势是，可以极大的减少日常工作的阻塞。试想在一个生产车间中，一条生产线由5个关键事件组成。理想的情况下，这5个事件顺畅的运转。突然，第3个事件由于故障停止运转，导致产品始终到不了4和5事件，而事件1和2又在不断的生产。最终造成了阻塞，产品的浪费。有没有让你回想起，手里的工作还没有完成，但是又收到经理分配的任务的情景？

推和拉的概念清楚之后，提倡领任务还有一个更深层次的原因。

责任分散（Diffusion of Responsibility）

心理学上，有这样一个定义：在一个群体中，阻止作恶的责任是由所有人分担的。每一个个体的责任感会因此减弱甚至消失。群体越大，责任越分散。

这里分享一个真实的案例：

1964年3月13日夜3时20分，一位叫基蒂·珍诺维丝的年轻女性在工作结束后回到她位于纽约皇后区的家。在她家的门口，一名男子正拿着匕首等着她。

在随后的一个小时里，这名男子连刺了珍诺维丝76刀。而在这一个小时里，珍诺维丝不停地绝望喊叫：“杀人啦！救命啊！”直到她死去。

让人震惊的是，在随后的调查中发现，至少有38名周围的居民在自家窗口目睹了这起行凶，可是竟然没有一个人前往救援，也没有一个人打电话报警。

为什么会出现这种情况？记者对这38名旁观者进行了采访，他们无一例外地说，他们“觉得”其他人肯定已经给警察打电话了，警察已经在来的路上了。

在这个凶杀案里，旁观者并非冷酷无情或者道德沦丧。对于每一个旁观者个体来说，由于他们是一个群体中的一员，阻止犯罪的责任感就会减弱甚至消失。

帮助求救者的责任是由大家来分担的，所以每个个体分担的责任就很少。这种集体冷漠的现象，心理学称之为责任分散。可以想象，群体越大，责任就越分散。

                                                                                                《得到-刘嘉·心理学基础30讲》

类比软件开发过程，为什么项目工期总是延后，为什么工作总是不能在预估的时间内完成。责任感分散应该是其中原因之一。指派任务，只会让程序猿过多的关注于当前的任务里，而缺少了全局的视野。团队越大，现象就越明显。反正人这么多，麻烦棘手的工作总会有人处理。没有人对项目负责，都只对自己工作多少、难易程度负责。最后搞得大家都很累，结果也不会很好，只能通过996的办法解决。只有让更多的人一起参与，才能减弱集体冷漠对于团队工作的影响。

领任务绝对不是你投机取巧占了先机，而是在团队内部充分理解需求后，共同遵守的团队规则。在领取任务时，并不是每个人随意将小卡片移动到自己的名字下面（获取任务的方式），而是团队内每个开发人员充分沟通之后，决定处理某一特性下的子任务。因为用户故事在被拆分成多个任务后，每一个任务只对所属的用户故事负责。如果团队内随意、无沟通的情况下，自由领取，本身对于整体进度无益。

不过，领导者往往比较排斥自有领取任务，是因为这样缺少了监控的机制。“我手底下的人偷懒怎么办？每个人都领简单的任务，那难处理的交给谁？”这样的疑问，相信是大多数管理者都会想到的。

这时候领导者往往要思考的应该是，为什们你手下的人会偷懒？如果是指派性的任务分配方式，就不会偷懒了吗？如果这次迭代的周期内，故事拆分的粒度不一致，那下一次是不是建议团队在拆分用户故事的时候，做到粒度大小一致。找到事物的本质，而不是一味的“守旧”，才是解决问题的办法。

那么领导者对于团队管理的思考，就要从下面两点出发：

目标共同化

向你的团队成员清楚的传达团队目标是非常重要的仪式。很多领导者从来不予团队交代目标，认为只要团队成员完成自己的任务即可，这是完全错误的。目标是个人努力的方向，没有的方向，每天也只剩下机械性的重复劳动，那团队就是一盘散沙。另外目标要符合每个人处于自身发展或者长期利益考虑。如果将目标定的太高，脱离了实际，往往也是空谈。

充分的尊重

互相尊重的环境，每个人都愿意自动沟通，表达自己的看法，发挥具体的智慧。一个开放的团队，承认并允许犯错。人人在这样的环境下工作，自组织的团队一定是最好的团队。