《Scrum精髓：敏捷转型指南》—预测和适应

预测和适应

在使用Scrum时，经常需要平衡预测性的事前工作与适应性的适时工作之间的关系。下面五个敏捷原则与这个主题相关。

l  不到最后时刻，不轻易做决定。

l  承认无法一开始就把事情做对。

l  偏好适应性、探索式的方法。

l  用经济合理的方法积极主动接受变化。

l  在预测性的事前工作和适应性的适时工作之间做出平衡。

不到最后时刻，不轻易做决定

对于需求或设计，计划驱动的顺序开发方式要求在当前这个阶段就做出重要的决策并进行审批。而且，在进入下一个阶段之前必须先做出决策，即使这些决策依据的知识有限。

Scrum认为，不该单单因为通用过程要求此时做出决定，我们就得做出不成熟的决定。相反，在使用Scrum时，我们倾向于“不轻易做决定”这个策略。这个原则常称“最后责任时刻”（Last Responsible Moment，LRM）（Poppendieck and Poppendieck，2003），意思是推迟做出承诺，直到最后责任时刻再做出重要的、不可逆转的决定。那么，最后责任时刻是什么时候呢？这个时刻就是不做决定的成本大于做决定的成本时（参见图3.6）。此时，就需要做出决定了。

图3.6  在最后责任时刻做决定

为了领会这个原则，我们考虑下面这种情况。在产品开发工作的第一天，我们对自己的工作内容了解得最少。随后的每一天，我们的了解都能多一点点。既然如此，为什么要在第一天或者很早就做出所有最关键且（也许）不可逆的决定呢？大多数人都倾向于等有更多信息之后再做出更明智的决定。在处理重要的或不可逆的决定时，如果决策太早且有错，就会处于图3.6中决策成本的指数部分。更好理解决策之后，决策成本会下降（因为市场和技术的确定性增加，做出错误决策的可能性降低了）。这说明我们应该在掌握更多信息之后再做决策。

承认无法一开始就把事情做对

计划驱动的过程不仅要求有完整的需求和全面的计划，还想当然地认为事先就能“把事情做对”。但实际情况是我们根本不可能事先就能以正确的方式得到所有需求，也不可能基于这些需求以正确方式得出详尽的计划。更糟糕的是，一旦需求有变，还得根据当时实际情况修改需求和计划基线（详情参见第5章）。

在Scrum中，我们承认自己不可能事先确定所有需求或计划。事实上，我们认为这样做可能很危险，因为可能漏掉重要的知识而产生大量低质量的需求（参见图3.7）。

图3.7  计划驱动的需求获取与产品知识积累

图3.7表明，在使用计划驱动的顺序过程时，在早期产品知识积累有限的时候就产生了大量需求。这样做是有风险的，因为它使我们产生错觉，认为自己已经消除了结果不确定性。一旦了解得更多或事情有变，还可能会造成巨大的浪费（详情参见后文）。

在Scrum中，我们也会预先产生需求和计划，但原则是够用就好，一旦了解更多在建产品的相关知识，我们就会填充需求和计划的细节。毕竟，在开始构建前，即使我们笃定要以什么方式构建哪些特性，但在把早期的增量可交付物放到目标使用环境之后，还是会发现不对劲儿的地方。此时，种种实际情形都会推动我们改变初衷，去做真正适用、适时的东西。

偏好适应性、探索式的方法

使用（或利用）现在已知的东西并对未知的东西进行预测，这是计划驱动的顺序过程关注的重点。Scrum则更倾向于恰当运用探索式方法，在此基础上采用适应性的试错法。

探索指的是通过某些活动来获得知识，例如构建原型、创建概念验证、实施研究或进行试验。换句话说，面对不确定，我们通过探索来获取更多可用信息。

工具和技术对探索成本有很大的影响。在过去，软件产品开发的探索成本很高，因而采用预测性的、尽量一开始时做对的方法是有利的（参见图3.8）。

图3.8  过去的探索成本

举个例子，我在佐治亚理工学院读大一时（上世纪80年代初），我用过几次打孔卡——跟打字机似的，如果出错或需要修改，是很烦人的。必须非常小心地为所有解决方案逐个做打孔卡，然后再排队等待使用大型机，可能得等上24小时才能验证解决方案是否正确，在这样的背景下，“快点试一试，看情况”这个理念是让人很难接受的。即使微不足道的排版错误，也至少得耽误一天。瀑布过程在面对不确定性时可以仔细考虑当前知识并做出预测，以求找到优化的解决方案，这种做法是经济合理的。

幸运的是，现在的工具和技术越来越好，探索成本也随之下降。从经济层面上不再是探索的阻碍。事实上，到如今，快速构建少量内容并根据用户反馈进行调整，其成本往往低于事先投入精力试图一次性做对所有事情。解决方案的目标使用环境（技术）如今已变得更加复杂，所以能够采取这种做法也是很值得庆幸的。

