1. 敏捷开发-简介
敏捷开发（Agile Development）是一种以「迭代」为核心的软件开发方式。
在敏捷开发中，一个项目不会被一次性规划到最终形态，而是被拆分为多个短周期的迭代（Iteration），每个迭代周期都是一个完整的开发周期，都具备需求、设计、研发、测试、部署等过程，项目会再持续迭代中不断完善。
2. 敏捷开发-背景
敏捷开发诞生的背景是因为在实际项目中，常常会遇到以下问题：
- 需求在项目推进过程中频繁调整
- 用户在早期阶段难以准确描述真实需求
- 市场与业务节奏变化迅速
- 一次性整体交付的失败成本较高
由于这些挑战，传统的瀑布式开发模式往往难以适应复杂多变的项目环境。敏捷开发正是在这种背景下提出的，旨在通过更灵活、更响应变化的方式来进行软件开发。
3. 敏捷开发-核心特征
3.1 增量迭代式开发
- 将整体研发过程拆分为多个短周期迭代
- 每个迭代都会在现有基础上交付 可运行的功能增量
- 产品始终保持在「可使用、可交付」的状态
不追求一次性完成全部功能，而是通过持续迭代不断演进。
3.2 重视客户协作与持续反馈
- 客户或用户会持续参与到项目迭代过程中
- 每个迭代结束后，都会对阶段性成果进行评审
- 基于真实使用反馈，动态调整后续迭代的优先级
在敏捷开发中，客户不仅是验收方，更是持续参与决策的一方。
3.3 快速响应变化
- 能够灵活应对需求、技术及业务方向的调整
- 允许在项目推进过程中对方案进行修正
- 不强依赖项目初期即“完全确定”的需求文档
变化被视为项目推进中的常态，而非需要刻意规避的异常。
4. 敏捷开发-典型迭代流程
一个典型的敏捷项目，通常不会在项目初期就定义完整的产品形态，而是通过 多轮短周期迭代，在持续交付中逐步降低不确定性、完善产品。
4.1 第一轮迭代（MVP / 可行性验证）
这一阶段的核心目标并不是功能完整，而是验证方向是否可行。在这一轮迭代中，通常会：
- 搭建基础技术框架与整体架构
- 验证关键技术方案是否能够落地
- 实现最小可用功能，用于内部或早期用户验证
4.2 第二轮迭代（核心能力构建）
在方向得到初步验证后，项目进入核心能力建设阶段。这一阶段的重点在于：
- 完善系统的核心业务功能
- 打通主要业务流程，形成完整闭环
- 构建相对稳定的产品主干结构
4.3 第三轮迭代（体验与稳定性优化）
当核心功能基本可用后，项目的关注点会逐步转向体验与质量。这一阶段主要包括：
- 优化用户交互流程与使用体验
- 修复前期迭代中暴露的问题
- 提升系统的稳定性与性能表现
4.4 后续迭代（持续交付与演进）
当产品进入相对稳定阶段后，迭代将成为一种常态化行为。后续迭代通常会围绕：
- 持续交付新功能与改进点
- 根据用户反馈动态调整功能优先级
- 通过小步快跑的方式避免一次性大规模改动
5. 敏捷开发-案例（在线宠物医院 App 的持续演进）
5.1 项目背景
项目最初的目标非常聚焦：
- 打造一款 在线宠物医院App
- 核心功能：
- 帮助用户快速匹配附近的宠物医院
- 支持在线问诊，解决基础咨询问题
在项目启动阶段，产品定位清晰，功能范围也相对有限。
5.2 第一阶段：解决核心问题（最小可用版本）
在第一轮迭代中，产品只需要满足最核心的用户需求：
- 基于地理位置的宠物医院匹配能力
- 在线问诊的基础流程
- 用户与商家之间的基础交互能力
产品在小范围用户中上线，用于验证 “用户是否真的需要这样一款产品”。
5.3 第二阶段：围绕核心功能的自然扩展
随着产品逐步投入使用，新的需求开始出现：
- 用户希望能记录宠物的健康情况
- 问诊过程中需要长期查看宠物历史信息
基于这些反馈，产品在后续迭代中引入了 宠物日志模块：
- 记录宠物的健康、疫苗、就诊等信息
- 为在线问诊提供更完整的上下文
产品能力在不改变核心定位的前提下，得到了自然扩展。
5.4 第三阶段：用户行为驱动产品方向变化
随着宠物日志功能的持续使用，产品团队发现了新的趋势：
- 用户开始主动分享宠物的日常记录
- 宠物日志逐渐演变为内容分享载体
- 用户之间产生了互动需求
在这一阶段，产品开始向 宠物社区 方向演进：
- 支持宠物日志的公开与互动
- 引入基础的点赞、评论等社区能力
- 强化用户之间的连接关系
产品形态开始从「工具型应用」向「社区型产品」转变。
5.5 第四阶段：规模增长后的能力扩展
随着用户规模不断扩大，产品进入新的发展阶段：
- 注册用户数持续增长
- 用户活跃度和留存率显著提升
在此基础上，产品在后续迭代中逐步引入：
- 宠物相关商品的商城功能
- 与宠物医院、品牌方的商业合作能力
这些能力并不是一开始就规划好的，而是在用户规模和使用场景成熟后自然演进出来的。
5.6 案例小结
这个案例体现了敏捷开发的几个关键特点：
- 产品始终围绕当前最核心的问题迭代
- 新功能来源于真实用户行为与反馈
- 产品方向并非一次性确定，而是在演进中逐步清晰
从 在线问诊工具 到 宠物健康管理平台 再到 宠物社区与商业平台，整个过程都是在同一个产品、同一个项目中，通过持续迭代逐步完成的。
6. 敏捷开发-优缺点
6.1 优点
- 适应变化能力强：通过短周期迭代与持续反馈，能够快速调整方向，降低需求变化带来的风险。
- 用户参与度高，需求理解更准确：用户在开发过程中持续参与，有助于减少“做完才发现不是想要的”情况。
- 问题暴露早，修复成本低：每个迭代周期都包含测试与回顾，问题可以在早期被发现并修正。
- 产品质量可持续提升： 通过频繁的测试、回顾与优化，产品质量不是一次性保障，而是持续演进。
6.2 缺点
- 对团队整体能力要求较高：敏捷开发强调快速响应与持续交付，如果团队经验不足，容易出现质量和节奏问题。
- 沟通成本较高：频繁的会议、评审和需求讨论，是敏捷开发不可避免的一部分，需要持续投入时间与精力。
- 缺乏整体把控时，容易偏离方向：如果没有清晰的产品目标和优先级管理，容易出现需求膨胀或功能冗余。
- 文档维护容易被忽视：敏捷并不等于不写文档，但在实际执行中，文档常常被延后或更新不及时，增加后期维护成本。
7. 敏捷开发-适用场景
敏捷开发并非适用于所有项目，更适合具备以下特征的场景：
- 需求存在较大不确定性：项目初期无法明确所有细节，需要在实际使用中不断调整。
- 需要尽快交付可用成果：希望通过早期版本验证市场或业务方向，而不是等待完整交付。
- 用户或业务方愿意持续参与：能够定期提供反馈，并参与需求优先级的讨论。
- 项目规模可拆分为多个迭代：功能可以分阶段实现，而不是必须一次性完成。
- 团队具备一定工程经验和自驱能力：成员能够在相对灵活的环境中保持质量和节奏。
8. 敏捷开发 vs 瀑布开发
在实际项目中，敏捷开发与瀑布开发并不存在绝对的优劣之分。是需要结合项目的实际情况来选择合适的开发模式。
8.1 没有“最好的”，只有“合适的”
不同项目在以下方面往往存在巨大差异：
- 需求是否稳定
- 项目规模与复杂度
- 团队经验与成熟度
- 业务试错成本与交付节奏
在这些前提条件不同的情况下，很难用单一的开发模式覆盖所有场景。因此我们的关注点应该是 “哪种方式在当前阶段更合适”。
8.1.1 敏捷迭代周期与瀑布流程并不冲突
从工程实践角度看，在每一次敏捷迭代中，依然会完整经历：需求确认、设计、开发、测试、交付 ，只不过，这个过程被压缩到了一个较短的时间周期内，且交付的范围更小。
8.2 瀑布开发的价值
瀑布开发的价值，在于它清晰地定义了软件开发的完整过程：
- 每个阶段的目标是什么
- 阶段之间如何衔接
- 交付物应当具备哪些形式
正是因为瀑布模型对流程的明确划分，后续的开发模式才能在此基础上进行改进和扩展。从这个意义上说，瀑布开发可以被视为软件工程方法论中的基础模型。
8.3 现实项目往往是“混合模式”
在真实项目中，很少存在“纯敏捷”或“纯瀑布”的情况。
更常见的做法是：
- 在项目初期，采用更偏瀑布的方式明确整体方向
- 在功能开发阶段，引入敏捷迭代以应对变化
- 在系统稳定期，会再次收紧流程，强调规范与质量
不同阶段、不同项目，可能采用 不同程度的敏捷或瀑布策略。
8.4 项目经理的核心能力
一个合格的项目经理，并不是严格遵循某一种方法论，而是能够：
- 理解不同开发模式的适用边界
- 根据项目阶段灵活调整策略
- 在效率、质量和风险之间做出权衡
敏捷与瀑布只是两种最经典、最常见的开发模式代表，而不是必须二选一的标准答案。