1.瀑布开发模式（Waterfall Development）
定义
是传统软件的开发模式，是一种线性、顺序式的软件开发方法，整个项目流程如同瀑布一样从上游依次流向下游。
开发流程：
- 需求分析
- 系统设计
- 编码实现
- 测试验证
- 上线部署
- 维护支持
分析
特点：
- 每个阶段严格区分、按顺序执行。
- 在进入下一个阶段前必须完成当前阶段。
- 通常适用于需求明确、变动少的项目（如银行、硬件、传统大型软件系统）。
优点：
- 过程清晰，管理和控制较容易。
- 文档充足，便于交接和后期维护。
缺点：
- 需求阶段一旦定下，很难修改。
- 客户需等到开发完成后才能看到产品。
- 不适合需求频繁变动的项目。
工具
- Microsoft Project 项目计划、甘特图
- WBS Schedule Pro 工作分解结构（WBS）图
- Excel 小型项目可用表格追踪进度与时间
2.敏捷开发模式（Agile Development）
定义：
敏捷是一种迭代式、增量式的软件开发方法，强调灵活应对变化、快速交付可工作的软件。
2001年，发表的《敏捷开发宣言》
4个重要的价值观 （Agile 4 Values）
- 个体和互动 高于 流程和工具
- 工作的软件 高于 详尽的文档
- 客户合作 高于 合同谈判
- 响应变化 高于 遵循计划
尽管右项有其价值，我们更重视左项的价值。
12 条原则（Agile 12 Principles）
- 我们的最高目标是通过早期和持续交付有价值的软件来满足客户。
- 欢迎需求变化，即使在开发后期也可变更，敏捷流程能利用变化为客户创造竞争优势。
- 频繁交付可工作的软件，周期从几周到几个月不等，越短越好。
- 业务人员和开发人员必须天天在一起工作。
- 以有动力的个人为核心，构建项目。给予他们所需的环境与支持，并信任他们完成工作。
- 团队内部最有效的信息传达方式是面对面交流。
- 工作的软件是衡量进度的主要指标。
- 敏捷过程促进可持续开发。团队应保持稳定的开发节奏（持续交付而不崩溃）。
- 持续关注技术卓越和良好的设计有助于敏捷性。
- 简洁——即尽可能减少不必要工作的艺术——是基本原则。
- 最佳架构、需求和设计源自自组织团队。
- 团队定期反思如何提高效率，并相应调整行为。
开发流程：
- 将项目切分为多个短周期（Sprint，通常为1~4周）
- 每个周期都包括：计划 → 设计 → 开发 → 测试 → 评审 → 回顾
- 不断迭代，直到产品完成
分析
特点：
- 强调与客户的频繁沟通与反馈。
- 快速交付 MVP（最小可行产品）。
- 高度响应变化，支持需求不断调整。
优点：
- 更快看到成果，更容易发现问题并修正。
- 用户参与度高，满意度更高。
- 适合不确定性高、需要灵活性的项目（如互联网产品、初创项目）。
缺点：
- 对团队协作和自组织能力要求高。
- 文档可能较少，依赖团队知识传承。
- 不当管理容易导致方向频繁变更，缺乏长远规划。
工具
- Jira（敏捷模板） 敏捷看板、Sprint管理
- Trello 看板协作
Scrum
Scrum 是一种敏捷开发框架，强调小团队协作、快速迭代、持续交付和持续反馈。
它以「经验驱动」为核心，即：你不可能一开始就知道所有的需求，所以你需要边做边优化。
核心理念
- 以**迭代式开发（Sprint）**推进项目
- 每个迭代周期都能交付一个可运行的产品版本
- 强调跨职能团队与高频沟通
- 鼓励团队自组织、自驱动
组成部分
1. 团队角色（3种角色）
| 角色 | 职责 |
|---|---|
| 产品负责人（Product Owner） | 负责定义产品需求（Product Backlog），按优先级排列任务，代表用户/业务 |
| Scrum Master | 类似项目协调者，保证 Scrum 流程顺利进行，移除障碍 |
| 开发团队（Developers） | 实际开发人员（包括前端、后端、测试等），负责将需求转化为可交付产品 |
2. 事件（5个核心会议）
| 事件 | 说明 |
|---|---|
| Sprint | 固定周期（通常1~4周）的迭代周期，输出一个可交付产品 |
| Sprint Planning（计划会） | 每个 Sprint 开始前，团队讨论要完成哪些任务 |
| Daily Scrum（每日站会） | 每天15分钟同步：昨天做了啥，今天做啥，有没问题 |
| Sprint Review（评审会） | Sprint 结束后展示成果，获取反馈 |
| Sprint Retrospective（回顾会） | 复盘团队过程，优化团队协作、工具、效率等 |
3. 工件（3个核心产物）
| 工件 | 说明 |
|---|---|
| Product Backlog | 产品待办事项列表，由 PO 维护 |
| Sprint Backlog | 当前迭代选定要完成的任务列表，由开发团队维护 |
| 增量（Increment） | 本次迭代完成的功能成果，必须可用且可交付 |
工作流程
- Product Owner 创建 Product Backlog（需求列表）。
- Sprint 计划会：团队选择任务，制定 Sprint 目标。
- 每日站会：团队同步进度，解决问题。
- 开发 & 测试：团队完成 Sprint Backlog 中的任务。
- Sprint 评审会：演示增量，收集反馈。
- Sprint 回顾会：总结改进点，优化流程。
- 进入下一个 Sprint，循环往复。
瀑布开发 and 敏捷开发对比
| 维度 | 瀑布流开发 | 敏捷开发 |
|---|---|---|
| 项目流程 | 严格线性、阶段性 | 迭代式、灵活 |
| 需求变更 | 不易接受变更 | 容易适应频繁变更 |
| 用户参与 | 初期沟通后较少参与 | 全程频繁参与和反馈 |
| 交付时间 | 一次性交付最终产品 | 快速交付多个可用版本 |
| 管理风格 | 自上而下 | 自组织、自驱动 |
| 文档需求 | 文档充分 | 更侧重交流与协作 |
| 适用场景 | 需求清晰、流程稳定的大型项目 | 不确定性高、需求变化频繁的项目 |
