定制你自己的敏捷：良好的预估如何练成？-InfoQ

本文要点

速度（velocity）不是加速度，它是对能力的度量

避免基于任务的预估

通过探针（spike）的方式明确工作量

计算故事（story）的数量代替预估的方式

采用周期时间来优化你的预估

很多敏捷理论都假设团队会通过故事点（story point）来预估时间，这也是一种主流的预估方式。但我们通常所说的距离，是一个标准的、不会变化的单位。在项目开发中，与距离对应的概念是故事点，但是大部分团队内部中都没有自己的标准化的故事点，不同团队之间更是如此。其实可以换一种思路，考虑通过对故事进行统计的方式，或者使用周期时间（cycle time）来进行预估。这种情况下你甚至可能完全不需要估算开发速度。

这是教你如何定制你自己的敏捷系列教程的第 3 篇文章。这篇文章中主要介绍了如何预估以及何时进行预估。

在我参加过的每个项目当中，无论是我自己的项目还是其他组织的项目，总有人想知道项目的持续时间是多久。在你进行数量级预估的时候，这是个有价值的问题。你的团队可能这样答复你：“ 我们做过很多类似的项目。有一个花费了 3 个月，有一个花费了 13 个月。我们认为我们的需求跟之前花费了 3 个月的那个项目更加类似。但是，代码基础发生了变化，所以我们有个大致的猜想：‘ 大概需要 6 个月的时间，并且随着项目开始 1 到 2 周之后，我们对代码有更深入的理解，从而能进一步优化这个预估时间 ’”。

这是预估的第一步。但是据我所知，很多团队都采用故事点的方式来进行预估。这种方式可能会带来问题，最常见的就是因为人们对开发速度的错误预判。

速度是一种时间点能力的预估

速度与方向是紧密关联的。但很多情况下，人们会混淆速度和加速度之间的概念，加速度关注的是速度变化的快慢而不是速度本身。速度并不是加速度。

假设你在家周边通过走路或者跑步的方式来进行锻炼。你的锻炼目标是每天通过走或者慢跑完成 2 英里的距离。

通常春天、夏天或者秋天，天气比较好的情况下，你可以采用四英里每小时的速度跑完全程。你的慢跑会耗时 30 分钟左右。

但是，你准备每天都走或者慢跑，不管天气如何。当下雨的时候，你不进行慢跑，而采用走的方式。并且，你因为没有穿合适的跑鞋而走的更慢了。取而代之的是，你穿了橡胶鞋来保证你的脚不会被雨淋湿。你采用了不同的速度来行走：3 英里每小时。你花了 45 分钟来完成全程。

此外，如果下雪了，你甚至连 3 英里每小时的速度都达不到。你穿了胶鞋的同时，还因为怕被雪或者看不见的冰滑到而更加小心翼翼地走。你的速度降到了 2 英里每小时。走完全程花费了你整整 1 小时的时间。

你仍然坚持每次都走一样的距离。但是，接下来有段很长的路要走：你走路的速度也不尽相同。你没有按照你的期望，在相同时间内走完相同的距离。干扰的因素有很多，包括天气、你的胶鞋，以及路况。

而软件研发团队会碰到相同的问题。团队的速度通常取决于完成的质量。下面列举了一些会影响到团队完成质量的因素：

故事大小。故事越大，那么团队在完成这个故事时面临的超出他们预期情况的风险就越大。就算你的团队对大的故事定义非常准确，还要记得是你的客户购买的是故事而不是故事点这个问题。参考 Customize Your Agile Approach: Start with Results ，看看其中是如何通过燃尽图（burnup chart）来反映故事的完成情况，而不是故事点。
代码现在的状态和相应的测试。自动化单元测试以及系统测试越多，那么团队在修改某个模块功能的时候所面临的风险就越小。
团队的稳定性。当你的团队是稳定的，那么团队就能通过参考历史情况来假设后面的速度。但是，当你的团队关系出现变化，有时候甚至只有一个人的变动，那么团队就无法维持与之前相同的速度前进。新人是需要花费时间来熟悉代码，以及团队的工作方式的。

