简介
以前学习项目管理的时候，对项目生命周期模型很感兴趣（瀑布型、V模型、敏捷型等），面对不同场景的项目，使用不同的方法应对也的确能提升不少效率，省下不少功夫。故此特整理一篇手记。
瀑布模型
瀑布型简单易懂，它非常适用于规模较小，周期较短，需求明确（很少变更）的项目。
大体流程
| 阶段 | 主要活动 | 输出 |
|---|---|---|
| 需求分析 | 收集需求，分析用户需求，编写需求文档 | 需求规格说明书 |
| 设计 | 系统架构设计，详细设计，编写设计文档 | 设计文档 |
| 实现 | 编码，单元测试 | 源代码，单元测试报告 |
| 测试 | 集成测试，系统测试，用户验收测试 | 测试报告，用户验收结果 |
| 部署 | 部署系统，培训用户 | 部署文档，用户培训材料 |
| 维护 | 处理用户反馈，修复缺陷，进行系统更新 | 维护记录，更新文档 |
每个阶段完成了才向下移动到下一个阶段，通常也不允许返回上一个阶段。属于一种线性模式。
外接项目时，我还挺喜欢用这种模式的，跟客户一开始就明确好项目目标，把职责，权力，成本，质量，范围，时间全写清楚，后面就不用拉拉扯扯踢皮球
举例
假设我们要建造一栋房子
需求分析:
首先，需要明确房子的需求，比如：
-
房子需要多少房间？
-
每个房间的用途是什么？
-
房子的位置、风格等。
和顾客详细讨论需求，最终确定了房子的设计要求和规格
设计:
开始绘制房子的设计图，包括平面图、立面图等。详细说明房子的结构、房间布局、材料使用等。并根据顾客的修改意见做出调整，最终确定设计方案。
实现:
在设计方案确定后，施工团队开始准备材料和设备。并严格按照设计图纸开始建造房子，从地基开始，到墙体、屋顶、内部装修等。
测试和验收:
和顾客检查房子的各个部分是否符合设计要求，比如房间尺寸是否准确、管道系统是否正常工作等。如有偏差，进行必要的修改和调整，确保符合预期。
维护:
当客户终于验收完成这套房子后，后续如果有一些小问题，我们依然需要处理，比如修理门把手、调整灯光等。
--------分割线----------
V模型
V模型跟瀑布型一样，适用于需求明确，变更不频繁的情况，只是相比于瀑布型，多了强调开发和测试同等重要的思想。
大体流程
| 阶段 | 主要活动 | 输出 |
|---|---|---|
| 需求分析 | 收集需求，分析用户需求，编写需求文档 | 需求规格说明书 |
| 系统设计 | 系统架构设计，详细设计，编写设计文档 | 设计文档 |
| 模块设计 | 设计各模块的具体功能 | 模块设计文档 |
| 实现 | 编码，单元测试 | 源代码，单元测试报告 |
| 集成测试 | 各模块集成后进行测试 | 集成测试报告 |
| 系统测试 | 整体系统功能测试 | 系统测试报告 |
| 验收测试 | 用户验收测试，确认系统满足需求 | 用户验收结果 |
| 部署 | 部署系统，培训用户 | 部署文档，用户培训材料 |
| 维护 | 处理用户反馈，修复缺陷，进行系统更新 | 维护记录，更新文档 |
V体现在哪里，这样看你就懂了
举例
假设我们在建一栋房子
需求分析:
首先，需要明确房子的需求，比如：
-
房子需要多少房间？
-
每个房间的用途是什么？
-
房子的位置、风格等。
和顾客详细讨论需求，最终确定了房子的设计要求和规格
系统设计:
根据需求进行房屋的整体设计，绘制平面图和立面图
模块设计:
具体设计各个模块，例如基础、墙体、屋顶、电气布线和管道系统
实现:
实际建造房屋，包括挖掘、浇筑基础、搭建墙体和屋顶、进行内部装修。
单元测试:
检查每个模块的功能，例如电气系统是否正常，管道是否通畅。
集成测试:
测试各个系统的集成效果，如水、电、气的配合是否正常。
系统测试:
进行整体测试，包括安全性和功能性，确保房屋符合建筑标准。
验收测试:
业主检查房屋，确认其满足所有需求并进行验收。
部署:
正式交付房屋，提供使用说明和维护指导。
维护:
处理业主的反馈，进行必要的维修和定期检查，确保房屋的长期使用。
--------分割线----------
原型化模型
原型化模型就跟前两个相反了，首要是建造一个快速响应原型，实现客户对系统的交互，经过和用户对原型的讨论和交流，以便弄清楚客户真正需要的是什么，非常适用于用户需求定义不清楚，计划反复修改的情形。
大体流程
| 阶段 | 主要活动 | 输出 |
|---|---|---|
| 需求分析 | 与客户沟通，了解初步需求和期望 | 需求概述文档 |
| 原型设计 | 创建低保真或高保真的原型，展示界面和功能 | 原型 |
| 原型评审 | 与客户进行原型演示，收集反馈 | 反馈记录 |
| 需求调整 | 根据反馈调整需求，修改原型 | 更新的需求文档，改进的原型 |
| 原型设计 | 创建低保真或高保真的原型，展示界面和功能 | 新的原型 |
| 原型迭代 | 重复原型设计和评审过程，逐步完善原型 | 最终原型 |
| 实现 | 根据最终原型进行开发，实现功能 | 完成的系统 |
| 测试 | 进行系统测试，确保功能符合原型 | 测试报告，用户验收结果 |
| 部署 | 部署系统，培训用户 | 部署文档，用户培训材料 |
| 维护 | 后续的支持和维护 | 维护记录，更新文档 |
举例
依然假设我们在建一栋房子
需求分析:
首先，了解客户对房子的期望，比如：
-
房子需要多少房间？
-
每个房间的用途是什么？
-
房子的位置、风格？
形成初步需求文档:
比如 至少五间卧室，开放式厨房和客厅，两个卫生间
原型设计：
创建低保真原型或高保真原型，帮助客户更直观地理解设计
原型评审：
向客户展示设计原型，讨论布局、功能等，并收集意见
需求调整:
根据业主反馈调整需求，比如增加新的房间、调整空间大小。
修改原型：
根据客户新的需求和建议，重新设计原型。
原型迭代：
不断重复原型设计和评审过程，直至原型趋于完善。
开发:
根据最终原型施工
测试:
在各个施工阶段进行质量检查，确保符合设计规范和安全标准。
最后进行业主的验收测试，确保所有设计和功能符合预期。
部署：
正式将房屋交付给业主
维护:
定期处理业主的反馈，进行必要的维修和定期检查
Tips:有时候做项目，很可能是客户自己都没想明白自己要的是什么，N次修改原型后，终于盼来一句：“那就先按这个做吧”。但是在听到具体报价后，也许就不了了之了，相当于设计原型这流程都是打水漂的，可能得话，还是要跟客户提前说清楚，设计原型的成本也是要算的，不然就免谈。
--------分割线----------
增量模型
增量型就像是拼图，强调的是渐进增加产品功能的一系列迭代来产出可交付成果。最后一次迭代完成后，可交付成果才是完整的。适用于周期短、项目规模大的情形。
大体流程
| 阶段 | 主要活动 | 输出 |
|---|---|---|
| 需求分析 | 与客户沟通，收集需求和期望 | 需求功能文档 |
| 规划 | 制定项目计划，确定各增量的开发范围和时间 | 项目计划文档 |
| 增量设计 | 针对每个增量进行详细设计 | 各个增量设计文档 |
| 增量开发 | 编码实现每个增量的功能 | 完成的增量（可运行的软件部分） |
| 增量测试 | 对每个增量进行测试，确保功能正常 | 测试报告 |
| 客户评审 | 演示每个增量功能给客户，收集反馈 | 客户反馈记录 |
| 需求调整 | 根据客户反馈调整后续增量的需求 | 更新的需求文档 |
| 迭代 | 重复增量设计、开发、测试和评审的过程 | 完整的系统（所有增量系统的集合） |
| 部署 | 部署系统，培训用户 | 部署文档，用户培训材料 |
| 维护 | 后续的支持和维护 | 维护记录，更新文档 |
举例
以电商购物为例更好懂
需求分析:
开发一个新的在线购物网站，需求包括：
-
用户能够浏览商品。
-
用户能够将商品添加到购物车。
-
用户能够完成支付。
规划:
制定项目计划，确定每个增量的开发范围、目标和时间线
增量1：用户账户管理:
用户可以通过短信、微信等创建账户、登录。
交付和反馈:
将账户管理交付给客户，并收集客户对登录注册功能的反馈。
增量2：基本购物功能
开发网站的基础购物部分，比如
-
商品浏览功能：用户可以查看商品的列表和详细信息。
-
搜索功能：用户可以通过关键词搜索商品。
交付和反馈:
将商品浏览交付给客户，并收集客户对商品浏览功能的反馈。
增量3：购物车功能
开发可以将商品添加到购物车，查看购物车中的商品的功能。
交付和反馈:
将购物车功能交付给客户，使得用户可以在原有的商品浏览基础上，进行购物车操作。并收集客户对购物车功能的反馈。
增量4：支付功能
在之前交付的增量的基础上，开发支付购买功能。
交付和反馈:
将支付购买功能交付给客户，使得用户完成整个购物流程的购买。并收集客户对支付功能的反馈。
--------分割线----------
螺旋模型
螺旋模型则适用于强调风险分析，适用于庞大而复杂、高风险的系统。关键在于通过多个迭代周期不断改进项目。每个周期都包括规划、风险分析、工程和评审。
大体流程
| 阶段 | 主要活动 | 输出 |
|---|---|---|
| 规划 | 确定项目目标，识别项目范围和资源需求 | 项目计划文档 |
| 风险评估 | 识别潜在风险，分析风险影响和应对策略 | 风险管理计划 |
| 原型开发 | 开发初步原型，展示基本功能 | 原型系统 |
| 客户评审 | 演示原型给客户，收集反馈 | 客户反馈记录 |
| 需求调整 | 根据反馈调整需求，制定下一个迭代的计划 | 更新的需求文档 |
| 实施 | 开发下一个版本，增加新功能 | 完成的系统增量 |
| 测试 | 进行系统测试，验证新功能和修复缺陷 | 测试报告 |
| 部署 | 部署系统，培训用户 | 部署文档，用户培训材料 |
| 维护 | 后续的支持和维护 | 维护记录，更新文档 |
举例
以开发一个在线教育平台为例
规划:
-
目标确定：开发一款支持视频课程、在线测验和互动讨论的在线教育平台。
-
范围识别：初步确定用户注册、课程管理、视频播放等核心功能。
-
资源需求：评估开发团队、技术栈、预算和时间框架。
风险评估:
-
风险识别：识别技术风险（如视频流延迟）、市场风险（竞争对手的功能）、法律风险（版权问题）。
-
风险分析：评估这些风险对项目成功的影响。
-
应对策略：制定缓解措施，比如选择成熟的视频处理技术和与法律顾问合作。
原型开发：
创建基本原型图，展示关键用户界面和交互流程。
客户评审：
向客户进行基本演示，收集客户对界面、功能和体验的反馈。
需求调整：
根据反馈调整功能，确认下一步迭代目标。
实施：
根据更新的需求，进行功能开发。
测试：
进行各项功能测试，确保所有功能正常工作。
部署：
将完成的新功能上线，确保平台可供用户使用，并对用户提供教程和培训。
维护:
定期收集用户的反馈，并进行问题修复和体验改进。
重复迭代：
随着用户需求的不断变化和新功能的添加，项目进入新的螺旋循环。再次进行规划、风险评估、原型开发、客户评审等步骤，不断完善和扩展平台。
--------分割线----------
迭代模型
迭代型的关键是项目早期就确定了项目范围，但是时间和成本却会随着团队对产品理解的不断深入而定期修改。适用于那些不能完整定义产品的所有需求、计划多期开发的、在开发早期需求可能有所变化的项目。
大体流程
| 阶段 | 主要活动 | 输出 |
|---|---|---|
| 需求收集 | 收集初步需求，明确项目目标 | 初步需求文档 |
| 设计 | 进行初步设计，确定系统架构和模块 | 初步设计文档 |
| 实施 | 开发初始版本，完成核心功能 | 初始可运行系统 |
| 测试 | 进行初步测试，验证核心功能 | 测试报告 |
| 评审 | 演示初始版本，收集用户反馈 | 用户反馈记录 |
| 需求调整 | 根据反馈调整需求，更新设计和开发计划 | 更新的需求文档，修改设计文档 |
| 迭代 | 重复设计、开发、测试和评审过程 | 改进的版本 |
| 发布 | 发布新版本，进行用户培训 | 发布文档，用户培训材料 |
| 维护 | 后续的支持和维护 | 维护记录，更新文档 |
举例
以开发一个TODO清单APP为例
初步规划:
初步需求包括：
-
用户能够创建任务。
-
用户能够查看任务列表。
-
用户能够设置任务的截止日期和提醒。
第一次迭代:
第一次迭代时，主要开发基本任务管理的功能
-
创建任务：用户可以添加新的任务。
-
查看任务列表：用户可以查看所有创建的任务。
测试： 对这些功能进行基本测试，确保任务创建和查看任务列表的功能正常。
反馈： 将这个初步版本的应用提供给一些用户使用，收集他们的反馈。用户可能会提出：
-
需要对任务进行分类（如工作、个人等）。
-
任务列表需要有排序功能（如按截止日期排序）。
第二次迭代:
根据反馈，在第二次迭代中，添加新的任务分类和排序功能：
-
任务分类：用户可以将任务分配到不同的类别。
-
排序功能：用户可以按截止日期对任务进行排序。
测试： 对新增功能进行测试，确保分类和排序功能正常工作。
反馈： 将更新后的应用再次交给用户使用，收集新的反馈。用户可能会提出：
-
希望能够设置任务的优先级（如高、中、低）。
-
需要提供任务的完成状态（如未完成、已完成）。
第三次迭代:
在第三次迭代中，添加优先级和任务状态功能：
-
任务优先级：用户可以为每个任务设置优先级。
-
完成状态：用户可以标记任务为已完成或未完成。
测试： 测试优先级和状态功能，确保这些功能符合用户的需求。
反馈： 再次将应用交给用户，收集反馈，看看这些新功能是否满足他们的需求。用户可能会提出：
-
希望能在任务中添加附件或备注。
-
希望应用能够提供数据统计功能（如已完成任务的统计）。
第四次迭代:
....
在迭代模型中，开发过程被分成多个小的迭代，每个迭代都包括设计、开发、测试和反馈的过程。
每个迭代都在前一个版本的基础上进行改进和扩展。让团队可以快速响应用户需求的变化，并持续改进产品的质量和功能。
和增量模型的区别
说白了迭代模型注重通过重复改进来逐步完善系统，而增量模型则强调通过逐步交付功能增量来构建完整的系统。增量就像拼图，一开始就大致确定了拼图的图像是什么，每次拼完一部分，最终完成所有拼图。迭代就像画画，一开始并不太确定最终要画成什么样子，在不断画画中前进调整。
--------分割线----------
敏捷模型
敏捷开发是一种迭代式增量软件开发方式，特点是较小增量，快速迭代，每次交付最有价值成果，适用于需求不确定，不断发展变化的项目。相当于吸收了增量和迭代两种模型的精髓。
大体流程
| 阶段 | 主要活动 | 输出 |
|---|---|---|
| 需求收集 | 与客户沟通，收集用户需求和功能期望 | 用户故事和需求文档 |
| 规划 | 确定迭代周期和优先级，制定迭代计划 | 迭代计划和优先级列表 |
| 迭代开发 | 在短周期内进行开发，完成用户故事 | 完成的增量功能 |
| 测试 | 进行单元测试和集成测试，确保功能正常 | 测试报告和缺陷记录 |
| 评审 | 演示完成的功能，收集客户反馈 | 客户反馈记录 |
| 迭代调整 | 根据反馈调整需求，规划下一个迭代 | 更新的需求文档和迭代计划 |
| 发布 | 部署完成的功能，进行用户培训 | 发布文档和用户培训材料 |
| 维护 | 后续的支持和维护 | 维护记录，更新文档 |
举例
以开发一个健康APP为例
需求收集:
与客户进行交流，收集他们的需求。
-
作为用户，我希望能够记录每日饮水量，以便保持健康。
-
作为用户，我希望能够查看我的健康数据趋势，方便进行健康管理。
-
作为用户，我希望能设置提醒。
规划：
确定迭代周期，制定迭代计划。
- 迭代1：实现基本的用户注册和登录功能。
- 迭代2：实现饮水量记录功能。
- 迭代3：实现健康数据趋势图功能。
- 迭代4：实现提醒功能。
迭代开发：
-
迭代1（两周）
-
开发用户注册和登录功能。
-
进行数据库设计，创建用户信息表。
-
-
迭代2（两周）
- 开发饮水量记录界面和功能，允许用户输入每日饮水量。
测试：
进行单元测试，集成测试，用户验收测试。
评审:
进行迭代评审会议，向客户演示已完成的功能（用户注册和饮水量记录），收集反馈。
迭代调整:
根据反馈调整需求，比如客户希望增加饮水量统计图功能，将其纳入下一个迭代计划，并更新需求文档，调整后续迭代优先级。
发布:
在每个迭代结束后，将新功能进行发布。并为用户提供手册和培训。
维护:
监测用户在使用过程中遇到的问题，定期收集反馈，并进行更新和问题修复。
下次迭代：
开始实现健康数据趋势图功能、饮水量统计功能等。
...
敏捷模型中，每个迭代都包含计划、开发、评审和回顾的阶段，在每个迭代中都交付可用的功能，并根据用户反馈不断改进，以适应不断变化的需求和优先级。
--------分割线----------
混合型生命周期模型
顾名思义，就是前面提到的瀑布型、迭代型、增量型、敏捷型不同类型的组合。这种情况下，项目周期往往充满了复杂性和多维性。需要在项目不同阶段采用不同的生命周期。
大体流程
| 阶段 | 主要活动 | 输出 | 模型 |
|---|---|---|---|
| 需求收集 | 收集用户需求，明确项目目标 | 初步需求文档 | |
| 初步设计 | 进行系统架构设计，确定技术栈和模块划分 | 初步设计文档 | 瀑布型 |
| 迭代开发 | 在短周期内进行开发，完成用户故事 | 完成的增量功能 | 增量型 |
| 测试 | 对每个增量进行功能测试和集成测试 | 测试报告和缺陷记录 | |
| 评审 | 向客户演示功能增量，收集反馈 | 客户反馈记录 | |
| 需求调整 | 根据反馈更新需求，规划后续开发 | 更新的需求文档 | 迭代型 |
| 完整系统开发 | 集成所有功能，进行系统级测试 | 完整的系统 | |
| 部署 | 系统上线，进行用户培训 | 部署文档，用户培训材料 | |
| 维护 | 后续的支持和维护 | 维护记录，更新文档 | 敏捷模型 |
通常能用混合型的项目，一个把控不好，项目范围就很难界定，最后很难验收，除非和客户达成了长期合作的关系，客户也舍得给钱。可能我经历的项目有限，对混合型是真的不太感冒。
举例
看过前面那么多例子，相信这里你们都可以自己举例了，嘿嘿。。。
