瀑布开发模式和敏捷开发模式
作者：互联网
转自：https://www.cnblogs.com/Raul2018/p/9375673.html
瀑布开发模式：
瀑布开发模式有以下显著的特点：
1.严格把软件项目的开发分隔成各个开发阶段：需求分析，要件定义，基本设计，详细设计，编码，单体测试，结合测试，系统测试等。
使用里程碑的方式，严格定义了各开发阶段的输入和输出。如果达不到要求的输出，下一阶段的工作就不展开。
2.重视和强调过程文档，在开发的中后期才会看到软件原型，早起只能通过文档来了解系统的模样。
在这种情况下，文档的重要性仿佛已经超过了代码的重要性。
3.瀑布模型把每个开发阶段都定义为黑盒，希望每个阶段的人员只关心自己阶段的工作，不需要关注其他阶段的工作。
好处是：可以让开发人员能够更专注于本职工作，提高阶段效率。
坏处是：
a.由于各阶段的开发人员只能接触到自己工作范围内的东西，所以对客户需求的理解程度高低不等，开发人员更像是定义为流水线上的工人。
b.对于客户需求变更，编码人员会比设计人员更容易产生很强的抵触情绪。
c.在每个开发阶段都会有一些信息刻意的不让其他开发阶段的人员知道（本意是为了提到效率，但实际上有时候产生的是互相的理解偏差）。
4.瀑布模型产生的管理文档(计划书，进度表)等，能让不太了解该项目的人也能看懂项目的进度情况（只有能看懂百分比就行），很适合向领导汇报用。所以管理人员比较喜欢瀑布模型，但是开发人员不喜欢，因为它束缚了开发人员的创造性。
5.既然叫做瀑布，就意味着不应该走回头路。否则如果出现返工，付出的代价会很大。
软件生命周期前期造成的Bug的影响比后期的大的多。
代价比较大的主要原因还是每个开发阶段的步子过大，每一次调整都可能伤筋动骨。
6.更适合需求相对稳定的大型项目。
敏捷开发模式：
核心是快速迭代，拥抱变化。
因为最终目标是让客户满意，所以能够主动接受需求变更，这就使设计出来的软件有灵活性，可扩展性。
宣言：
个体和交互 胜过 过程和工具
可以工作的软件 胜过 面面俱到的文档
客户合作 胜过 合同谈判
响应变化 胜过 遵循计划
敏捷开发模式有以下显著的特点：
1.story细化。
2.简单设计，避免过度设计。
3.重复迭代。
4.减少不必要的文档。
5.客户最关心的功能最先完成。
6.要求客户有时间对每次迭代的成果进行确认，提出改进意见。
7.showcase。
8.沟通是非常重要的，所有的开发人员对项目活动的理解应该是一致的。加强团队之间和客户之间的沟通。
9.测试驱动开发（TDD）
10.需要更强的个人和团队能力。
11.敏捷的管理是团队的自我管理和项目经理的服务式管理。
12.敏捷开发不能在一开始就给出项目完整的成本计划。
13.在有技术问题还没有解决的情况下不适合展开迭代。
14.敏捷实践：晨会，deadline，负责人制等等。
瀑布+敏捷开发模式：
核心是减小瀑布模型的粒度，采用敏捷开发的优秀实践方式，提高开发的沟通效率，提供项目的全景视图。
敏捷开发，首先把客户最关注的软件原型先做出来，交付或者上线，在实际场景中去修改弥补需求中的不足，快速修改，再次发布版本。再次上线或者交付。通过一些敏捷实践方式，细化story，可以提供更小的迭代。如此循环，直到用户（客户）满意。适用于需求不明确的项目、创新性的项目或者需要抢占市场的项目。 瀑布式开发，要求明确的需求，大家按照需求一步步做好规划，在项目运作过程中严格产出各种文档，按着流程一步步走下去。这种模式一般适用于需求比较明确、to B端项目 但总的来说，在现在管理项目过程中，并没有严格的按照完全的敏捷或者完全的瀑布模式，都是各自掺杂了其他的方式。在实际项目过程中，过于强调模式并没有意义，重要的是能不能预防问题的发生，在问题发生之后能不能用最小的成本解决，模式更多起一个参考作用 最后借用民国时候的一句话：少研究一些主义，多关注一些实际问题。 文章中部分内容是借鉴于其他文章。
标签：开发人员,模式,瀑布,开发,文档,敏捷,开发阶段 来源： https://www.cnblogs.com/sharpest/p/10482560.html