敏捷方法的含义

敏捷宣言的4大核心价值

• 个体和互动 高于流程和工具

• 可工作的软件 高于详尽的文档

• 客户合作 高于合同谈判

• 响应变化高于遵循计划

敏捷宣言的12条原则

• 最高优先级是 尽早持续交付有价值的软

• 欢迎需求变化，即使开发后期也要适应变化

• 频繁交付可工作的软件（周期越短越好）

• 业务人员与开发团队每天协作

• 激励个体，提供信任和支持

• 面对面沟通 是最有效的交流方式

• 可工作的软件是衡量进度的首要标准

• 可持续开发，保持稳定的开发节奏

• 持续追求技术卓越和良好设计

• 简单性（最大化不必要工作的减少）

• 自组织团队 能产生最佳架构、需求和设计

• 定期反思并调整工作方式

常见的敏捷方法

Scrum（最流行）

• 角色：产品负责人（PO）、Scrum Master、开发团队

• 关键会议：Sprint计划会、每日站会、Sprint评审会、Sprint回顾会

• 关键工件：产品待办列表（Product Backlog）、Sprint待办列表（Sprint Backlog）、增量（Increment）

Kanban（看板）

• 可视化工作流（To Do、In Progress、Done）

• 限制在制品（WIP）数量，优化流程效率

极限编程（XP）

• 强调 测试驱动开发（TDD）、结对编程、持续集成

DevOps（敏捷的延伸）

• 结合开发（Dev）和运维（Ops），实现持续集成（CI）/持续交付（CD）

敏捷方法的注意事项

1. 避免形式主义

   • 敏捷的核心是“个体和互动高于流程和工具”，避免过度依赖工具或僵化的流程，而忽视团队协作和实际价值交付。

2. 确保客户参与

   • 客户或业务代表应持续参与项目，及时反馈需求变化，避免开发团队闭门造车。

3. 保持迭代节奏

   • 每个迭代（Sprint）应控制在 2-4周，确保快速交付可工作的软件，避免迭代过长导致需求变更滞后。

4. 避免技术债务积累

   • 虽然敏捷强调快速交付，但仍需关注代码质量，避免因追求速度而忽视架构优化和测试覆盖。

5. 团队自组织与信任

   • 敏捷团队应具备自组织能力，管理者应避免过度干预，信任团队自主决策。

6. 适应变化但避免无序变更

   • 敏捷欢迎需求变化，但需通过产品待办列表（Product Backlog） 管理优先级，避免频繁无序变更导致目标模糊。

7. 持续反馈与改进

   • 定期进行 Sprint回顾（Retrospective），总结经验教训，持续优化团队协作方式。

8. 避免“伪敏捷”

   • 部分组织仅采用Scrum会议形式（如每日站会），但未真正遵循敏捷价值观，导致“形似敏捷，实则瀑布”。