在Scrum中，只要具备足够的知识，就可以得出明智、合理的最终解决方案。然而，在面对不确定性时，不要一厢情愿地预测，要用低成本的探索方式来换取相关信息，并综合利用这些信息得出明智、合理的最终解决方案。通过行动获得的反馈可以帮助我们确定是否还需要进一步探索以及何时进行。

用经济合理的方法接受变化

我们都知道，使用顺序开发方式时，后期变更成本比早期变更成本高很多（参见图3.9，基于Boehm 1981）。

图3.9  顺序开发方式的变更成本曲线图

举个例子，分析阶段的变更可能只花1美元，但在后期测试阶段，同样的变更却可能花1000美元。为什么会这样呢？如果分析阶段出现的错误能在现阶段被发现，那么修正成本肯定不高。但如果直到设计阶段才发现这个错误，则不仅需要修正错误需求，可能还要修复基于这个错误需求所做的设计。每往后延一个阶段，错误的影响也越大，甚至演变为这种情况：分析阶段的小错误到测试或运行阶段演变成大错误。

为避免后期变更，顺序开发过程的做法是设法提高预测的准确度，澄清系统需求及其实现过程，再加以严格控制，力求最小化需求和设计变更。

不幸的是，早期活动阶段的过度预测往往适得其反。不仅无法消除变更，反而成为交付延期和预算超支的原因之一。为什么会出现这种有悖常理的事实呢？首先，为了消除昂贵的变更，我们被迫在每个阶段进行过度投资，即做一些不必要、不切实际的工作。其次，在尚未得到干系人对工作产品的反馈来验证假设之前，我们被迫在过程早期做出重要的假设。结果，根据这些假设而产生大量工作产品库存（WIP）。后来，在这些假设被证实（或被推翻）或发生变更的时候（例如，需求的出现或演变），很可能得修改或放弃原有的工作成果，这样的情况时有发生。自我实现的预言，其经典模式莫过于此（参见图3.10）。

在Scrum中，我们认为变更是很正常的。我们相信，产品开发所固有的不确定性无法事先通过加班加点来预测。因此，必须准备好主动迎接变更。不过，在出现变更时，我们希望能比传统开发更经济的方式来处理，即使变更发生在产品开发工作后期。

因此，我们的目标是要让变更成本曲线尽可能长期保持平稳——即使在后期接受变更，开销也是经济合理的。图3.11说明了这个观点。

我们可以通过对WIP数量和工作流进行管理来实现这个目标，因此，与顺序开发相比，在使用Scrum时，变更成本受时间的影响更小。

不管使用哪种方式来进行产品开发，我们都希望有这样的关系：小的需求变更所造成的实现方式变更也相应较小，因而成本变更也小（不难想象，大型变更带来的成本显然更高）。我们从这种关系中希望得到的另外一个特征：不管变更请求何时出现，都要保持这种关系。

图3.10  自我实现的预言

图3.11  让变更成本曲线趋于平稳

在使用Scrum时，很多工作产品（例如详细需求、设计和测试用例）都是以刚好及时的方式产生的，以免创建非必需的工件。这样，在发生变更时，不必丢弃或重新修改的、基于假设而产生的工作或被迫做出的决定要少得多，因此可以让成本和变更请求的大小更加成比例。

使用顺序开发方式时，库存会随着时间的推移而增加，这意味着早期所做的工件和被迫做出的轻率决定最终造成变更成本快速上升。这导致图3.11中传统开发方式的曲线在早期就出现拐点（曲线突然上升的那个点）。在使用Scrum开发时，到达某个时间点之后，变更成本和变更请求的比例也会变得很离谱，但这个时间点会出现得更晚一些（如图3.11中的Scrum曲线拐点所示）。

平衡预测性的事前工作和适应性的刚好及时工作之间的关系

计划驱动开发有一个基本的理念：事先得到详细需求和计划是至关重要的，并且做事情要有先后。在Scrum中，我们相信前期工作有帮助，但不宜过度。

在Scrum中，我们承认不可能事先精确获得所有需求和计划。这是否意味着不应该事先做需求和计划呢？当然不是！Scrum的要义是找到平衡点，即取得平衡预测性的前期工作和适应性的刚好及时工作的平衡（参见图3.12，改编自Cohn 2009中的图）。

在开发产品时，应该从经济合理的角度来设置平衡点，满足法规、监管和∕或公司的目标的前提下，尽量根据快速反馈持续进行调整，少做事先预测。

究竟怎样才算平衡？这在一定程度上由这几个因素推动：所建产品的类型、待建产品（结果不确定性）和产品构建方式（方法不确定性）的不确定程度以及开发中的限制。过度预测要求我们在普遍存在不确定性的情况下做出假设。过度调整可能会让我们处于动荡中，让人觉得工作效率低下、混乱。为了能够快速开发创新产品，在我们的工作环境中，一方面要调整，一方面也要通过刚好够的预测来取得平衡，以免陷入混乱。Scrum框架在秩序与混乱之间取得了很好的平衡。

图3.12  平衡预测性的工作和适应性的工作之间的关系