瀑布流开发模式
benifits
- 标准化，流水线
- 分工、协作
- 质量保证
drawbacks
- 对于中大型需求，因为复杂，导致很难轻易的深入细节和分支，需要耗费较大的人力、时间成本
- 对于中大型需求，因为功能复杂，时间跨度大
- 产品设计跟不上市场需求的可能性更大
- 需求变更的成本高（而且越到后期 代价越大）
- 甚至有些方向性的调整 导致产品流产，无法及时的止损
- 在传统流程中，部分的流程是串行的
- 比如 产品同学在产品调研、产品方案设计的时候，研发、测试同学基本上是无法参与太多的
- 这个时候一般也没法开始其他的中大型需求，否则可能导致人员占用，无法及时支持原来的需求
- 直到提测阶段，才能看到“成果“（一个完整的、功能齐全的产品）
核心根本问题，其实是中大型需求复杂度高，周期长。
- 因为复杂度高，需求难以明确（客户很多时候也不知道想要什么，更何况在没有直接客户需求，依赖”猜测“）
- 因为复杂度高，各个环节出现漏洞的可能性增加
- 产品流程缺失、冲突、不符合用户习惯
- 技术方案不全面
- ... 对各个团队的主要负责人的个人能力和行业经验有更强的依赖性。
- 因为复杂度高，各个环节需要的周期就会长，而且有些时候 还不是能单纯的靠加人能搞定的
- 复杂度高，周期长，及时响应需求变化（市场的、老板的...）的能力差，也无法及时止损。
- 因为复杂，相互之间的影响大，调整难度大，
- 排期2个月，开发一半了，市场变了，热度过去了，政策变化了...(排期2周，干了一半，调整方向，都能及时止损)
- 因为整个周期长，无法灵活调整（市场不等人，上线时间不能再晚了）
- 开发了1/3了，为了应对市场变化，调整个需求，但是排期要保障
- 先压缩测试时间，再尝试压缩开发时间
- 最终由于时间紧张，影响点没考虑全面，技术方案没想完善，导致上线之后质量也不够理想
其他的开发模式
快速原型开发模式
- 常用于针对需求不明确的客户需求
- 先开发一个简陋的原型版本，收集客户反馈
- 因为不是最终交付版本，所以注重功能实现，不关注性能、安全性等
模块拆分|增量迭代-瀑布模式拆分
既然大瀑布模式的问题是复杂度高， 周期长，那么就拆分成独立模块，按模块交付或者按照。
模块拆分： 举例来说，可以将一个产品的不同页面独立交付，比如首页、详情页；但是这个时候可能还不是一个完整的产品，无法上线。
增量迭代 可以先将部分非必须的功能和页面放到之后的版本迭代中完成，就是我们经常看到的拆分需求；这种模式下的每一个版本交付都是可以独立上线的。
以上两种适用于不同的业务情况，一般如果能使用增量迭代，则优先使用增量迭代，因为交付的一般是一个完整、可用的产品
但是增量迭代麻烦的是，
- 不是每一个需求都能拆分成不同的独立可交付版本
- 及时能拆分出可交付版本，但是这个版本不一定能够满足周期尽可能短（比如小于2周）的要求
敏捷开发
不可能三角理论
时间、质量、功能范围三者不能同时兼顾，类似区块链中的安全、去中心化、效率/性能的问题
针对瀑布式的中大型需求开发模式的问题，必须去牺牲一个的话，其实也没有别的太多选择，只能对功能范围进行取舍。
敏捷宣言
- 更强调个人主观能动性和团队配合
- 拥抱变化，用户需求优先
所以敏捷开发在强调更加发挥人的主观性和及时沟通，快速的明确用户最新的需求，迅速的交付包含用户最期望的功能特性的产品，同时能够及时调整产品方向适应市场变化。
敏捷开发常见流程
敏捷开发 vs 迭代 vs 增量
敏捷开发适应的场景
- 实际开发过程中，往往技术的不确定性其实比较少，往往更多的是需求的变化
- 同时需要注意的是 需求的变化应该是由市场的变化或用户需求的变化、明确、或者公司整体战略架构变化导致的
