三、生存期模型
3.1 生存期模型选择
软件开发模型变迁： 作坊式–>过程控制–>敏捷–>DevOps等
从项目变化性和提交频率两个维度可将模型分为四个大类型：
- 预测型：提前进行大量的计划工作，然后一次性执行；执行是一个连续的过程。即预测模型是没有变更的。
- 迭代型(项目变化最高)：允许对未完成的工作进行反馈，从而改进和修改该工作。即迭代模型是通过不断反馈原型，改进产品。
- 增量型(提交频率最高)：向客户提供各个已经完成的，可能立即使用的可交付成果。即增量模型可以不断提供增量产品。
- 敏捷型：既有迭代也有增量，便于完善工作，频繁交付。
生存期的项目特征
| 方法(Approach) | 项目需求 | 开发活动 | 产品交付 | 目标 |
|---|---|---|---|---|
| 预测型(Predictive) | 稳定（Fixed） | 对整个项目执行一次 | 只提交一次 | 管理成本 |
| 迭代型（Iterative） | 不断变化的（Dynamic） | 不断重复直到正确 | 只提交一次 | 获得正确的解决方案 |
| 增量型（Incremental） | 不断变化的 | 每次增量活动只执行一次 | 多次提交小版本 | 速度 |
| 敏捷型（Agile） | 不断变化的 | 不断重复一些活动直到正确 | 多次提交小版本 | 获得用户肯定 |
没有哪个生存期模型能完美地适应所有的项目。
3.2、预测生存期模型
预测模型： 项目具有高确定性，有很明确的绣球，项目活动通常以顺序方式执行(无反馈)。
流程： Analyze(分析)–>Design(设计)–>Build–>Test–>Deliver
如瀑布模型，V模型。
瀑布模型
（优点：管理方便，缺点：项目可变性无法适应瀑布模型的要求）
适合瀑布模型的项目特征(需求很明确，方案很明确)
类似项目：短期项目等。
V模型
强调需求与测试的对应关系
适合V模型的项目特征(需求明确，方案明确)
类似项目：系统性能，安全等有严格要求等。
3.3、迭代生存期模型
迭代模型： 是通过连续的原型和概念验证来改进产品或结果，每一个新的原型都能带来新的相关反馈和团队的见解。
迭代模型有利于识别和减少项目的不确定性，也称为原型模型。(优点：可应对需求变化，缺点：时间长)
不断对部分完成或未完成的工作进行反馈，从而对该工作进行改进和修改。
原型模型（构造原型来应对需求和设计方案的不确定性的问题）
适合迭代模型的项目特征(需求不明确，项目复杂性高，项目变更频繁)。
3.4、增量生存期模型
增量模型： 一个增量一个增量的开发过程，每个增量是一个交付成果。即增量模型向客户提交完成的可交付的成功，让用户可以立即使用。
增量模型的策略： 是不同时开发项目的需求，而是分增量开发。
每一个增量都包括：分析，设计，实施，测试，提交等过程。
优点：
- 可以避免一次性投入太大带来的风险
- 阶段式提交一个可运行的产品
- 关键功能可以尽早出现
- 早期预警问题，避免缺陷蔓延
- 阶段性完成可降低估计失误(每个增量为后续增量提供评估基础)
敏捷生存期模型
前几种传统生存期模型在实际应用过程中遇到一些挑战，有时不能很好的适应快速需求的变化，为此软件界比较流行敏捷生存期模型。
敏捷模型结合了迭代和增量的方法，可以适应更频繁的变更和更频繁的交付。
传统软件开发更倾向于不考虑项目后期需求的变化，在项目开始时预测用户的需求，然后冻结需求，制定相应的开发计划，在按照计划执行，而计划和实际之间会存在一些差距，与之对应的是敏捷软件开发过程是不断的用户反馈，动态调整需求，最终达成目标。
初始需求可以很粗，但是要有优先级，每个迭代按照优先级来进行，从中选择部分内容进行迭代，每个迭代1-4周左右，迭代完成提交一个可运行的交付成果，进行评审反馈，然后继续下一个迭代。
敏捷方法是一个囊括了各种框架和方法的涵盖性术语。
Scrum模型是敏捷模型的代表。
2层的项目规划，迭代式的软件开发过程，4个管理会议。
2层的项目规划
- 体现为远期的项目计划和近期的计划，基于远粗近细的原则
- 远期计划和近期计划通过产品订单和冲刺订单体现
- 产品订单是所有需求的唯一来源，所有工作来自于它，开始阶段模糊，随着时间推移越来越明确。最高优先等级需求就是当前冲刺订单，冲刺订单是当前迭代完成的任务清单。
迭代式的开发
- 通过将整个软件交付过程分为多个迭代周期，一个迭代就是一个冲刺(Sprint)。
- 每个迭代周期2-4周，迭代内任务有详细的分解估算，可以分解到小时，迭代结束时提交一个运行版本。
4个管理会议
XP(eXtreme Programming) 极限编程模型
XP极限编程是由Kent Beck提出的一套针对业务需求和软件开发时间的规划。
13个最佳实践
- 整体实践：Whole Team，Customer Test，Small Releases(小版本)，Planing Game
- 开发团队实践：Collective Ownership，Coding Standard(编程标准)，Continuous Integration(持续集成)，Metaphor，Sustainable Pace(恒定速度)
- 开发者实践：Test Driven，Development，Pair Programming，Simple Design，Refactoring(重构)
精益模型(lean)： 提倡持续不断的改进，减少流程中浪费。
持续交付： 经典的敏捷软件开发延伸能够以较短周期完成需求的小粒度频繁交付。(持续集成，持续部署，持续交付)
- 持续集成：将个人代码像整体部分交付，以便尽早发现个人开发部分的问题
- 持续部署：集成的代码尽快向可运行的环境来交付，以便尽早测试
- 持续交付：尽快向客户交付以便尽早发现生产环境中存在的问题
由持续交付演变成DevOps(Development和Operations的组合)融合一系列基本原则和实践的方法论。
全程敏捷思维(开发段和运维端工作紧密合作)
开发人员与运维人员的差异：开发人员希望尽快提交产品，运维端希望产品更加合理化，高性能，高可靠性，减少运维成本。
DevOps： 是一组过程，方法与系统的统称，用于促进开发，技术运营和质量保障(QA)部门之间的沟通，协作与整合。