作者：Mike Cohn
译者：李洁（Jerry Li）
原始链接：https://www.mountaingoatsoftware.com/blog/should-a-team-assign-work-during-sprint-planning
小时候，妈妈教我系鞋带。我已经记不清具体每个步骤了，但应该是采用了兔耳朵系鞋带法。
那以后，我了解到有很多种不同的鞋带系法，其中多数方法都更好用。大多数方法会更适用于某些特定环境:宽脚、窄脚、高足弓等等。
从首次系鞋带至今，我已学到了很多。同样，从在首个敏捷团队工作至今，我也已学到了很多。
早期团队如何开Sprint计划会议
在我早期的敏捷项目中，团队成员会在Sprint计划会议上分配任务。我们会在计划会议上对每项任务分配人员。我们的Sprint backlog，当时我们称其为Sprint计划，是如下图这样的。
这样做，明显能带来以下这些好处：
- 每个任务由谁负责是非常清晰的。
- 团队成员对他们的任务更有责任感。
- 它能帮助团队确认是否有人在Sprint中过度承诺。
这种方法最大的缺点是，团队成员得在对工作了解最少的情况下，决定由谁来承接工作。我早期的许多团队都进行为期四周的Sprint。这就意味着他们正在决定由谁来承接可能在未来20天内开始的任务。很明显，在这20天里可能会发生大量变化。
不要在Sprint计划中分配任务
这种方法，我坚持使用了相当长的一段时间。甚至在2004年出版的《用户故事与敏捷方法》一书中，我还倡导使用它。
但是，如同系鞋带一样，我发现还有更好的办法。与其让团队成员在Sprint计划期间就认领每个任务，还不如让团队成员在Sprint中选择他们接下来的任务。
这通常发生在每日站会上。在团队成员声称已经完成了某个任务时，他们选择下一个任务。
这种做法的效果真得很好。在决定接下来的工作时，会从整个迭代角度来考虑。例如，会考虑以下这些问题:
- 团队是否考虑了某个产品待办项?
- Sprint目标能顺利达成吗?
- 是否有哪种工作(例如，测试)滞后了?
存在的问题
这种实时的工作分配方式确实很有帮助。团队使用这种方法，能够更好地在迭代过程中进行调整。
只是存在一个问题:在Sprint计划上，团队该如何知道是否有人承担了过多的工作呢?
当所有任务都在Sprint计划中得到了分配时，这很容易评估。每位团队成员都能看到他们所承担的任务集，并确保不多不少刚刚好。
但是，当在Sprint计划上不分配任务时，就无法进行这种评估了。
找出工作路径
如果每项识别的任务旁都没有名字，团队就很难确定他们是否在Sprint中引入了合适的工作量。
为了更好地评估被纳入Sprint的工作量，我开始要求团队“找出工作路径”——可以把它看作是团队成员各自指向他们认为在Sprint中会完成的一组任务。例如，你指出四项预期要开展的任务，而我则指向另外四项，剩下的团队成员则指向了剩下三项。
如果每项任务都有人说“我来做”，并且没有团队成员感到工作负担过重，那么所选择的工作最有可能实现。
当团队成员“找到一条工作路径”时，它只是众多可能的路径之一。团队成员不被期望就一定会承担他们指向的任务。更确切地说，至少需要有一条可能的工作路径，才能让每个人都觉得Sprint规划得很好。
为了强化这种临时工作分配的短暂性，一些团队将其称为“用铅笔签名”。当团队成员指向一组任务说:“我要做这些”时，他们就签名了。但在会议结束时，铅笔签名就会被擦掉，使每项任务都未被正式分配给任何人。
在不知道谁将承担每项任务的情况下进行估算
这些团队面临的另一个问题是，在没有指定任务分配人员的情况下，如何估算一个任务需要多长时间。对于一个任务，需要5个小时还是10个小时，应该估算成多少，这取决于由哪个团队成员来完成?
在这里，用铅笔签名的想法也有帮助。对任务的估算，可能会是说自己想承担这个任务的人所估算的工作所需时间。
因此，你的估算是基于你认为自己会承担任务的情况，而我的估算则是基于我认为自己要承担任务的情况。
然后，在迭代过程中，当某人开始一个任务时，他们会在把该任务领作自己下一个任务的瞬间，就改变估算时间。这种方式下，如果工作速度比最初计划承担工作的人慢，我可能会在获取一个任务时，立即将其估算从5个小时更改为8个小时。
这种寻找工作路径的方式之所以有效，是因为它通常代表团队成员之间只是进行了一次时间交换。你拿走了一个我想要完成的任务，然后改变了我的估算时间。然后我拿走一个你计划好的任务，改变你的估算时间。
而且，即使新的估算数据更大，一般也可以认为，当前的工作分配方式是当前已知的最佳工作路径。换句话说，在迭代中，团队成员在不断寻找到最优的工作路径。
我现在的建议
我非常偏爱在临近工作开始时才决定谁来承担某项工作。因此，我不喜欢在Sprint计划中分配所有任务。我指导的团队成员通常会在Sprint计划结束时认领他们的第一个任务。这让每个人在离开Sprint计划会议时，都能清楚地知道接下来要做什么。
虽然不喜欢在Sprint计划中分配所有的任务，但我认为在两种情况下，团队能从在Sprint计划上分配每项任务中受益:
- 刚接触敏捷的团队
- 仍在打造个人责任感的团队
个人责任感与团队责任感
正如前面提到的那样，当团队成员认领任务时，他们会对自己名下的任务有更强的个人责任感。在具体某项任务旁边看到我的名字，会让我更有可能完成那项任务。
但这是以牺牲团队责任感为代价的。对有我名字的任务，我会更有责任感；但有你名字的任务，我恐怕就没那么有责任感了。
一个拥有强烈团队责任感(每个人都对所有的工作负责)的团队，才能达到最佳状态。但是，如果不首先建立个人责任感，就很难建立起团队责任感。
因此，如果当前团队的个人责任感较低，您可能需要在一段时间内在Sprint计划中分配所有任务。而一旦个人责任感加强了，再考虑不要在Sprint计划中分配每项任务，以转向加强团队责任感。
刚接触敏捷的团队
在Sprint计划上分配所有任务，也可能会使刚接触敏捷的团队受益。当敏捷的紧密协作对一个团队来说仍然是新鲜事物时，很难想象在不首先将所有工作都分配给团队成员的情况下，一个团队如何承诺完成一组工作。
从一个简单的混合方式开始
幸运的是，对于任何希望放弃在Sprint计划上分配所有任务的团队来说，有一种简单的方法可以实现这种转变——通过在计划会议上逐步减少分配给具体人员的任务数量来做到这一点。
如果您的团队今天分配了所有的工作，那么下次可以试着只分配50%的任务。然后，团队成员在下一次计划会议结束时，会临走5个任务，而不是10个。剩下的任务——大约是Sprint工作的一半——还没有分配给团队成员。这些任务将随着Sprint的进展而分配。
我确信，这对团队来说不会有什么好处或坏处。但，这是向最少分配方向迈出的很好的一步。因此，可以在接下来的几次Sprint中让团队继续只分配一半的工作。
一直这样做，直到整个团队都能适应这种方式为止。然后，再进行调整。将在计划会议中分配50%的任务，改为只分配25%。再这样做几次，直到每个人都再次适应这种方法为止。
接下来,可以更进一步。在计划会议上，只分配大约10%的任务。并且，最终考虑不分配任何工作任务。即使这样，大多数团队都会让每个团队成员在计划会议后立即认领完成一两个任务。
您采用什么方式？
随着经验的积累，我们能找到新的、更好的工作方式。就像我不再通过想着兔耳朵来系鞋带一样，我所指导的团队在Sprint计划期间也已不再分配任务，因为这些团队已经有经验了。
您的团队采用什么方式?你们会在何时决定由谁来完成Sprint backlog中的任务?请在下面的评论中分享您的观点。