此时，你可能会认为如果一个稳定的团队始终采用故事点方式来预估进度的话，那么这个团队应当能比较准确的做出预估。通过我的实践发现，一般 1 - 2 天左右的故事采用故事点的方式进行预估是比较准确的，最多情况下可以用于 3 天规模的故事。

但是，当故事变的更大，或者故事的类型增加的时候，团队通常很难通过故事点的方式来进行预估。通常情况下是故事点越多，相应的风险也就越高。

有个团队的历史数据显示，他们团队能在每次迭代中完成 42 个故事点。他们只有包含 1、2 或者 3 个故事点的故事。这些故事通常会花费大概 0.5 天、 1 天，或者 1.5 天的时间。这意味着他们可以相对独立的完成工作。

但是，在下个迭代期间，他们选择了 3 个有 13 个故事点的故事（共计 39 故事点）以及一个包含 3 个故事点的故事。这些加起来也是 42 个故事，花费他们完整的 8 天。

团队并不是因为愚笨或者懒惰。他们低估了故事的复杂度，以及故事所涉及的代码量。这是因为当你需要预估的单位，其规模越来越大的时候，你预估的误差可能就越来越大（参考 Predicting the Unpredictable ，其中有对这个现象更深入的解释。）

故事点可以用来比较你们的故事的规模大小是否相同。但是，只有一个或两个故事点的故事与那些有 5 个或者 8 个故事点的故事是截然不同的。

反而，你可以通过你的团队平均能多久交付指定数量的故事作为衡量的速度，或者修复问题的速度，或者你们团队可以用于衡量交付物的任意一种形式。这也是预估的一种方法。

可能这种方式对你来说不太适用。很多的敏捷团队使用关联预估的方式。

团队使用关联预估

如果你们团队已经采用敏捷开发有一段时间了，我确定你已经听说过使用计划扑克（Planning Poker）来进行关联预估的方式。团队成员在一起讨论下个迭代中要完成的工作。每个团队成员都有标有数字的卡片，数字可以是斐波那契中的数字或者 T 恤的规格型号（从小到大，译者注）。PO（Project Owner，项目所有者）开始解释故事的具体内容，然后团队成员举起相应的卡片，并解释为什么觉得这个故事有这么大。

每个团队成员不需要在相对的大小上达成一致，讨论的过程才是最具有价值的。团队成员讨论代码、设计、测试，以及他们能看到的任何风险。

这个讨论的过程，其实是团队对这个故事的不同理解进行讨论和统一的过程。并且，当团队最终决定故事的大小大于 “ 1 ” 的时候，这时候团队就知道这个预估中存在一个不确定因素（可以参考 Pawel Brodzinski 的 Story Points and Velocity: The Good Bits ，来了解更多关于评估的细节内容。）

避免基于任务的预估

有些团队会尝试将工作分解为任务。对这种基于任务预估的方式有个问题。我见过很多次团队都尝试采用基于人力资源优先的方式，而不是基于团队工作流优先的方式去分配任务。当一件工作被修改为已完成状态时，这件工作通常就淡出了团队的视野，因为还有很多正在进行的工作要做。很多情况下，团队每次的发布都不是按照特性来进行，反而团队会发布一部分尚未完成的新特性。这些新特性并不会帮助到客户。团队开始通过统计故事点的方式来完成统计，而不是统计已经完成的特性的数量。

换一种说法，思考一下对于那些大于 1 天的故事，你如何能做到更好的理解不确定因素呢？如果你想通过关联预估的方式理解你工作中的不确定因素，下面有一些指导建议：

