1. 软件生命周期
软件开发模式无论是瀑布模型还是迭代模型，核心阶段和角色同样是存在的，只是每个阶段的周期和工作内容上有些许的差异。
1.1. 产品 MVP
在项目早期，更多的是一个 Idear 想法，希望使用软件的方式来实现一个产品功能，提供服务或产生实际价值。
将想法转化成便于沟通交流汇报的产品时，最佳方案是提供产品的演示 Demo，这就是产品的 MVP （Minimum Viable Product –最简化可实行产品）。
MVP: MVP是一种产品理论，这个概念听起来复杂，不过你可以把它想像成是一部电影的剧情大纲，或是一部漫画的角色介绍。它的重点就是制作的成本要极低，但是却能展示最终产品的主要特色。
MVP 的功用就是让你拿来接触客户，从很早就根据客户的回馈来改进你的产品。典型的错误就是窝在家里做没人要的产品 ，却自以为很有进度。大家的经验是，使用者要的东西往往是非常容易做的，但是也是最容易被你忽略的，如果你不一开始就跟用户接触，就很难知道这些内幕。
MVP不是每个迭代做出产品功能的一部分，而是每次迭代都要交付一个可用的最小功能集合，这个集合的功能可以满足用户的基本需求，虽不完善但至少可用。然后逐次迭代做出满足客户预期的产品，直至最后完全满足客户需求。
1.1.1. 角色
在这个时期，更多的是以下几个角色
- 创始人
- 项目负责人
- 产品经理
1.1.2. 产出
- MVP
1.2. 产品设计
由于分工的不同，全站工程师毕竟是稀缺资源，不是普适性的资源认知。更多场景是
- 产品经理来规划产品功能，输出产品设计稿
- 设计师设计，输出产品原型
1.2.1. 角色
- 产品经理
- 设计师
1.2.2. 产出
- 产品设计稿
- 产品原型
1.3. 编码开发
有了明确的开发需求后，有软件开发工程师进行功能编码实现。
1.3.1. 角色
- 软件开发工程师
1.3.2. 产出
- 代码
- 可执行程序
1.4. 测试
编码的程序可能由于各种原因会出现一些不可预知的 BUG，发现 BUG 并反馈研发修复 BUG 是测试工程师主要工作内容
1.4.1. 角色
- 测试工程师
1.4.2. 产出
- 自动化测试
- 测试报告
1.5. 部署
当编码的程序经过测试验证符合一定的标准后，可以将程序安装部署到实际运行环境。
1.5.1. 角色
- 交付工程师
1.5.2. 产出
- 软件在环境安装并正常运行
1.6. 运维
在程序日常运行过程中，可能会由于硬件或其他原因导致服务
1.6.1. 角色
- 运维工程师
1.6.2. 产出
- 环境 SLA
1.7. 升级
产品由于 bug 和功能上调整，需要升级到新的目标版本。
1.7.1. 角色
- 运维工程师
- 升级工程师
1.7.2. 产生
- 环境升级到目标新版本