Scrum 在敏捷开发中是非常有意思的一种模型，虽然在国内被采纳的公司比较少。 我买过超过 3 本 Scrum 图书，不过它们并没有把 Scrum 背后的人性密码讲出来。

如果对 Scrum 感兴趣的朋友，推荐阅读官网这个材料：

https://www.scrum.org/resources/what-scrum-module

比较简明的说明了作为 agile framework 它的一些工作方式和流程。

但是关键的内容隐含在 Scrum 这个词的起源中，Scrum 的英文含义是争球。我在学习 Scrum 时，讲师提到一个要点：工作任务不能由 TL 分配，而是让团队成员自己领取

为什么呢？ TL 分配工作任务不更加便捷和符合逻辑吗？培训的讲师没有说明，只讨论了这是 Scrum 框架中倡导的。

直到我作为 TL 时，惯性的让团队成员领取任务而不是分配任务，这种机制可以工作。但是我尝试自己分配任务时，发现一个问题，分配任务这件事情并不容易。

软件工程并不像建筑一样，每项工作可以被清晰的定义。也就是说，软件开发工作很多时候并不像工程，更像写作。修建一座房子，砌筑一面墙所用的工作量是很容易计算的，然而编写软件往往会出现各种各样的差异，有可能捡到便宜、也有可能遇到麻烦。

在很多时候 TL 并不能完全清晰的掌控每项任务的细节，不能很好的分配任务，以及设置时间节点。

通过考察人性我们会发现，在长期工作中，我们不得不顺应人性制定规则。即使短期内，可以克服人性的弱点，长期来看，人性的效应会慢慢被放大。

任何团队和工作，人们都希望拿到手中的任务工作量、难度和估算匹配，如果能估算的人天能充沛一点更好，这样就能“摸鱼”了。

通过自己领取任务，人们会倾向于先领取简、估算充足的任务，完成手上的工作后，赶紧领取下一项估算充足的任务，这样一个迭代完成后，完成的工作量会更多。

虽然很多时候有运气的成分，但是我们通过完成的工作量作为考核的维度之一，依然是可靠的。

争球让工作量估算变得更容易，也消除了因为工作量估算不准确带来的团队矛盾。