一、敏捷相关核心概念与实践
一、预测型（计划驱动型）生命周期
1. 特点与问题
| 特点 | 问题 |
|---|
| 需求必须明确，初期需收集详细需求 | 需求易变时需走变更流程，灵活性差 |
| 初期编写大量详细文档 | 文档维护成本高，可能与实际开发脱节 |
| 客户参与度低（需求收集后被动等待） | 需求理解偏差风险大，后期变更可能导致返工 |
| 需频繁汇报项目状态 | 沟通效率低，资源投入集中于汇报而非交付 |
| 价值仅项目结束时显现 | 高风险（市场变化可能导致成果过时） |
| 无法灵活应对市场变化 | 缺乏迭代反馈，难以快速调整方向 |
二、MVP（最小可行产品）
1. 定义与特点
- 定义：Minimum Viable Product（最小可行产品），指仅包含最基本功能但完全可用的简化版产品。
- 核心特点：
- 最小：聚焦核心需求（如早期微信仅支持发消息）。
- 可行：非半成品，能验证用户真实需求（可用且可收集反馈）。
2. 作用机制与优势
- 作用机制：交付MVP→获取用户反馈→快速迭代→最终稳定。
- 优势：快速验证目标、降低试错成本、灵活调整方向。
3. 常见应用场景
| 场景类型 | 说明 |
|---|
| 时间/预算严重不足 | 需快速占领市场（如初创公司验证商业模式） |
| 创新项目需市场反馈 | 不确定用户需求时（如新型社交产品） |
| 竞争对手已开发类似产品 | 抢占先机，通过反馈优化功能（如短视频APP早期版本） |
4. 经典案例
- 交通工具演进：滑板（基础功能）→带扶手滑板（优化）→自行车（稳定）→摩托车（升级），通过持续反馈调整方向，避免盲目开发不适用产品（如直接开发汽车可能偏离用户真实需求）。
三、STACEY矩阵（生命周期选择工具）
1. 判断维度与适用方法
| 维度 | 需求明确性 | 技术确定性 | 适用生命周期 |
|---|
| 低不确定性 | 明确 | 确定无风险 | 预测型（计划驱动） |
| 中等不确定性 | 较明确但需细化 | 部分风险 | 混合型（预测+敏捷） |
| 高不确定性 | 模糊或易变 | 技术不成熟/高风险 | 敏捷型（适应变化） |
2. 合同管理要点
- 需求不明确时，应采用工料合同（T&M）而非固定价格合同（FP），避免因需求变更导致成本超支。
四、混合型生命周期
1. 定义与典型场景
- 定义：同一项目中同时融合预测型与敏捷型方法。
- 典型场景：
- 研发+开发阶段：前期敏捷研发（探索需求）+后期预测开发（稳定落地）。
- 软硬件组合：硬件预测采购（标准化流程）+软件敏捷开发（快速迭代）。
2. 过渡优势与实施建议
- 过渡优势：允许组织逐步适应敏捷，降低方法论转换风险。
- 实施建议：
- 先在中低不确定性项目中尝试敏捷，积累经验。
- 通过混合模式实现渐进式过渡（如部分模块用敏捷，部分用预测）。
五、敏捷宣言与原则
1. 敏捷定义与核心能力
- 定义：敏捷是通过创造变化和响应变化，在不确定和混乱环境中取得成功的能力。
- 常见误解：敏捷≠“快”，本质是“适应”或“灵活”。
- 关键特征：强适应性，主动调整以应对环境变化。
2. 敏捷宣言四句话的理解
| 宣言内容 | 核心含义 | 实践意义 |
|---|
| 个体互动胜过流程和工具 | 重视团队直接沟通，而非依赖标准化流程 | 不过度依赖工具/流程，保持灵活性（如每日站会面对面交流） |
| 可用的软件胜过详尽的文档 | 交付实际可用的成果比大而全的文档更重要 | 采用“恰当文档”原则（如用户手册简化，优先保证功能可用） |
| 客户合作胜过合同谈判 | 与客户建立协作伙伴关系，而非对立谈判 | 持续沟通需求（如Scrum评审会邀请客户参与） |
| 响应变化胜过遵循计划 | 主动拥抱变更，而非僵化执行原计划 | 通过迭代开发（如Sprint）逐步适应需求变化（允许Sprint中调整优先级） |
3. 敏捷开发十二原则（核心要点）
- 客户满意：通过持续交付有价值成果使客户满意（如每2-4周交付可用软件）。
- 拥抱变化：即使在开发后期也接受需求变更（如Sprint评审后调整Backlog）。
- 频繁交付：短周期交付可工作软件（如每周/每月）。
- 团队协作：业务人员与开发人员每日合作（如结对编程）。
- 激发个体：以团队为核心，提供支持与信任（如自组织团队）。
- 面对面沟通：最高效的信息传递方式（如远程会议需辅以视频）。
- 进度度量：以可工作软件为核心指标（而非文档完成度）。
- 可持续开发：保持稳定节奏（避免加班冲刺）。
- 技术卓越：追求技术优化与良好设计（如代码重构）。
- 简洁为本：减少不必要工作（如避免冗余功能）。
- 自组织团队：最佳架构/设计出自团队自身（如团队自主决定技术方案）。
- 持续改进：定期反思并调整行为（如Sprint回顾会）。
六、敏捷实践-Scrum框架
1. Scrum核心结构（3-3-5-5）
| 类别 | 内容 |
|---|
| 三个角色 | 产品负责人（PO）、Scrum Master（敏捷教练）、开发团队 |
| 三个工件 | 产品待办列表（PB）、冲刺待办列表（SB）、产品增量 |
| 五个事件 | Sprint（迭代周期）、计划会议、每日站会、评审会议、回顾会议 |
| 五个价值观 | 承诺、专注、开放、尊重、勇气 |
2. 角色详解
（1）产品负责人（PO）
- 定位：客户代言人，最了解需求的业务专家（如产品经理、BA）。
- 核心职责：
- 唯一责任人：管理产品待办列表（PB），排序优先级。
- 需求决策：接受/拒绝Sprint增量，决定是否发布。
- 权威性：团队必须尊重其决策（开发团队不接受其他指令）。
- 工作特点：非管理职能（不负责团队考勤），专注业务需求；可团队参与PB维护，但最终责任自负。
（2）Scrum Master（敏捷教练）
- 定位：移除障碍，确保流程执行（“牧羊犬”角色）。
- 核心职责：
- 流程保障：确保团队遵循Scrum规则（如每日站会不超过15分钟）。
- 障碍清除：解决团队外部干扰（如协调资源、处理跨部门冲突）。
- 教育引导：教导团队/PO理解敏捷实践（如培训用户故事编写）。
- 服务对象：PO（优化PB管理）、开发团队（保护专注）、组织（推动敏捷转型）。
（3）开发团队
- 定位：自组织的跨职能团队，负责交付可发布产品增量。
- 核心特点：
- 自组织：自主选择任务、估算工作量、决定实现方式。
- 技能完整：团队成员具备全流程技能（如开发+测试+设计）。
- 无头衔：统称“开发者”，无层级差异（如“高级工程师”不主导决策）。
- T型人才：一专多能（如开发人员学习测试，测试人员学习开发）。
3. 工件详解
（1）产品待办列表（Product Backlog, PB）
- 类比：采购清单（包含所有待完成任务）。
- 内容：用户故事（需求描述）、缺陷、技术债等，按优先级排序。
- 管理：PO负责维护，动态调整（新增需求需重新排序）。
（2）冲刺待办列表（Sprint Backlog, SB）
- 类比：每次迭代的具体任务子集（从PB中选取）。
- 内容：Sprint周期内要完成的详细任务（如“完成登录功能开发”）。
- 作用：指导团队每日工作，跟踪迭代进度。
（3）产品增量（Product Increment）
- 定义：每次Sprint结束时交付的可用的、符合验收标准的成果。
- 核心要求：必须集成到当前产品中，且通过测试（如可发布状态）。
4. 事件详解（关键流程）
（1）Sprint（迭代周期）
- 时长：固定（通常2-4周），期间目标不变。
- 目标：交付一个可工作的产品增量。
（2）Sprint计划会议
- 时间：Sprint开始第一天（通常4-8小时，视周期长度）。
- 内容：PO讲解PB优先级最高的用户故事，团队拆解任务、估算工时，制定Sprint目标。
（3）每日站会（Daily Scrum）
- 时间：每日固定15分钟（如上午9:00）。
- 内容：团队同步进展、暴露障碍（三问：“昨天做了什么？”“今天计划做什么？”“遇到什么阻碍？”）。
（4）Sprint评审会议
- 时间：Sprint结束最后一天（通常2-4小时）。
- 参与：PO、开发团队、客户/干系人。
- 内容：演示产品增量，收集反馈，调整PB优先级（未通过验收的需重新规划）。
（5）Sprint回顾会议
- 时间：评审会后（通常1-3小时）。
- 内容：团队反思本次迭代的优点与不足，制定改进措施（如优化测试流程）。
总结：敏捷通过灵活的流程（如Scrum）、快速反馈（如MVP）和自组织团队，应对不确定环境，核心是“适应变化”而非“遵循计划”。
