对瀑布和敏捷的最大误解

0
421
本文作者:刘华Kenneth
转自:https://mp.weixin.qq.com/s/ONHHqVLgy-lHlZjbJR7Igg对瀑布和敏捷的最大的误解就是瀑布只需要关注计划的执行和敏捷不需要计划。

01 — 瀑布只需要关注计划的执行吗?
典型的瀑布项目管理就是制定整个项目的计划并监控计划执行的情况。但如果把执行计划当作项目管理的全部,则是大错特错。计划的价值并不在于执行(关于这一点,可点击“阅读原文”参考“得到”的《计划的用处》的文稿和语音,让你茅塞顿开)。我们需要计划来规划资源以及所需要的各种依赖。它能确保我们能顺利地开展项目。但就像我们开车前需要规划路线,而在开车过程中则需要随机应变一样。在项目执行过程中,应变才是最重要的能力。因此,我们需要简化变更流程。而且,我们需要区分输出(output)和产出(outcome)这两个概念。计划、文档是输出,交付才是产出,对用户、业务有价值的东西,这才是我们关注的重点,而不是反过来。所以,我们的关注点不应该是计划的执行情况,而是基于最新的情况,如何才能满足当前的业务目标,做价值驱动的交付。而且我们要让用户、业务持续参与到项目执行过程,形成集体决策、责任共担,也避免了事后解释和互相指责的不必要开销。
02 — 敏捷就不需要计划了吗?

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

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

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

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

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


  • 就职于世界500强银行,负责基金服务业务软件开发与交付
  • 敏捷、精益、DevOps专家
  • 精通极限编程、Scrum、看板方法、测试驱动开发、持续集成、行为驱动开发、DevOps工具栈
  • 曾在GDevOps、DevOpsDays Meetup、中国软件技术大会等论坛发表主题演讲
  • 著有《猎豹行动:硝烟中的敏捷转型之旅》一书

- leansoftx.com -