深入浅出 Kanban 系列 (2) - 如何解决计划和时间估算痛点

使用看板的流程可视化，可以消除不必要的流程和减少沟通成本。除此之外，我们还可以用它从另一个角度来解决开发流程中很普遍的问题——计划和时间估算痛点。

现实情况

传统管理或者计划方式是这样的：首先根据一个迭代有多少人天数，再加上估算出来的工作任务大概要多长时间做完，然后产品经理或者业务部门按照优先级挑选出匹配的任务。可是常见的问题是，某些估计可以完成的任务无法及时完成，要么推迟，要么中途再排优先级和砍任务。

产生这种情况的原因很简单，因为时间估算经常不够准确。多年前，在软件开发领域里的一本负有盛名的书——《人月神话》，其中已经花了整整一章节来阐述过这个问题。我们如果就把估算时间当作是承诺完成时间，会有很大问题。

是否还需要估算时间

如果说我们一直在做的时间估算通常不准，不应该拿它来解决计划的问题，那它还有没有用？我们不妨问清楚我们自己，到底我们是用它来做什么。下面列举一些常见的使用场景：

1. 人力资源充分利用

   高利用率的一种意图，是希望在一定时间内能做更多的东西出来。但是，如果我们把迭代时间和人天时间算得很紧，这是很危险的。也就是说，如果有一点点的意外发生，那就会影响计划了。随之而来的是，重新计划和调整。而这些环节，也都是有成本的，还可能带来质量的下降。

   还有另一种比较可悲的想法就是把空闲人力资源都用尽，像管理以前的体力劳动工作者一样。这种想法是觉得，如果有空闲人力资源，他们并不会做一些对团队和公司有什么益处的事情。实际上，这是某程度的信任问题，和把知识工作者当作耗费品，而不是财富的思想。

2. 平衡优先级

   时间估算，也会被用来协助平衡优先级，也就是要衡量所谓的投入产出比。

3. 做计划

   艾森豪威尔（Dwight Eisenhower）曾说过， “planning is everything, the plan is nothing.” 计划的目的其实具体有好几种，有时是想知道，如果我想在某一个时间前完成某件事情，那应该什么时候开始。或者是，我要做一个项目或者功能，想知道什么时候做完。要么，像上面所说的，结合人力资源，希望达到投入产出最大化。
   
   如果要为了确保事情能在规划时间内完成，估算的时间里一般都会加上一点点缓冲。比如，原来认为是两个人天能做完的事情，估算可能会加到两个半人天。但是，这个缓冲怎么加，误差有多少，就有相当大的考验了。我们虽然可以通过一些其它的手段来尽量减少它的误差，比如共同评估，尽量分解任务成为细小的单元等。但是，很多影响计划的因素是不可控的，多任务带来的效率问题，优先级改变，人员的流动等。如果我们用时间估算的方法，关注个体，这个误差可能会比较大。所以说，把估算时间，当作承诺交付的时间来排计划和资源的时候，会有比较大不确定性。

Martin Fowler 写的《估算的目的》就说得很好。估算有用，但其实是看它给我们带来什么真正的好处。它可以用做任务间难度对比，评估上线风险看是否需要简化，或者相应地平衡优先级等。只是，如果这些好处可以通过其它方式获得，那就不一定要用估算这种方式。

其实，在敏捷社区里面，之前也已经有不少声音是关于摒弃时间估算的了，还推动名叫 #NoEstimates 的运动。有兴趣可以从原文链接里看看下面几篇文章：

The NoEstimates Movement

'No Estimates' in Action: 5 Ways to Rethink Software Projects

No Estimation in Small And Large Scale Agile Projects

看板是否可以解决

针对以上的场景，看板是怎么看的？

1. 人力资源充分利用

   如果所有的任务来源都反映在看板里，团队是用看板来沟通的，那么，是可以从看板上看到每个人当前的任务是什么，在什么阶段。所以，还真可以看到每一个人的负载情况，从而得知有没有空闲的资源。这样并不需要通过估算来达成这样的目的，而且还更实时准确。
   
   但是，看板不主张每一个阶段都达到 100% 利用率。闲置人力资源对持续改进和提高创造性都是很有帮助的，不是说利用率越高越好。Google 之前提出的 20% 自由时间，LinkedIn 的 InCubator, Apple 的 Blue Sky 和微软的 Garage 项目，都是为了让员工有自由时间去创造而提出的项目(近期好像 Google 已经收回了那个 20% 的自由时间的项目，但是还有不少公司认为这种模式是有效的)。再说，追求高资源利用率，也不是新时代应有的知识工作者的管理方式。有兴趣可以看看管理学大师，德鲁克，在这方面写的一些书。

2. 优先级

   首先，优先级不应该是什么高，中，低，然后再加上时间估算来平衡，而是真正的1, 2, 3 这样的顺序。没法做到这样，其实是我们还不能清楚知道最重要的事情是什么。有些事情，如果真的是非常的重要，而且无法简化或者分割，那么无论多少时间，我们都需要倾尽所有的资源和时间在上面，对吧？倘若真的没法清晰区分不同任务的重要性，当然我们还是可以用估算来平衡一下。
   
   看板无法帮我们决定优先级，但是可以很透明的反映任务状态和优先级，整个团队都可以很清楚状态，有优先级变更，也可以更好协调。而且一旦任务优先级确定并开始，看板就能帮助我们关注在流的管理上，尽可能快和顺畅地把它完成。

3. 做计划

   
   认清了计划的目的，那看板是否可以不用估算时间来实现。在看板，我们观察的指标是前置时间 (lead time)，这个是任务从开始到结束的实际时间，并不是估算。它包含了任何外部因素对任务的影响在里面。 而且，我们是用统计的眼光来看，忽略个体（包括人，任务，环境等）差异，就像你在估算时候利用共同评估来忽略人的差异一样。通过前置时间的统计分布，我们就能得知团队的真实交付能力和效率。比如说，我们可以知道 85% 的情况下，相同性质的任务大概要多长时间完成。软件研发本身就比较复杂，而且知识工作者的管理更加复杂，就像大数据中的理念，我们要容忍不精确。

看板并不是万能，它无法帮助我们解决所有的问题，但是可以协助我们把注意力，从老旧的坏习惯，转到真正应该关心的事情上面来。

结语

时间估算其实很难，而且经常是不够准确的。一旦使用它的出发点不对，就会给开发人员带来不必要的精神负担，也无法作为计划的有效参考依据。所以，我们要关注的是，我们期望从估算获得的好处是什么。

如果我们关注的是前置时间的统计分布区间，我们可以知道到底什么时间才是最保险的开始做一个项目的最晚时间。一旦我们能把前置时间缩短和固定在某一个值附近，偏差也不大，也就是说明我们对开发项分拆已经是比较均衡，而且一般没什么大的流程的阻碍，或者即使有，也能很快解决。这样，其实我们能有更清晰的认识和参考依据来做计划，达到同样的目的。

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

互联网plus管理新范式

Agilean官方博客平台

微信号

iPlusLeadership

点击

阅读原文

了解更多详情