要记住你的预估可能会出现偏差。比如，你有一个包含 3 个故事点的故事，你的预估可能会比这多 3 个故事点，或者少 3 个故事点。如果你的故事包含 8 个或者 13 个，甚至更多的故事点呢？在极端情况下，你那包含 8 个故事点的故事最终可能需要 16 个故事点的工作量。
问问你自己为什么会觉得这个工作花费很久。一些可能的原因是：代码很乱；单元测试或者自动化系统测试不够，无法覆盖每一个变更；工作的内容很复杂，比如是一个完整的特性需求而非一个故事。

当你在讨论一个故事的时候，可能发现采用任务这种方式进行分解是有效的。但是不要忘记你任务的最终产物，并不能直接被客户使用。客户需要的是一个或多个完整的特性。

特别是对于那些规模很大，耗时很久的故事，划分任务的方式可能能帮你发现你工作上哪里有遗漏。我不推荐通过任务的方式来划分工作。但是当你采用了这种方式，你可能发现你能更好的评估故事中的风险和不确定的部分。甚至对于小一些的故事，你还会发现你的评估更精确了，交付速度也更快了。

利用探针使工作更清晰

我开始喜欢那种一天就能完成的故事了，当然通常是指一个团队一天能完成的。你可能会想，一个团队一天怎么能完成一个故事呢？当你采取多人一组（swarming）或者人海战术（mobbing）的方式，你就会发现相比单打独斗，故事完成的效率要高了很多。（更多内容可以参考： Pairing, Swarming, and Mobbing 。）要谨记，在敏捷实践的过程当中，一个人能做什么并不重要；重要的是一个团队能做的事情。

你可能对我的观点 “ 结对、多人一组、人海战术等方式要优于个人的单打独斗 ” 持怀疑态度。不管你的看板上有几个阶段，敏捷实践证明当团队齐心协力一起的时候，将一个故事从开始移动到完成状态的效率更高。很少有团队能很好的利用好团队内部的合作。大部分团队通常都是与客户或者用户合作，但很少关注团队内部。结对、多人一组、以及人海战术的方式都能够帮助团队成员更深入的了解产品细节，从而交付更高质量、更有价值的产品。（更详细的信息可以参考： How Pairing & Swarming Work & Why They Will Improve Your Products 。）

很少有 PO 或者团队能将故事的迭代周期控制在一天之内，他们没有掌握化整为零的艺术。当团队面对比较大的故事的时候，通常会讨论故事的不确定性。例如，如果一个团队认为当一个故事包含八个或者更多的故事点是一个比较危险的情况，会存在很多不确定的因素，通常的做法可能是下面几种之一：花更多的时间讨论这个故事相关的内容，然后通过使用探针的方式拆分这个故事，亦或者采用人海战术，投入更多的人力去解决。还有一种情况是，PO 和团队一起分析这个故事，看看他是不是一整个需求合集或者一个复合型的故事。亦或者团队使用一天的讨论来对这个故事做更深入的理解。

下面描述了一个团队是如何通过一天的讨论来探索、交付，最终更加充分理解整个故事的过程。Jim 是一个六人团队的 PO，团队中包括 4 个研发人员以及 2 个测试人员。Jim 之前跟客户见面讨论过，知道客户所想所需究竟是什么。但是 Jim 看到的是整个功能集合，对于如何将其拆分为具体的故事，Jim 遇到了一些困难。他想让团队通过多人组队的方式来帮助他更好的分析其中的风险。

