【敏捷那些事儿 06期】选敏捷还是瀑布？

---

敏捷系列内容：

【敏捷那些事儿 01期 】跳出误区的我，应该如何看待敏捷？
【敏捷那些事儿 02期】如何理解敏捷价值观和原则？
【敏捷那些事儿 03期】一文讲透敏捷的“道、法、术、器”
【敏捷那些事儿 04期】敏捷实践中的迭代和Scrum
【敏捷那些事儿 05期 | 敏捷实践中如何提高团队敏捷性？
【敏捷那些事儿 06期】 选敏捷还是瀑布？

---

在介绍完敏捷实践的相关内容后，大家可能会有个疑问：是继续使用传统的以控制和计划为导向的瀑布模型，还是使用可以提供许多好处的敏捷？

这也是企业和项目经理面临的一个比较大的挑战。本期将分享在实际项目管理过程中到底该是选择敏捷还是瀑布？

---

敏捷与瀑布的场景及关系

我们可以从具体的例子中，观察两者的使用场景及关系。

# 桥梁建设

桥梁在修建初期，其勘探规划都非常明确，且不会面临过多变更。

比如公铁两路桥不可能在中途改为公路专用桥，这时我们自然会选用瀑布模式。

# 食品加工

食品加工所使用的流水线生产方式也适用于瀑布式。

因为整个生产制造过程是一环接着一环的，比如生产一块饼干时，在制造过程中不会突然变成巧克力。

最终产品交付的结果非常明确，所以通常会选用瀑布的方式。

# 开发一款新的互联网产品

互联网产品的开发往往会面临着许多新的不确定的需求，所以我们往往会选择敏捷模式。

从上面的例子可以看到，瀑布和敏捷其实并没有绝对的优劣之分，该怎么选取决于具体情况。

正如这样一句话：

如果说敏捷是比瀑布更好，那么就像说一辆车比一艘船更好

车和船都是交通工具，陆地上选用车，水上就选用船，具体的出行选择视使用环境而定。

敏捷与瀑布，也是如此，两者都有各自的优势和局限性。瀑布模式并不是落后的，也并不是所有的项目都要用敏捷的方法去做。

事实上，选用瀑布还是敏捷并不是一个非此即彼的决定，我们所选用的解决方案通常会介于两者之间，比如以下这几个例子。

# 增加额外的计划层

上图下方所显示的是一个Scrum框架，在每一个迭代开始前，我们都会做一次迭代的sprint计划会，这就是一个迭代级别的计划层。

而我们仍然可以给这个项目再额外加上一个项目级的计划层，并且这个计划层根据需要可大可小。

比如依据决策流程、开发周期、需求收集等等，设定相应的项目计划。当项目计划转化成具体的待办事项列表后，我们就可以进入迭代级的计划，安排1~4周为一个迭代周期，逐步实现需求。

以上这种方法增加了一个额外的计划层，就是将敏捷和瀑布进行了结合。

# 大型敏捷团队的交付模式

在进行更大型、更复杂的项目开发时，整个产品backlog中的待办事项会非常多。

此时我们就可以对backlog做一个路线的规划图，包括大的版本一、版本二、版本三。这一块是由产品决策小组来进行一个相对应的规划。

而每个具体版本的发布，再由Scrum团队来做sprint级别的规划，比如sprint 1、sprint 2、sprint 3，会把sprint级别的规划放到相对应的sprint的任务板里。

这就是一个大型敏捷的交付模式。

** #不同层次的敏捷性**

从上图左侧可以看到，敏捷性有着从这些不同的层次。

从上图右侧则可以看到，传统计划驱动（瀑布模型）的敏捷性和适应性较差；而最右侧的敏捷，比如Scrum、SAFe则有着很强的敏捷性和适应性。

在两者之间，还有一种混合型架构，这是pmi推出的一个可控的敏捷交付框架，保有了计划性和适应性。

---

敏捷 X 瀑布

通过上述的例子，我们会发现敏捷和瀑布之间关系并不是“or”，而是“x”，两者是一个有效的结合。

从图中可以看到：最左侧是瀑布模型，最右侧是敏捷模型，中间则还有很多混合的方式方法。

敏捷与瀑布不是各自独立的方法论，两者能够相互兼容。

我们应认识到，计划驱动和适应性方法应该是互补的，而不是竞争的；敏捷并不是一个比瀑布更先进更高级的工具，而是另外一种思维模型，里面诞生了很多实践、方式、方法、工具，拥有很广泛的含义。

最好的方式就是将方法的组合与项目的商业环境相适应。

---

回看对敏捷的误会

在本系列的最后，让我们回到开头，再看看那些对敏捷的误会，此时会不会有全新的体验？

一、我们澄清的是敏捷开发并不是快速开发。

比如用瀑布六个月完成的工作，并不是说用敏捷就可以四、五个月完成。而是说在有敏捷思维、方法和实践后，我们的团队更具有适应性，更能拥抱变化。

二、我们用敏捷因为我们是迭代开发。

迭代开发也可能只是一种增量式的，我们更关注的是每个迭代的交付物，每次迭代能够有相对应的产出。

三、我们用Scrum，因为团队每天都开站会。

注意：并不是每天开站会，就是用了Scrum框架。

是否使用了Scrum框架，需要看团队里面是不是具备三种角色，是不是在开四个会议，是不是定义了迭代周期。

详细内容可点击查看：【敏捷实践中的迭代和Scrum】

四、不写文档、不做项目计划、不用走流程是不可能的。

敏捷宣言里只是说更重视左侧，并不是要舍弃右侧。

五、需求不确定用敏捷，需求确定用瀑布。

这只是一个大方向上的判断，因为现实情况可能会更复杂。

比如在需求确定的情况下，我们的开发团队也可以用敏捷、迭代的方式进行交付物的产出，它的效果或许会更好。

此外，互联网产品用敏捷，因为互联网产品天生就是需求多变的,更适合用敏捷。

最后分享一些学习参考的书籍：

《Scrum指南》

涵盖一些Scrum必备的要素、框架、方法、工具等。

《敏捷革命》

较通用的科普性书籍。

-迈克科恩撰写的系列书籍-

从专业的角度深入学习。

敏捷系列内容到这里就完结了~希望通过以上分享，能够解答大家内心的一些困惑！