敏捷方法

敏捷宣言的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会议形式（如每日站会），但未真正遵循敏捷价值观，导致“形似敏捷，实则瀑布”。