从产品的视角看待敏捷开发减少和程序猿撕的几率
⇨⇦
作为产品，如何有理有据地撕程序猿呢？如何把程序猿撕的无话可说，且直接认怂呢？答案就是——了解程序研发流程中的点点滴滴，多用程序猿的视角与程序猿沟通问题，提高产品研发效率，尽可能减少撕的环节。
产品原型制作完成了，下一步的工作就是将原型及相关文档交付给开发团队进入到产品开发环节。这时，作为产品经理的你，终于可以稍微松一口气了。但是，并不是这以后的事情和自己没关系了！
作为一个产品，你应该是无所不能的，从产品、交互设计、开发到运营，所有的知识不能说精通但是都要略懂。这样一来，无论在创业公司需要一人兼多职还是在大公司与其他同事有良好的沟通、写作都是可以胜任的。
说到软件开发流程与管理，有很多堪称经典的书讲解得要深刻的多。在这里，笔者只是对常用的软件开发流程进行大致的介绍，但具体到各个公司不同的开发团队应用的具体方法还会有所不同。在此，希望各位通过对基本的了解，在进入公司后才能够尽快与开发团队达成默契。
瀑布模型
瀑布模型是1970年由温斯顿·罗伊斯提出的软件开发模型，直到80年代早期还在软件开发界被人们所沿用。
瀑布模型的核心思想是按照工序将问题分阶段化简，将功能的实现与设计分开，采用结构化的分析与设计方法将逻辑实现与物理实现相分离。它将软件的生命周期分为：制定计划、需求分析、软件设计、程序编写、软件测试和运行维护六个阶段，并规定了它们自上而下的固定顺序，如同瀑布一样落下。
瀑布模型的优点：
明确了不同阶段的任务目标
可以分阶段检验阶段进度
当前一阶段任务完成后，只需关注后续阶段任务（这同时也是一个缺点）
瀑布模型的缺点：
在阶段间极少有反馈
只有在项目最后阶段才能看到项目效果
无法适应需求的变化，因为需求阶段一旦完成就不会再又变动
通过瀑布模型的缺点可以发现，这和互联网时代的产品设计理念有很大的冲突。因为瀑布模型后一个阶段必须在前一个阶段完成后才会开始，这让需求的变动变成了不可能。但是在互联网时代用户的需求变化速度是很快的，产品从开发到最终发布的过程中要面对需求频繁变化的可能性。为了适应用户不断变化的需求以及产品的快速开发发布，诞生了敏捷开发模型。
敏捷开发模型
敏捷开发是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发模型。敏捷开发强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重做为软件开发中人的作用。
不同的公司或不同的开发团队所遵循的敏捷开发方式可能会有所差异，但是它的本质都是为了增加人与人间的沟通以及频繁交付软件版本，不断的开发与更新符合用户需求的软件。
敏捷开发是一种软件开发模型，根据这种思维方式衍生出了很多种具体的敏捷开发实现方法，这其中极限编程XP和Scrum是实际开发过程当中经常使用的两种实现方法。这里只介绍其中的一种：Scrum。
Scrum
Scrum一词来自英式橄榄球运动，本质含义就是一群人你推我搡地去抢球和控球。用球赛来类比确实是一个形象又合适的比喻，在赛场上尽管队员们努力按照既定计 划推进，但是场上瞬息万变，不可能实时按照教练或者队长的指令亦步亦趋的去行事，只能靠平时训练中形成的素养见机行事，达成目标。
Scrum的核心思想是首先承认我们的用户并不清楚自己的需求，并且人类的需求会不断变化的，所以我们默认需求是变化的需求，并且制定一套策略对小功能快速开发，通过后续不断迭代完善产品。
Scrum三大角色
产品经理：产品功能和需求的确定者，明确产品不同版本需要实现的功能。
流程管理员：负责整个Scrum流程的顺利实施，项目经理的角色。
开发团队：负责产品的开发工作，不同的开发成员负责不同的模块或功能，通过协作完成整体任务的完成。
Scrum开发模型
产品经理根据用户需求以及产品设计制定产品需求列表
开发团队对需求进行工作量和时间评估，并和产品经理共同制定一个迭代周期内需要实现的需求列表。
开发团队进入开发迭代周期（根据实际情况设定周期在1-4周）进行产品开发，在开发过程中会有每日站立会成员间对开发中遇到的问题进行讨论，开发成员对各自负责需求进度进行更新，共享整体工作信息。
每一个迭代周期结束时都要保证输出一个可发布版本，所有团队成员进行回顾会议，对迭代周期中遇到的所有状况进行回顾，吸取经验教训，为下一个迭代周期的工作做准备。
总结
产品初期设计完成后，从研发阶段到后续版本频繁迭代升级，每一次的变动都少不了和研发团队打交道的机会。通过产品的视角去看待产品敏捷开发全流程，在与研发团队沟通过程中可以更好地站在对方角度思考问题，减少＂撕＂的几率，提高产品研发、迭代效率，打造更好的产品。