1. 会议

在Scrum会议中包括：计划会议、每日站会、评审会议和回顾会议。

2.介绍

2.1 Sprint计划会（Sprint Planning）

2.1.1 第一部分 决定需要完成哪些工作 what

PO向开发团队介绍排好序的Product backlog，由整个Scrum团队共同理解这些工作。
产品待办列表梳理会议（product backlog refinement）
refinement（grooming）
简单的来说，Refinement目的就是让我们Backlog里的Story更加DEEP，DEEP的意思是：
Detailed Appropriately
Emergent
Estimated
Prioritized
具体操作方式如下图。
image.png

Sprint中需要完成的产品待办事项数目完全由开发团队决定。做多少工作只能由开发团队决定，产品负责人或任何其它人都不能给开发团队强加更多的工作量。

2.1.2 第二部分 决定这些工作如何完成 how

开发团队需要根据当前的“完成的定义”一起决定如何实现下一个产品增量。他们进行足够的设计和计划，从而有信心可以在Sprint中完成所有工作

决定如何完成工作是开发团队的职责，决定做什么则是产品负责人的职责。
Sprint计划会议最终需要Scrum团队对Sprint需要完成工作的数量和复杂度达成共识，最终产生的待办事项列表就是“Sprint待办事项列表（Sprint Backlog）”。
Sprint待办事项列表是一个需要在当前Sprint完成的且梳理过的产品待办事项，并包括了一个团队完成这些工作的计划。

2.2 每日站会（Daily Scrum）

每一个开发团队成员需要提供以下三点信息：
从昨天的站立会到现在，我完成了什么； Done
从现在到明天的站立会，我计划完成什么；Plan
有什么阻碍了我的进展。Difficult
每日Scrum中可能有简要的问题澄清和回答，但是不应该有任何话题的讨论。
每日Scrum既不是向管理层汇报，也不是向产品负责人或者Scrum Master汇报。它是一个开发团队内部的沟通会议，来保证他们对现状有一致的了解。

2.3 Sprint评审会（Sprint Review）

Sprint结束时，Scrum团队和相关人员一起评审Sprint的产出。所有Scrum会议都是限定时长的，Sprint评审会议的推荐时长是Sprint中的每一周对应一个小时（比如，一个Sprint包含2个星期，则Sprint评审会议时长为2个小时）。
每个人都可以在Sprint评审会议上发表意见。产品负责人会对未来做出最终的决定，并适当地调整产品待办事项列表（Product Backlog）。
Sprint评审会议向每个人展示了当前产品增量的概况。通常都会在Sprint评审会议中调整产品待办事项列表。

2.4 Sprint回顼会议（Sprint Retrospective）

在每个Sprint结束后，Scrum团队会聚在一起开Sprint回顾会议，目的是回顾一下团队在流程、人际关系以及工具方面做得如何。团队识别出哪些做得好，哪些做得不好，并找出潜在的改进事项，为将来的改进制定计划。所有的Scrum会议都是限定时长的，Sprint回顾会议的推荐时长是Sprint中的每一周对应一个小时（译者注：比如，一个Sprint包含2个星期，则Sprint回顾会议时长为2个小时）。
Scrum团队总是在Scrum的框架内，改进他们自己的流程。

2.5 总结

Scrum团队成员（包括产品负责人、开发团队，以及Scrum Master）一起合作完成一系列的产品增量，他们采用称为Sprint的短时间周期。每个产品增量符合产品负责人的接受条件，并满足团队的“完成的定义”。所有工作来自于产品待办事项列表（Product Backlog）。
Sprint总是从Sprint计划会议开始，团队在会议中制定出Sprint待办事项列表（Sprint Backlog）。团队自组织地去开发，利用每日Scrum会议来协调并确保团队产出最好的产品增量。团队通过产品待办事项列表梳理来为下个Sprint计划会议做准备。在Sprint结束时会有Sprint评审会议以及Sprint回顾会议，来审视产品以及团队流程。

3 DOD DOR

DoR 和 DoD 就是 Definition of Ready 和 Definition of Done。
Scrum - 图2

