本栏目为 EXIN Agile Club 的子栏目。栏目目的是翻译 Mike Cohn 的高质量博客，让大师的智慧可以影响更多的人。翻译已经得到 Mike Cohn 的授权。

00-前言

不确定性无处不在。在写这篇文章的同时，我在等待一个已经迟到快一个小时的水管修理工。他还来吗？什么时候来？天气app告诉我今天应该很晴朗，但是我感觉似乎马上就要下雨了。

今天早些时候，我要求研发人员做一些功能变更。我大致知道我想要什么，但是我并不清楚所有的细节。我的不明确给他们的工作引入了不确定性。

我们的周围充满了这么多的不确定性，我们应该见怪不怪。你可能会认为，使用Scrum方法的敏捷团队会对此习以为常，然而事实并非如此。

比如，我就并非对不确定性习以为常。按理来说，水管工什么时候出现真的无关紧要。因为距离我要去做某件事情之前还很多时间，他的到达时间应该不会对我产生困扰。但这事儿的确对我造成了困扰。

01-团敏捷团队需要与不确定性共舞

学会与不确定性共舞，这对Scrum团队至关重要。在敏捷项目或任何使用敏捷的项目中，并非所有内容都可以预先知晓。随着时间的推移，产品的细节才会逐渐浮出。

这意味着团队及产品干系人都不能预先知晓所有需求——因为那根本是 Mission Impossible。有些需求甚至在整个开发过程中都没有被识别，直到用户看到产品的最初版本时才被提出来。同样，用户界面的细节更加不能被预先定义，数据库也同样不能预先被完美设计。

无论用户故事有多详细，无论Scrum团队成员与产品经理及干系人进行了多少次沟通，一些细节只有在迭代进行时才会出现。

02-当我们试图消除不确定性时会发生什么

当团队成员抵触不确定性时，他们会表现出某些明显的迹象。

首先，团队成员经常在用户故事需求会，细化（refinement）或迭代计划会议中花费大量精力，试图在开始工作之前捕获所有细节。在某些时候，随着不确定性的降低，工作价值也会迅速下降。在这种情况下，即使仍然存在悬而未决的问题，团队成员也应该直接开始工作。立即开始工作是消除剩余不确定性的最好方法。

此外，想要消除不确定性的团队往往会变得非常抗拒变更。团队成员希望锁定需求，而不是接受因为向用户展示产品而导致的不可避免的变更。

最后，当一个团队抵触不确定性时，它的冲刺计划和产品列表细化会（product backlog refinement meetings）通常会花费过长的时间。这些敏捷规划会议应该被用来确认接下来要处理的内容，而不是确定所有细节内容。害怕不确定性的团队将试图在这些会议期间排除所有不确定性。

03-Scrum Master 的三种武器

幸运的是，Scrum Masters可以做一些事情来帮助团队在适应不确定性。

1-承诺并非估算

Scrum Masters可以从确保在组织范围内达成一个共识，即“估算就是估算，而不是承诺”。

每个未经明确细节的可能都会影响估算的准确性。

如果一个团队说他们可以在一周内写出一个媲美Microsoft Word的竞品，那么他们达到这个估算的可能性大约为0%。相反，如果他们估计可以100人一年内做到这一点，那么这个估算的可能性要高很多。

干系人、项目经理和团队估算的其他人必须接纳估算不等于承诺，这点非常重要。团队可以使用估算作为承诺的基础（在合理范围内可用作承诺），而承诺意味着实现的可能性要高得多。为此，团队的估算结果会需要更长的时间。例如，一个团队估算，完成某件事最有可能需要的时间是两个月。但是，如果被要求承诺，他们会说三个月（为了确保能兑现承诺）。

一旦团队的干系人普遍理解了这一点，团队成员就可以放弃在项目开始前回答所有未决问题的想法。但是，如果团队成员担心他们会因事情花费的时间比预期的要长得多时而备受指责时，他们还是会尽可能提前去了解更多情况。

2-移缓就急

第二种帮助方法是，指出团队对非必要信息的过度关注。我最喜欢的方式是告诉团队，“我知道你需要那个问题的答案。但是，你是在开始处理这个事项前就需要获得答案，还是在即将完成前获得答案即可？”

这种回应认可了团队成员对更多信息的诉求的合理性，同时也有助于让其知晓有些工作可以在没有答案的情况下开始。

举个例子，一个为新系统构建登录功能的团队，可以在不了解诸如以下事情的情况下开始工作：

账号在被锁定前做了多少次失败尝试

强密码的具体构成标准是什么

使用什么机制来重置忘记的密码

在将登录功能完成之前，此类问题都需要被回答。但一个理性的团队成员会意识到，工作可以在得到这些答案之前就开始。

3-重申会议目的

Scrum Masters可以提供帮助的第三种方式是强调每场Scrum会议的目的。在这些会议中，你可能会看到团队成员过度地推动消除不确定性。例如，迭代计划会的目标是为当前迭代排进适量的工作，而这并不需要解答每个未决问题。

不确定性可能会让人感到不舒服。许多人不太可能完全适应它。但是，让团队接受不确定性而非试图消除不确定性，这是敏捷成功的关键。

你的想法

您的团队成员是是否能拥抱不确定性？您做了哪些工作来让他们克服对不确定性的不适？欢迎留下您的想法。

译者信息

梁瑞香

本文译者

大型国有银行敏捷教练

DevOps 的追随者

带着辩证思维一直在路上

崔宏宇（崔小）

本文审校

敏捷从业者

自称“To B 产品道