团队的会议在下午 1：30 开始，正好是午休之后。（因为团队之间是在一起工作的，所以他们不需要在每天早上通过通讯工具来互相沟通进度情况；每个人每天就绪后就能开始工作了。）
团队在交付方面，关于如下点是达成一致的：每次交付一个小特性之后，会尝试回答如下问题：这个特性包含了哪些故事？其中的风险是什么？我们交付的产品中的最重要的点是什么？
团队成员决定工作时间是早上十点到下午五点，之后可以选择检查邮件或者回家。中午的时候他们会工作到十二点半左右，然后去吃午饭，回来之后参加 Jim 主持的下午 1：30 左右的会议。这就是他们一天的安排。
团队开始决定采用开发者和测试者结对的方式来理解一个完整的特性是如何工作的，然后再决定接下来的工作。一开始的时候他们采用多人一组或者人海战术的方式。但是不确定的因素太多了，他们决定更换为结对的方式，然后每小时碰头沟通一次。下面是他们这一天工作的细节：
下午 1：30 的时候，Jim 向大家解释工作目标，以及客户的需求是什么。Jim 对接下来的工作有一个模糊的想法，但是他不能够完全确定。
Jim 想跟团队在下午 2 点的时候进行一次迭代。团队分成了三组，两组是由开发人员互相结对，剩下的一组由两名测试人员组成。他们互相约定，在下午 3 点的时候会重新碰头开一次会。
下午三点的时候他们回到了会议室，会上他们互相阐述了刚刚过去的一小时内都得到了什么结果，并且会后他们决定不更换互相的结对组合。
在下午 4 点的时候，团队成员又碰了一次头，互相了解了一下进度。其中一个开发人员组成的小组给出了一个原型设计，并且希望团队以及 Jim 能够给出一些建议。测试人员那一组给出了一些自动化测试用例，并且得到了 Jim 的一些建议和反馈。Jim 根据大家的结果，重新调整了一下他所需要的内容，然后每个小组仍然保持之前的结对，继续工作。
到了下午 5 点之后，团队成员再一次碰头。现在他们的方向终于正确了。有些人在下午 5：15 离开了，像往常一样结束了他们一天的工作。剩下的人继续处理他们的邮件，总结未完成的工作，准备明天继续。
第二天的早上 9：30，每个人都回到各自工作岗位然后处理他们收到的邮件。团队开了一个简单的会议，进行了重新结对然后继续工作。
在上午 10：30 的时候团队再一次碰头，跟 Jim 沟通从而获得更多的反馈意见。到目前为止，两组开发人员都完成了各自的原型设计，并且向 Jim 和团队中其他成员就他们的原型设计进行阐述。测试人员给出了他们新设计的自动化测试用例，这也帮助开发人鱼更加理解最终的所得所需。Jim 针对大家的工作成果给出了更多的反馈和建议。接下来分组调整为三个一组：两个开发人员和一个测试人员。
在上午 11：30 的时候，团队成员再次与 Jim 碰头，每组都完成了一个小的故事，并且还有相应的单元测试和自动化系统测试。团队成员互相了解了目前的故事进展。接下来的 30 分钟内他们与 Jim 一起就剩余的故事进行研讨分析。团队成员回答了相应的问题，并且解释了为什么性能问题是这一特性集中的较大风险。

这个团队采用了两两结对和三个一组的方式完成了这个过程。其他组选择了每人自成一组的形式来完成，每个人会工作规定的时间，然后一起碰头互相沟通一下彼此的进度。

但是，他们也可能选择了多人一起工作的方式。如果他们采用了，他们可能不需要每小时一次的检查点了，尤其当 Jim 也跟他们在一间屋的时候。

当团队使用探针的时候，他们可以互相了解大家每天都做了什么。他们也会了解剩余的工作量以及可能在什么时间会出现风险。

如果团队成员发现工作太复杂，他们会有如下选择：约定接下来的某一天举行探针，与团队成员和 PO 一起研讨分析目前的工作，或者重新对当下工作进行评估。

尝试着不根据大小来进行评估，采用更进一步的、更准确的方式，比如考虑通过统计故事的数量。

统计故事数量取代预估

采用故事数量进行统计的方式有一个优点，就是团队会尝试将每个故事调整到一个适合他们团队的大小。有的团队可能喜欢 1 天左右的故事，但是有的团队可能喜欢 3 天左右的故事。不管怎么说，一个团队如果采用统计故事数量的方式，那么他们会尝试让寻找一个适合自己的故事大小。

