切片、估算、剔除 | 抛弃估算系列 | Agilean学院出品

这篇Ron Jeffries的这篇文章介绍了通过工作范围切片进行工作历时估算，由Agilean学院张明,张迎辉翻译，侯伯薇审校

许多人都支持或加入了“抛弃估算运动”，试图通过简单的机制限制估算的使用，比如：观察进度并据此预测未来。可是事情变得更困难了，所谓的进展“大小不同”，因此我们没法根据当前的进展预测未来，至少部分人这么认为，而在一定程度上这是事实。

当然，假如我们工作在为期两周的迭代中，并且很有把握在两周内可以完成10个同样大小的功能。那么通过快速地把待开发的功能切成同样大小，我们就能比较有把握地预测进展。

此时，有些人会说把功能切分成合适的大小也是一种估算，你们根本就没有抛弃估算。你们声称抛弃估算，其实到处都是估算。

好吧，如果你们也开始用这样的估算方法，我们乐于承认到处都是估算。此估算非彼估算：你含糊其辞随口嘟囔个功能，却强迫我们给出精确的数字。你把我们给出的数字加起来，并告诉我们数字太大了。你再随口编造个数字，并强迫我们把你随口编造的数字变成现实。这还不算完，你不断改变需求，增加更多随口嘟囔的功能。在你明明说了要紫色的时候，竟然嚷着"我绝不可能想要紫色的！你们怎么搞的，这么清楚的需求都搞不定，太没用了。”

但我离题了。计数并基于此估算，大多数人觉得还不赖。可是在抛弃估算运动中，这可不是我们想要的。

早在2004年甚至更早，从“运行测试过的功能”的理念出发，我开始写文章讨论估算的问题。从那以后，还冒出来了更好的点子：许多从这里可以链过去，还有一些要从别处链过去。

基本的理念是：假定所有的功能都同样大小，那么只要做一个功能，然后数数一共有多少功能，就可以精确预测项目多久完工。不需要骚扰任何人，只要把功能排上日程表就可以预知未来。

慢着，抛弃估算的傻瓜们！功能不都一样大，数数的主意根本行不通。

不，等等！如果能把用户故事切分到合理的大小，一个星期差不多可以完成十个，那就足够好了。切分，计数，排上日程表。瞧着吧，你的进度表已经胜过这个世界上一半的进度表了。

你把这个也称为估算？好吧，如果你能接受，我们就称之为估算。你把自己绕晕了吧。

等等，我还没说完。

我们这些走在敏捷最前沿的家伙在用一种叫切片的技术。我们把用户故事切成小片，每个切片仍然是个故事。也就是说，每个薄片不管长得像不像番茄意大利面，至少要尝得出商业价值的味道。

事实上切片通常不需要任何估算。我之前提到过从Neil Killick那儿学来的主意：把一个大的故事切到每个小薄片只需要一个验收测试。这么小的薄片几乎肯定可以在几天内做完。不然验收测试就太大了，需要拆分。拆分验收测试的话题改天再聊。

这样一来，估算就转化成了故事切片和计数，故事切片只需要拆分验收测试，完全不需要估算。数数过去一段时间做完了多少薄片，还剩多少薄片，我们就可以预测了。

结论是：比起传统估算来，计数是最简单有效的估计项目完工日期的方法，切片是得到计数的好方法。因此，抛弃估算运动的家伙并没完全疯掉，为之辩护的人可以歇歇了。认为估算是必须的，甚至是天赐的礼物，你们走开！

但是别急，还有更多...

假设上面的方块代表一个大的故事，我们把它切成了更小的小故事。每个切片代表一个验收测试，每个切片都适用我们的估算系统。当我们观察这些切片时发现，某些切片不如其他的重要，它们是修饰的花边或者带来的价值不如其它切片大。

我们干脆不做这些切片！如图所示，我们直接砍掉它们。在这个虚构的例子里，我们比原来节省了40%的成本。我们可以直接去做其它更重要的工作。

每项需求都有水分，即低价值的部分。每个大的故事都由小故事组成，有些小故事价值高，有些价值低。切分故事的时候，如果我们跟商业客户紧密合作（像敏捷宣言建议的，每天），很容易把低价值的水分剔除出去。

切片胜过估算。更妙的是，切片确保我们总是先完成高价值故事、以及故事里面高价值的切片。无论我们想要实现多少价值，切片的方法都会降低总成本。

现在就试试切片吧，你在切片上的投资得到的不是一个、而是两个回报。一分不花就得到39.99美金。现在就拨打热线，客服已经准备好为您服务。

请长按一下二维码，关注我们的微信公众号：互联网plus管理新范式。

互联网plus管理新范式

Agilean官方博客平台

微信号

iPlusLeadership

点击

阅读原文

访问英文博客