大家好，新人第一次发文可能存在诸多问题求轻喷求轻喷，闲话不多说我们这就进入正题。相信大家都听过在开发过程中的“敏捷式开发与瀑布流的开发”，可是具体在实际工作过程中我们应该选用哪种方式呢？请大家来随我看看这其中的各种利弊…
一. 敏捷式开发的限制
目前已经有不少产品团体通过以“敏捷式开发”的方式去管理与完成自己的产品，尽管在我看来“敏捷式开发”有诸多优点，但是我们始终要谨记敏捷式开发的源头是定制软件服务，最早的敏捷开发诞生于1986年的日本；
所有流程的初衷也并非完全适用于用户产品软件开发，如果初创团队决定使用一套完整的敏捷式开发流程来完成自己产品的话，这个团队需有明确了解何为敏捷开发的人员；如若没有，那么整个团队将面临一些空前的磨难，只有经历不断忍过这些阵痛才能体会到“敏捷式开发”所带来的优势。
本本文仅列出需要敏捷开发过程中所注意的事项，如果大家想与我一起了解后续，会另开文章详细介绍如何组建一个真正的敏捷开发团队，具体的敏捷开发过程也需要根据公司的实际情况进行调整。
二. 在敏捷开发过程中的注意事项
我将其归类为8点：
1. 产品经理就是项目负责人
在敏捷开发过程中产品需要做好代表整个用户需求的作用，需要与开发团队保持密切沟通，及时解决开发过程中的问题，如果有些产品经理认为采用敏捷开发可以使工作变得更加轻松，那么就大错特错了。其实如果产品经理与项目负责人不是同一个人，通常会使整个产品留下非常严重的隐患，产品在整个敏捷开发过程中必须始终都要是第一责任人；
2. 使用敏捷方式不等于不做产品规划
使用敏捷开发的过程中产品仍需要明确定义整个产品的方向和目标，设定产品里程碑，只不过在敏捷迭代过程中所有的里程碑可以尽可能缩短其周期，通过使用反复迭代与轻量级的机会评估方法代替冗长的市场机会文档等纸面材料；
3. 产品经理与设计师的工作应领先团队1-2两个版本以上
为了确保在项目推进过程中有足够的时间攻克技术上的难题，需要让产品与交互设计和视觉设计师提前完成产品设计，充分发挥三者在产品设计过程中的主导作用，同时保证开发人员在产品设计与交互设计阶段始终处于参与状态及时反馈关于产品的可行性、成本与解决方案的建议在问题的出发点就将其解决；
4. 尽量把产品设计拆分成独立的部分
虽然将产品拆分成多个模块，但是也不能将其拆分的过于细碎，好比建造一座房子，你不能每次只建造一件房子，目标是设计出符合所有基本需求的产品，在这一过程中要求设计师需有更快的响应速度，去做经过市场验证后的调整；
5. 产品主要的工作是定义有价值、可用的产品原型作为产品基础
在敏捷开发过程中产品更需要注意，每次交付到技术同学手里的原型是经过测试与目标用户验证的，避免浪费任何资源，哪怕是一个开发迭代周期；
6. 让开发人员自主控制所有迭代周期
有的产品功能可以在一个迭代周期内完成，而有些需求确需要多个版本的迭代才能完成，而这些迭代周期应该尽可能的让技术同学去规划，产品只需把控最终的判断是否与规划相符合；
7. 除非达到预定目标否则绝不轻易发版
产品经理必须保证给到用户手中的产品是正常符合预期的，过度而过度频繁的更迭会让用户失去安全感，所以没有达到产品预期里程碑与阶段预期时绝不可妥协上线；
8. 每次迭代之后需向整个团队展示下个版本的需求设计与上个版本的数据回归
让大家看到工作成果可以极大的加深整个团队的信心，在敏捷开发过程中每一个产品即是一个小团队的领袖，产品经理需要让这个团队有更加积极的状态。
三. 瀑布式开发
传统瀑布式开发，至今为止应该已经有不少于30年的历史，瀑布式开发流程也分为正式流程与非正式流程，正式的瀑布式开发流程可以追溯到美国国防部软件开发标准2176A及后续修正的498，在网上有详细的阐述每一个阶段所需要提供的必要性文档，本文想说明重点在于非正式流程，也就是我们很多公司的开发流程；
非正式瀑布流程，也是目前很多互联网公司依旧在使用的方法：由市场/运营进行需求收集，交由产品对需求进行产出文档，统一进行研发和设计评审，评审之后由开发制制定开发计划、设计软件架构，由设计进行交互与视觉设计等细节设计，最后正式进入开发、测试与部署上线。
四. 瀑布开发的优劣
瀑布式开始是目前大多数团队仍然在使用的一套开发流程，虽然无论是开发还是产品同学都对其十分的不满，但其仍能在不断拥抱变化的互联网公司被推崇使用必定有其优势。所以在讨论瀑布式开发的局限性前，我们需要先聊下瀑布式开发的基本准则与优势
瀑布式开发的基本原则：
采用阶段式开发，即软件开发过程中分为固定几个阶段：完成需求文档、设计软件架构、完成交互细节、编写代码、测试、部署；
采用阶段式评审，每个阶段结束由上到下进行相应的评审，评审通过后进入下一阶段。
瀑布式开发的优势：
（1）对于管理层而言有可预测性，在理论上只要在产品评审阶段前将所有产品细节确认并完善，且不再更改需求，那开发团队就可以为超大型及复杂项目制定相应的开发计划，虽然不进行需求变更这种情况很少见，但是并非不能做到，相反迭代性开发的迭代次数无法预估，很难让管理者做到心中有数；
（2）在瀑布式开发过程中每个阶段都会由对应的负责人员提供相对完善翔实的文档及其他书面材料，这会让项目在开发过程中给人一种感觉，这些项目都经过了所有人的深思熟虑才会进行的相应推进，但是问题在于使用书面材料当作稳定剂多少都会有些靠不住，因为他并不能实际的在你面前演示。
瀑布式开发的劣势的劣势：
（1）产品验证滞后
产品验证滞后是瀑布式开发过程中最让产品头疼的部分，产品人员必须等到项目进程尾声的时候才可以对产品进行验证，也就是说在投入大量的人力物力之前所有的产品概念都是无法得到充分的验证的，验证滞后也意味着所有阶段不能出现任何纰漏否则将导致整体项目变得失控；
（2）需求变更困难
在瀑布式开发过程中，任何对之前决策的修改与调整都将打乱原本的开发流程，大量已完成工作需要重新评估与推进严重耗费整个团队的精力，产品经理在跟踪用户需求的过程中，难免会产生需求的变更，如果发生需求变更那修改需求必定在所难免，只是早晚的问题，而且延迟到下一个版本开发也只是一个权宜之计，无论从成本或是用户体验上考虑肯定都是越早改动越好；
（3）难以适应变幻的市场
瀑布式开发过程中的所有工作都严重依赖于流程与文档，任何一点改动都会牵一发而动全身，也使得产品经理压力倍增，产品经理在这一流程下提交给开发的所有产品必须确保通过严格的验证且没有缺陷，另一方面发布过后产品也会提心吊胆，随时做好快速线上修复的准备。
五. 实际推进项目过程中，我们该如何选择
在了解了瀑布式开发过程中的缺陷就不难理解为什么要改用各种敏捷开发，瀑布式开发流程过于理想化，需要人们在开始的时候就预见到所有的问题，全面的把握需求；最终实践证明，往往瀑布式开发只适用于规模很小的项目开发，对于大型项目来说，瀑布式开发就显得难以顺利推进且如果采用瀑布式开发，产品的交付时间通常都会比一开始所预计的时间晚，而且常常是产品上线后发现各种缺陷，产品与整个技术团队不得不花费更多的精力去进行修补。
通过这些说明，我也更希望文章前的你看到两种方式的局限性，并选择一个真的适合你团队的开发流程。
希望本文可以帮助那些还在犹豫的人，以后也会更多的深入各个问题进行探究~
