敏捷开发培训会！（十年大佬分享，不看后悔系列）

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

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

近期有幸参加了一场敏捷开发的培训会，是由一位十年以上产品大佬分享的，真的是让我受益良多，获益匪浅。

在这里做一次总结，一方面，是为了吸收消化一下这次培训的精髓所在，另一方面，当然是分享给大家啦，谁让你们一直陪伴着我呢，有好东西当然是想着大家啦！

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

我之前分享的自己写的各种述职报告，就属于用来讲的那种，也就是没有我的现场讲解，大家是不大容易看明白的，或者是说不大能够get到我想表达的全部信息的；

而今天分享的这次敏捷培训的PPT，基本上属于用来看的这种，也就是大家自己看PPT本身，没有人讲的话，也大致能够明白想传递的信息精髓所在。

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

（1）流程

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

瀑布模型分为七个步骤，这个也应该是我们再熟悉不过的了：1. 可行性分析；2. 需求分析；3. 概要设计；4. 详细设计；5. 编码开发；6. 测试（单元、集成、验收）；7. 部署上线。

每个阶段的产出物，相信也是我们日常工作的一部分，例如《可行性分析报告》啊、《需求分析文档》啊、原型图、测试用例啊等等，这里就不详细列举了。

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

（2）问题

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

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

1. 需求变更

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

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

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

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

（该观点出自文章《五个要点，助你应对需求变更！》）

对于瀑布式开发模式来说，由于业务需求的多变性，导致很难有稳定的需求边界，需求变更就更加难以避免了。

而且经常性的需求变更，给整个团队带来的损失是极大的，不仅仅是劳动时间的白白浪费，更重要的是影响大家的工作积极性，会让大家认为，有些事情做了，也会没什么结果，没什么意义。

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

2. 进度延迟

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

但如果开发团队面对是一个200多页的方案或者PRD文档，这个时候的工时应该怎样预估，或者说应该怎样才能准确预估，恐怕没人知道。。。

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

一个不可控的过程，往往会造成一个不可控的结果，在瀑布式开发的模式当中，项目失控并不罕见，我就经历过。。。

3. 业务误解

瀑布式开发的模式当中，产品设计和产品开发往往是割裂的，二者只是通过交付物进行信息传递。

人与人之间，通过不断反复地语言沟通，还避免不了信息差的情况呢，更何况仅仅是通过冰冷的文字。

于是乎，开发对于业务的误解，那也是在所难免的了，功能开发出来以后，不是我们原本设计的，或者是使用人员想要的。

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

4. 项目取消

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

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

谁也不能够保证，每一项决策都是正确的，所以项目取消，有时候也见怪不怪吧。但这个时候，就会造成大量的成本浪费。

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

（3）敏捷宣言

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

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

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

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

3. 与客户协作 胜于 合同的谈判！

4. 对变化的响应 胜于 遵循原计划！

这四句宣言，大家初步读起来或许就会有不一样的感受，相信在敏捷开发的过程中当中，大家的体会会更加深刻！

（4）敏捷理念

了解了宣言之后，我们再来看一下敏捷的理念。

这11条理念就不再一一赘述了，大家可以花一分钟时间自己看一下，体会一下是否跟自己之前的理念不一样，甚至是颠覆了自己的原有理念~

尤其是像“欢迎对需求提出变更”这一种~

（5）敏捷前提

当然，也并非所有的团队都适合敏捷模式的，敏捷也是有前提的，这个前提总结一下的话，有这四个方面：

1. 领导支持

这一点真的非常非常重要，如果领导层压根没有敏捷的概念或者意识，当你第一个核心功能的迭代版本出来以后，领导层通常会反馈“这是什么玩意”这种话。。。

这也很正常，因为通常第一个，甚至前几个迭代版本，东西还少，又没有用户体验，关键长得也不好看。。。

2. 教练保障

如果一个团队在之前没有经历过敏捷模式，那一个敏捷教练的保障是必不可少的，不然就刚才所说的一个理念，敏捷是欢迎对需求提出变更的，那产品跟开发还不得天天干架啊。。。

那敏捷教练是干嘛的呢？简单介绍一下的话，大致分为这几个方面吧：

• 技术教练（CI/CD，OO，微服务，Cloud 等）

• 团队教练（团队流程，团队建设，团队回顾等）

• 组织教练（组织级变革）

• 管理教练（战略，人才等）

总之就是找个有经验的人带带大家，保障迭代能够顺利进行，防止大家天天干架。。。

3. 熟悉敏捷

敏捷开发模式当中的相关成员，一定是要熟悉敏捷的。

想要熟悉呢，无在乎两个方面：一方面是通过培训提升理论知识，另一方面是通过实践进行理解并应用。

4. 人员调整

敏捷模式，可以说是麻雀虽小五脏俱全，一个完整的工作组以及角色分工，那绝对是必不可少的。

稳定是一切持续的前提！

（6）敏捷框架

敏捷模式的框架可以说跟我们瀑布模式的框架没什么两样。

只不是敏捷模式，是一种持续循环的模式，每次迭代任务大概只有2-4周，对于产品是一种螺旋式上升的过程。

如果非要说一些不一样的地方，那么每日立会或许是一个~

（7）敏捷角色

我们再来看一下敏捷模式中的六种角色~

1.导演：保护团队不受外界干扰是团队的领导和推进者，提升团队的工作效率，确保所有的利益相关者都可以理解敏捷和尊重敏捷的理念；

2.演员：交付产品并对其质量负责，对所有提出产品请求的人一起工作，创建功能设计，测试并交付产品；

3.老板：为团队搭建良好的环境，以确保团队能够出色工作；

4.制片人：为团队提出产品需求的人，会与组织签订合同以开发产品；

5.编剧：从业务角度驱动项目，传播产品的明确意愿，对投资回报负责；

6.观众：根据自己的业务知识定义产品，并告知团队自己的期望，提出请求。

（8）敏捷产出物

整个敏捷开发模式，关键的产出物，有这么四种：

1. 剧本：一个列表，涵盖了词汇，故事，需求和功能等等，团队要在将来交付这些条目；

2. 场景：团队希望到Sprint结束前开发出来的Product Backlog条目排序列表；

3. 情节：Sprint结束时，Scrum团队要交付有可能发布的产品增量；

4. 实际拍摄：一个任务列表，开发团队使用它来可视化团队活动。

（9）思维方式

最后呢，我们再来感受一下，瀑布思维与敏捷思维，两种思维方式的不同。

这一个大家就自行阅读吧，总之呢，大家行为方式改变的前提，一定是思维方式的改变。

敏捷开发的模式，有诸多的优点，可以说是现在主流的模式，但也有它自身的局限性。

关于模式的选择，就像寻找人生另一半一样，没有最好的，只有最合适的~

实际的培训过程，大概持续了两个小时的时间。

其间举了很多我们工作过程中的实际事例，这个我不好体现在我们的公众号当中。

但我已经把培训时所讲的，敏捷开发的精华内容，全部奉献给了大家，反正我当时听的是挺有感觉的，让我对于敏捷开发有了一个全面的认知，也希望能够对于大家有所帮助吧。

最后呢，大家如果需要这个PPT资料的，可以在公众号后台回复“资料分享”四个字，就可以查看获取方法啦。可以作为自己工作的指南，也可以当个培训资料，去教育教育小弟小妹们，赚取一下他们崇拜的眼神，哈哈哈~

END

原载作者公众号：