我们的敏捷团队在需求管理上主要有两个会：需求梳理会和需求计划会议。
需求梳理会的阐述的意向用户故事会放到 Backlog，后由研发 Owner 跟进，在计划会上，将符合 DoR 放入 Sprint Todo。
「Backlog」 to 「Sprnt Todo」：

  • PRD，原型产出
  • UI 设计，相关依赖方已明确
  • 需求以用户故事及实例化验收标准呈现
  • 具有开发时间的评估（Dev：前端，后端）
  • 具有测试的时间评估（Test）
  • 在故事上标注明确的预计上线时间（不包括紧急 Buffer）

「Sprnt Todo」 to 「Doing」：

  • 完成设计评审（技术架构评审）
  • 如果需求发生变更或增加，需要重新 check 用户规模和上线时间点（同步运营和产品）

「Done」 to 「Test」：

  • 研发 CodeReview 完成（代码评审）
  • 测试完成测试用例并同步给研发
  • 研发根据测试用例在预发上自测完成
  • 新功能埋点完成
  • 研发提交 Jira 任务
  • 研发配置好测试环境，提供有效参数和配置
  • 如果有其他因素导致进度停止，放入停车场

「Test」 to 「Ready on line」：

  • 发布计划评审
  • 依据测试用例完成上线需求及可能影响的功能测试
  • 测试过程中产生的 bug 解决
  • 产品验收、UI 验收、交互验收
  • 如果有其他因素导致进度停止，放入停车场

总而言之，涉及到10人日以上的项目，必须有明确的技术架构评审、代码评审和发布计划评审。

DoD, Definition of Done

Scrum最重要的概念之一，就是对每个Sprint Backlog条目要有非常明确的Done的定义。譬如，对一个典型的编码任务而言，对其Done的定义应该涉及如下几个方面：

  • 设计文档必须经过评审。
  • 功能应该完全实现（包括错误处理、性能、可靠性、安全性、可维护性及其他质量标准）。
  • 代码符合编码标准。
  • 有UT并测试通过。
  • UT的代码覆盖率（Code coverage）>80%。
  • 至少有一个人做过代码评审（Code review）。
  • 代码已经提交。

只有这样，我们才容易对两件事情达成共识：其一，如何做才算完成一项编码工作？其二，shippable quality（可交付的质量标准）到底意味着什么？如果这些定义不清晰，以后你会花更多的时间和精力，并且修正会更难。
通过敏捷，我们期望在较早的阶段就给出高质量的交付，而不是依赖于最终阶段的长期”稳定”，如果我们在前期就尽一切努力预防Bug，长远来看，我们会更省时间，发布得更早。对每一个任务都明确定义Done是非常关键的。

DoD的要点

  1. 为Sprint中任务给出明确的Done定义是非常重要的。不过即使遵循这个最佳实践，但最终仍然会有集成问题，会存在Bug，还有后期的需求变更。所以，对于大型复杂产品，在正式发布前，单独计划1～2个Sprint，专门做Bug修复，也是合理的。
  2. 关于完成/DoD的例子，通常需要从以下几个维度考虑：
    • 需求/用户故事DoD
      • 用户故事的描述及拆解符合INVEST。
      • 用户故事有验收标准AC（Acceptance Criteria）
    • 开发任务DoD
      • 代码已经提交到代码库
      • 代码通过单元测试
      • 代码经过Code Review
      • 代码通过集成测试
    • 迭代DoD
      • 所有代码通过静态检测，严重问题都已修改
      • 所有新增代码都经过Code Review
      • 所有完成的用户故事都通过测试
      • 所有完成的用户故事得到Product Owner的验证
    • 发布DoD
      • 完成发布规划所要求的必须具备的需求
      • 至少完成一次全量回归测试
      • 符合质量标准（Quality Gate），所有等级为 1、2 的缺陷均已修复；3、4 级缺陷不超过10 个
      • 有发布通知（Release Notes）
      • 有用户手册
      • 产品相关文档已全部更新
      • 代码已部署到发布服务器上，并冒烟通过
      • 原始需求提交人完成UAT
      • 对运维、市场、客服的新功能培训已完成
  3. 完成的定义（DoD）及团队工作协议必须是团队共同讨论出来的，团队愿意共同遵守的原则，一旦确定，团队就应共同遵守。