几种常用的软件生命周期模型与敏捷开发解读

瀑布式开发和敏捷开发，看过软件工程相关的书籍的同学，对瀑布模型，增量模型 ，喷泉模型，W模型，V模型以及H模型都是知道一些的，那么现在提到更多的敏捷开发它们之间有什么不同和适用的范围，是否敏捷开发适用于所有的开发模式？在实际的实践中又遇到了什么样的困难？平时各个团队的敏捷开发是敏捷开发吗？传统项目型开发是绝对要摒弃的呢？

比如：XXXX存管：需要与银行确定对接内容，保证符合监管要求
瀑布式开发【生命周期模型】，将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。严格产出各种文档，按着流程一步步走下去。这种模式一般适用于需求比较明确、toB项目

传统项目型开发：产品经理，需求分析师，研发负责人，测试负责人，项目经理 ，

1. 强调文档。所以产品经理（需求文档），需求分析师（需求说明文档），研发负责人（研发计划，项目研发日报），测试负责人（测试计划，项目测试日报）
2. 每个阶段有明显的界限。严格定义了各开发阶段的输入和输出；如果达不到要求的输出，下一个阶段不开展
3. 抵触变化。各个阶段的人员只接触到自己工作范围内的东西，所以客户需求的理解程度不一致，导致越到后面的人员对需求的变更越抵触
   4.管理模式:PMBOK的项目管理是自上而下的命令式管理,有意识的保持信息不透传。
4. 比较适合相对稳定的大型项目

缺点：
a.由于各阶段的开发人员只能接触到自己工作范围内的东西，所以对客户需求的理解程度高低不等，开发人员更像是定义为流水线上的工人。
b.对于客户需求变更，编码人员会比设计人员更容易产生很强的抵触情绪。
c.在每个开发阶段都会有一些信息刻意的不让其他开发阶段的人员知道（本意是为了提到效率，但实际上有时候产生的是互相的理解偏差）。

比如：减免需求：一期 完成申请；二期：完成对接账务
迭代式开发【生命周期模型】，在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：需求、分析设计、实施和测试工作流程。实质上，它类似小型的瀑布式项目。RUP认为，所有的阶段都可以细分为迭代。每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。
不要求每一个阶段的任务做的都是最完美的，而是明明知道还有很多不足的地方，却偏偏不去完善它，而是把主要功能先搭建起来为目的，以最短的时间，最少的损失先完成一个“不完美的成果物”直至提交。然后再通过客户或用户的反馈信息，在这个“不完美的成果物”上逐步进行完善。

传统的瀑布模型相比较，迭代过程具有以下优点：
1）降低了在一个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费。
2）降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙。
3）加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工作会更有效率。
4）由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的。因此，迭代过程这种模式使适应需求的变化会更容易些。
迭代模型缺点是：
在项目早期开发可能有所变化 ，需有一个高素质的项目管理者和一个高技术水平的开发团队。

比如：项目上线后的后期维护，已有项目的重构
增量模型【生命周期模型】该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的“增量”。客户对每一个增量的使用和评估都作为下一个增量发布的新特征和功能，这个过程在每一个增量发布后不断重复，直到产生了最终的完善产品。增量模型强调每一个增量均发布一个可操作的产品。
优点：
1)整个项目的资金不会被提前消耗，因为首先开发和交付了主要功能和高风险功能。
　　每个增量交付一个可操作的产品。
　　2)每次增量交付过程中获取的经验，有利于后面的改进，客户也有机会对建立好的模型作出反应。
　　3)采用连续增量的方式，可把用户经验融入到细化的产品，这比完全重新开发要便宜得多。
　　4)“分而治之”的策略，使问题分解成可管理的小部分，避免开发团队由于长时间的需求任务而感到泪丧。
　　5)通过同一个团队的工作来交付每个增量，保持所有团队处于工作状态，减少了员工的工作量，工作分布曲线通过项目中的时间阶段被拉平。
　　6)每次增量交付的结果，可以重新修订成本和进度的风险。
　　7)便于根据市场作出反应。
　　8)降低了失败和更改需求的风险。
　　9)更易于控制用户需求，因为每次曾两开发的时间很短。
　　10)由于不是一步跳到未来，所以用户能逐步适应新技术。
　　11)切实的项目进展，有利于进度控制。
　　12)风险分布到几个更小的增量中，而不是集中于一个大型开发中。
　　13)由于用户能够从早期的增量中了解系统，所以更加理解后面增量中的需求。
需要注意的地方：
　 1)良好的可扩展性架构设计，是增量开发成功的基础。
　　2)由于一些模块必须在另一个模块之前完成，所以必须定义良好的接口。
　　3)与完整的系统相比，增量方式正式的回顾和评审更难于实现，所以必须定义可行的过程。
　　4)要避免把难题往后推，首先完成的应该是高风险和重要的部分。
　　5)客户必须认识到总体成本不会更低。
　　6)分析阶段采用总体目标而不是完整的需求定义，可能不适应管理。
　　7)需要更加良好的计划和设计，管理必须注意动态分配工作，技术人员必须注意相关因素的变化。

项目：AI机器人
敏捷开发【项目管理方法集合】，首先把客户最关注的软件原型先做出来，交付或者上线，在实际场景中去修改弥补需求中的不足，快速修改，再次发布版本。再次上线或者交付。通过一些敏捷实践方式，细化story，可以提供更小的迭代。如此循环，直到用户（客户）满意。适用于需求不明确的项目、创新性的项目或者需要抢占市场的项目。

核心是迭代。

1. 客户合作胜过合同谈判，要求客户有时间对每次迭代的成果进行确认，提出改进意见。
2. 敏捷就是“快”。响应变化胜过遵循计划。因为最终目标是让客户满意，所以能够主动接受需求变更，这就使设计出来的软件有灵活性，可扩展性。
   3.迭代。客户最关心的功能最先完成，软件的功能是客户的需求，界面的操作是客户的“感觉”。对迭代的强调是缩短了软件版本的周期。
   4.沟通是非常重要的，所有的开发人员对项目活动的理解应该是一致的。开发团队：业务团队和技术团队；
   如果任何一方控制了沟通，那么项目注定会失败。
   如果业务一方控制，项目会议上就会不断的要求功能和交付日，而不太关心开发人员是否能够全部完成或开发人员是否明白他们的真正要求；如果开发人员控制了沟通，那么项目会议上技术术语会代替面向客户的业务语言，开发人员也失去了通过倾听来了解客户真正需求的机会。
   5.个体和交互胜过过程和工具。快才可以适应目前社会的快节奏，要快就要发挥个人的个性思维多一些个性思维的增多
   6.设计周密是为了最终软件的质量，但不表明设计比实现更重要。可以工作的软件 胜过 面面俱到的文档。 简单设计，重复迭代。减少不必要的文档。
   7.story细化，小版本。快速功能的展现，看似简单，但对于复杂的客户需求合理地分割与总体上的统一，要很好地二者兼顾是不容易的。
   8.需要更强的个人和团队能力。

缺点：
敏捷开发不能在一开始就给出项目的成本计划。
在有技术问题还没有解决的情况下不适合展开迭代.
因此敏捷方法更适用于较小的队伍，40、30、20、10人或者更少

但总的来说，在现在管理项目过程中，并没有严格的按照完全的敏捷或者完全的瀑布模式，都是各自掺杂了其他的方式。在实际项目过程中，过于强调模式并没有意义，重要的是能不能预防问题的发生，在问题发生之后能不能用最小的成本解决，模式更多起一个参考作用。