对不起，这个锅，敏捷不背

某公司的头号项目正在如火如荼地进行着。

这是一个跨国合作的项目，有严格的上线期限，采用敏捷的Scrum方式交付，管理层希望把它做成敏捷运用在大型项目的标杆。而这个项目组成员的口头禅是：“ 因为是敏捷，所以不需要做计划。”也正因为这样，项目成员对于这个复杂项目所需要的要件和资源并没有一个清晰的规划，有点做到哪算哪的意思，经常出现各种意外情况（其实完全可以通过前期规划避免），蕴含着巨大的风险。

敏捷真的不需要计划吗？如果因此这个项目最终一地鸡毛，这是敏捷的错吗？

我在《对瀑布和敏捷的最大误解》里提到，对瀑布和敏捷的最大的误解就是瀑布只需要关注计划的执行和敏捷不需要计划。

对于一个项目而言，不管交付形式怎么变化，范围、资源（成本）、时间、质量这几个要素都是关键的。业务有一个需求，必然需要知道要花多少钱和多少时间。

早年我和我的上司探讨整个部门的敏捷转型时，她非常拥抱敏捷的思想，但是我们陷入一个迷思——如果采纳敏捷后，在项目开始无法回答业务关于成本和时间的问题，我们也感到很困惑和不可接受。

这两年的实践，让我对这个问题终于有了清晰的认识。我的结论是对于一个有复杂依赖关系的项目来说，事前的计划是必须的，而且这个计划需要不断回顾和调整，但这个计划并不是为了一折不扣地执行的，在执行和交付层面，我们需要随机应变，敏捷方法增强了我们的应变能力，而计划中确定的预算和资源，是这一切的基础。

在敏捷的原则下，项目的关键因素也有了新的内涵：

1. 范围——更关注最小可用产品（MVP）的定义；

2. 资源（成本）——做任何事情都要有钱和有人，要估算大概需要多少钱和人；

3. 时间——我们需要知道要做什么、它们之间的依赖关系是怎样的，关键路径是什么；

4. 质量——说清楚需求从来不是一件容易的事情，除了要拆分需求进行简化以外，实例化需求，提前准备好验收测试用例以形成交付闭环也是关键。

同时，模糊的正确要胜过精确的错误。我们不必追求计划的精确性，在交付过程中，更重要是围绕业务目标灵活应变，与业务一起想方设法达成某个阶段的业务目标。罗胖曾经提过：指南针比地图重要，对于项目来说，目标比计划重要。

以上结论对于产品开发同样适用，同理没有钱、没有人，你什么都不会变得出来，老板、投资人也需要知道要投入多少钱、多长时间能看到成果，哪怕是阶段性成果，这些都需要计划。

小结一下，今天想说就是两点：

1. 做一个项目或产品，计划必不可少，计划不需要面面俱到，不需要精确，但是要能解决需要多少钱、哪些资源和多长时间的问题；

2. 交付的过程可以是迭代的，围绕业务目标随机应变，而应变的基础，来自计划确定的预算和资源，敏捷原则和方法提供了应变的具体思路和实践。

两者缺一不可。

购书通道

—