产品经理敏捷开发培训会!(十年大佬分享 不看后悔系列).pdfVIP

话说，你们公司用的是哪种开发模式？瀑布式开发or敏捷式开发？

然后，作为产品经理，你真的了解当下主流的敏捷开发模式么？还是只听

过其概念？

近期有幸参加了一场敏捷开发的培训会，是由一位十年以上产品大佬分享

的，真的是让我受益良多，获益匪浅。

在这里做一次总结，一方面，是为了吸收消化一下这次培训的精髓所在，

另一方面，当然是分享给大家啦，谁让你们一直陪伴着我呢，有好东西当然是

想着大家啦！

前言

首先说个前提，PPT这玩意从大的方面划分，可以分两种：一种是用来讲

的；另外一种是用来看的。

我之前分享的自己写的各种述职报告，就属于用来讲的那种，也就是没有

我的现场讲解，大家是不大容易看明白的，或者是说不大能够get到我想表达

的全部信息的；

而今天分享的这次敏捷培训的PPT，基本上属于用来看的这种，也就是大

家自己看PPT本身，没有人讲的话，也大致能够明白想传递的信息精髓所在。

来，废话少说，让我们开始这次培训，Letsgo！2

瀑布式开发

（1）流程

相信很多同学都熟悉瀑布式开发，尤其是B端项目制的同学，应该大部分

使用的，都是这种开发模式。

瀑布模型分为七个步骤，这个也应该是我们再熟悉不过的了：1.可行性分

析；2.需求分析；3.概要设计；4.详细设计；5.编码开发；6.测试（单元、集

成、验收）；7.部署上线。

每个阶段的产出物，相信也是我们日常工作的一部分，例如《可行性分析

报告》啊、《需求分析文档》啊、原型图、测试用例啊等等，这里就不详细列

举了。

这就是大多数人所熟知的瀑布式开发模式。

（2）问题

不过这种模式，也是存在诸多弊端的，不然敏捷开发也不可能上位，哈哈

哈。

归纳起来，瀑布式开发模式，有四宗罪：

1.需求变更

产品经理和开发干架，大多时候都是因为需求变更。

就像互联网经常调侃的那个段子，产品经理对开发说：“砍我可以，不能砍

需求！”

而且大家还记得，我们之前在总结需求变更文章时的一个重要观点么：

“需求变更是必然的、可控的、有益的！”

对于瀑布式开发模式来说，由于业务需求的多变性，导致很难有稳定的需

求边界，需求变更就更加难以避免了。

而且经常性的需求变更，给整个团队带来的损失是极大的，不仅仅是劳动

时间的白白浪费，更重要的是影响大家的工作积极性，会让大家认为，有些事

情做了，也会没什么结果，没什么意义。

这也是瀑布式开发，最显著的缺点。

2.进度延迟

面对一个小的功能，我们能够准确地预估出来，需要花费多少工时。

但如果开发团队面对是一个200多页的方案或者PRD文档，这个时候的工

时应该怎样预估，或者说应该怎样才能准确预估，恐怕没人知道。。。

再加上上面所说的必然的需求变更，所以进度延迟是经常发生的事

情。。。

一个不可控的过程，往往会造成一个不可控的结果，在瀑布式开发的模式

当中，项目失控并不罕见，我就经历过。。。

3.业务误解

瀑布式开发的模式当中，产品设计和产品开发往往是割裂的，二者只是通

过交付物进行信息传递。

人与人之间，通过不断反复地语言沟通，还避免不了信息差的情况呢，更

何况仅仅是通过冰冷的文字。

于是乎，开发对于业务的误解，那也是在所难免的了，功能开发出来以

后，不是我们原本设计的，或者是使用人员想要的。

到时候就又该扯皮了，到底是谁的锅呢？

4.项目取消

这种项目取消就属于重大事故了。。。

在团队的分工当中，开发团队是负责实现的，产品团队是负责设计的，管

理团队是负责决策的。

谁也不能够保证，每一项决策都是正确的，所以项目取消，有时候也见怪

不怪吧。但这个时候，就会造成大量的成本浪费。

这也是MVP产品模式，在这些年逐渐兴起的原因吧。03

敏捷式开发

（3）敏捷宣言

上面我们了解了瀑布式开发的流程以及问题，接下来我们正式进入今天的

主题：敏捷式开发！

想要了解敏捷式开发，就需要先知道这四句敏捷宣言：

1.个体和交互胜于流程和工具！

2.可工作的软件胜于求全责备的文档！

3.与客户