对瀑布和敏捷的最大误解

首先来分析一下这个误解是怎么来的。我们看到各种敏捷教科书里很多端到端的敏捷案例都是像互联网产品这样的面向消费者（To C）的产品的，其需求和用户都是不确定的。这类产品的具体的用户和需求，是一个需要不断探索和验证的过程。整个过程最关键的是试错——更快地开始行动并通过真实的市场反应获取反馈。因此也不适合和不可能预先做长期的计划。

但是大多数面向业务（To B）的项目则完全不一样。针对一个需求，尽管可能还非常概要，我们需要明确回答要多长时间和多少预算才可以完成，不管准确与否，业务需要一个承诺，因为他们需要以此给客户一个承诺。

因此，不管是采用敏捷计划方法（故事点和测速）还是瀑布项目计划方法（WBS、网络图、关键路径），我们都需要在项目开始前有一个大致的计划。我们需要对整个项目需要交付什么、有哪些必须的流程以及大致的交付时间做到心中有数。当然正如前面提到的，这份计划并不是为了执行。在项目执行过程中，我们可以采纳敏捷、精益的手段更好地应变。

不管是瀑布和敏捷，项目管理背后的核心逻辑并没有什么冲突。而最大的冲突在于很多人对这两套方法论的误解和误用。我总结一下项目管理的一些关键点：

1. 关注当前的业务目标，而不是时间；
2. 随机应变，价值驱动；
3. 减小批量，加快流动；
4. 频繁沟通，持续反馈，集体决策、责任共担；
5. 以终为始，提前明确验收条件；
6. 减少不必要的交接与依赖，减少等待时间。