当一个团队真的采用上述方式的时候，你可能对这个团队是否有能力找到合适的故事大小而存疑。先标准化故事或者先开始采用故事计数这种统计的方式并不重要。关键点是团队需要聚焦于他们的最终目的：完成故事。当他们开始统计故事而不是故事点的时候，他们的行为会发生变化。（具体如何做可以参考： Customize Your Agile Approach: Start with Results You Want ）

有个团队刚使用故事计数法的时候，曾经认为他们不需要关注故事的大小。但是经过一次迭代的证明，他们要么需要重新审视故事的规模，要么需要测量他们的迭代时间。

故事计数法允许团队能更清楚的了解到他们的产出。并且因为故事计数法会帮助他们标准化他们的故事规模，所以团队不需要花费太多的时间在预估上。

取而代之的是，PO 和他的团队需要花费更多的时间在划分故事上，因为故事需要被划分为近似的大小。每个故事花费的时间总有差异，一个可能多一些，另外一个可能少一些。一段时间之后，每个故事的大小就基本相同了。

另外一个好处是，团队不会被基于任务的预估所阻碍。

时间周期是一个很好的方式帮助你统计自己的故事。时间周期记录了每个故事在每个阶段所使用的时间。下面的表格式，可能就是你在实际中所需要的：

故事 故事开始日期 故事结束日期 故事持续天数 1 第 1 天 第 2 天 (全天) 共 2 天 2 第 3 天 第 6 天 共 4 天 3 第 6 天 第 8 天 共 2 天 4 第 8 天 第 10 天 共 2 天 合计: 4 个故事 共花费 10 天 时间周期 = 平均每个故事 10/4=2.5 天现在你可以知道每个 story 平均花费 2.5 天的时间，那么团队就可以说：“ 我们每个迭代周期可以完成四个故事 ”。这是一个有效的统计。

假设下没有预估会怎么样

你可能听说了无预估的方式。核心的观点就是你的团队工作流程已经标准化，所以你不需要预估任何东西。如果采用这种方式，你的故事必须保持很小的规模，这样标准工作流中才能持续输出来看到相应的成果。

有时候团队预估可能也没什么用。你可能有过如下经历：

在你完成并提交故事之后，PO 想修改故事
团队发现之前认为很小的故事实际并不小的时候
团队发现自己的代码或者测试用例搞错了方向的时候

团队这时会发现预估失效了。这种情况下，故事计数法可能更有帮助。

要记住的是，如果你的团队每周或每两周需要交付一个可以运行的产品给你的经理或者客户的时候，你可能就不需要预估了。

总结

关于预估，不同的团队可以选择不同的方案。我还没有发现根据故事点速度来实现一个很好预测的案例，除非这个团队能做到每个故事都能在 1 天或者 2 天内完成。我还发现，时间周期是一个在整个迭代周期中都好用的方式。这是因为时间周期利用了你的团队的历史数据。

如果你需要预估你们团队的工作量，尝试下能否将工作目标拆分为 1 天左右的故事，然后进行统计。如果不能的话，可以尝试在某天采用探针的方式暂停当前的工作，将已经完成的特性进行发布，并统计下剩余的故事。

如果可以的话，尝试让你的团队采用工作流的方式进行工作，每天都完成 1 个故事。这样可能会帮你节省预估的工作。

关于作者

Johanna Rothman, 以 “ 实用主义管理者 ” 的称号为人所熟知。她能为困难问题提供最直接的建议。她擅长帮助团队发现自己的问题，协助领导和成员解决问题和风险，以及更好的管理项目开发的进度。Rothman 著有 10 余本著作，包括：Create Your Successful Agile Project: Collaborate, Measure, Estimate, Deliver, Agile and Lean Program Management: Scaling Collaboration Across the Organization, Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, 2nd ed. 你可以从网站 jrothman.com 上找到更多关于 Rothman 著作的介绍。