Product Backlog（产品待办列表）

• 项目背景
• 用户故事列表（Story，指一条用户需求）
• 阶段性规划 - 拆分故（事）事（项）

Sprint 计划

计划会议

• Sprint 目标
• 团队成员（成员的投入度）
• Sprint Backlog（当前 Sprint 包含的故事列表）
• 确定 Deadline（Sprint 演示日期）
• 每日晨会时间点

   范围
估算    重要性

PO 确认 Sprint 目标的范围与 Story 重要性。
团队根据 Story 拆分功能，讨论细节，估算时间。
调整 Story 的重要性和目标的范围。

评估
⇩
调整
⇩
重新评估
⇩
最终确认

不能在质量上让步

• 外部质量：显性，可通过快速迭代一步步解决
• 内部质量：隐形（含系统设计，测试覆盖率、代码可读性、项目可扩展性等）
• 必须保证内部质量，从开始到永远。

牺牲内部质量来换取时间是糟糕与不负责任的想法。
技术债是给团队挖坑，给项目埋下恶魔的种子。
将来需要付出的代价是不可预估的。

工作细节

• 确定 Sprint 长度（开发周期，例如两周一迭代）
• 确定目标
• 确定 Backlog（Product Backlog => Sprint Backlog，PO 建议，团队决定数量）

估算生产率

• 用本定反应估算
• 用生产率计算估算（估算生产率、实际生产率，调整下一个 Sprint 生产率估算）

索引卡

• 明确故事内容
• 确定优先级
• 拆分成更小的故事
• 故事再拆分成任务
  故事是可交付的内容（PO 最关心的模块）

技术故事

非功能性条目，例如软件升级、安装，架构调整等。
协调技术故事与用户故事的时间安排。

验收标准

更具优先级来验收，哪些是必须的，哪些是可以放到下一个 Sprint 继续完善的。

Sprint 之间的休整时刻

让团队有适当的空余时间自我学习与调整。

XP 极限编程

• 定制代码标准
• 结对编程（例如：代码审查）
• 测试驱动开发（TDD）
  • 黑盒集成测试
  • 自动化测试（Selenium）
  • 开发 - 构建 - 测试（通过 Mock 构造数据）
• 持续集成
• 充满信息的工作空间
• 可持续的开发速度

拒绝盲目加班，保证工作时精力充沛。

多个 Scrum 团队

• 虚拟团度
• 单个团队最佳规模 5～9 人