什么是 Scrum
简而言之，Scrum 需要一个管理者营造出这样一种环境：
- 一个产品负责人将复杂问题排序放入一个任务队列中
- Scrum 团队在一个 Sprint 周期内选出一部分工作完成，实现价值增长
- Scrum 团队和利益相关者检查这个 Sprint 周期的产出结果，并为下个 Sprint 进行调整
- 重复执行以上动作
Scrum 术语词汇表
| 专业名词 | 名词解释 |
|---|---|
| Burn-Down Chart | 燃尽图，用于表示产品任务队列的剩余任务数量 |
| Burn-Up Chart | 燃烧图，用于表示已完成的任务数量 |
| Daily Scrum | 每日Scrum汇报，大约十五分钟，在一个 Sprint 周期的每天都需要执行。Developer 会确认未来二十四小时的开发计划。在这个过程中，会检查上个 Daily Scrum 的结果，并调整这个 Sprint 接下来的工作。这有助于提高团队人员之间的协作和效率。Daily Scrum 可以很好的减少 Sprint 的复杂度 |
| Definition of Done | 产品任务完成的定义。任务队列中任务在执行时需要有明确的完成定义，这可以让团队对任务有更清晰的共同理解。如果一个产品任务不符合 Definition of Done，它就不可以被发布，也不能在 Sprint Review 中展示 |
| Developer | 隶属于 Scrum 团队的任何一名成员。 |
| Increment | 在 Sprint 期间产生的所有完整且有价值的工作就是 Scrum 的产出。所有的这些增量（Increment）的组合，就构成了一个产品 |
| Product Backlog | 产品任务队列。Scrum 的产物由一个有序的任务清单组成，这个清单可以创造、维护、和维持一个产品。Product Backlog 由产品负责人（Product Owner）管理 |
| Product Owner | 负责将产品的价值最大化，主要是通过逐步管理并向开发人员表达对产品的业务和功能期望 |
| Product Goal | 产品目标描述了产品的未来状态，可以作为 Scrum 团队计划的一个目标。Product Goal 在 Product Backlog 中，Product Backlog 剩余的任务定义了如何来实现 Product Goal |
| Ready | 产品负责人（Product Owner）和开发人员（Developer）对在 Sprint 中引入的任务有共同的理解 |
| Scrum Board | 一个实体面板，用于为 Scrum 团队提供可视化的信息，通常用于管理 Sprint Backlog |
| Scrum Master | 在 Scrum 团队中负责指导、辅导、教导和协助 Scrum 团队，确保对 Scrum 的正确理解和使用 |
| Sprint | 在 Scrum 中的一个重要组成事件，时间通常为一个月或者更短，作为其他 Scrum 事件和活动的一个容器。Sprint 是连续运行的，没有空隙 |
| Sprint Backlog | 在一个 Sprint 期间需要执行的任务清单，指明了这个 Sprint 周期内的产品目标 |
| Sprint Goal | 对 Sprint 周期内需要完成的目标的简短描述 |
| Sprint Planning | 一个 Scrum 事件，以八小时或者更短的时间来开始一个 Sprint。它的作用是让 Scrum 团队检查产品任务清单（Product Backlog）中，接下来最有价值的工作，并将这些工作设计到下个 Sprint 任务清单（Sprint Backlog）中 |
| Sprint Retrospective | 一个 Scrum 事件，以三个小时或更短的时间来结束一个 Sprint。它的作用是让 Scrum 团队检查刚过去的 Sprint，并计划在未来的 Sprint 中进行改进 |
| Sprint Review | 一个 Scrum 事件，以四小时或者更短的时间来总结刚过去的 Sprint 中的开发工作。它的作用是让 Scrum 团队和利益相关者检查 Sprint 的产出，评估所做的工作对实现产品目标的总体进展的影响，并更新产品任务清单，以使下个阶段的价值最大化 |
| Stakeholder | 利益相关者，Scrum 团队的外部成员，会在 Sprint Review 中与 Scrum 团队进行积极互动，关心 Sprint 的增量产出（Increment） |
| Technical Debt | 技术债务 |
| Velocity | 一个可选的，但是经常使用的指标，表明 Scrum 团队在 Sprint 期间将产品任务清单（Product Backlog）转化为产品增量（Increment）的数量，由开发人员跟踪，供 Scrum 团队使用 |
另外，当软件开发团队使用 Scrum 和敏捷编程时，也有些专业词汇。参考 Professional Scrum Developer Glossary
| 专业名词 | 名词解释 |
|---|---|
| User Story | 来自极限编程的敏捷软件开发实践，从终端用户的角度表达需求，强调口头交流。在 Scrum 中，它经常被用来表达产品任务清单（Product Backlog）上的一组任务 |
Scrum 工作流
图片来源：https://www.scrum.org/resources/what-is-scrum
本图描述了一个完整的 Scrum 工作流，其中的各个单元都在上文的名词解释中有提及。
图中的每个节点就是项目过程中我们需要关注的指标，节点之间流转就是管理人员需要介入的时间点。
从节点和流转的视角来看：
| 节点 | 节点指标 | 流入 | 流出 |
|---|---|---|---|
| 产品任务队列（Product Backlog） | 待开发任务的总和，需要关注燃尽&燃烧的情况 | 需要产品&项目负责人把关流入的需求 | 流出是转入下一个开发周期（Sprint）需要确认下个周期的排期安排 |
| 周期开发计划（Sprint Planning） | 关注会议的时间和结论，需要控制好时间和验证结论的合理性 | 需要确认优先级高的需求优先进入开发周期，但是需要关心需求的连贯性和整体性，我们的目标是本开发周期（Sprint）后的的产品增量（increment）能产生更大价值 | 需要将最终决定的需求整理好进入开发周期任务队列 （Sprint Backlog） |
| 开发周期任务队列（Sprint Backlog） | 进入到开发周期了，在这里依然要关注燃尽的情况，更重要的是需要对产品增量（Increament）负责，要将本开发周期的目标向最终产物对齐的同时，保障开发任务能按时交付 | 必须是整合过后的优先级高的需求流入，进入此队列时，需要对其开发资源，确保交付周期和质量 | 进入开发周期日会，检验成果 |
| 每日 Scrum 汇报（Daily Scrum） | 这是开发周期（Sprint）内的必要动作，日报需要关注昨天的开发情况，提早发现问题&暴露风险，也要规划今天的开发任务。这里并不是说在当天才确认当天的开发任务，而是对原定开发任务的一个补充。是根据之前的 Daily Scrum 已知问题和暴露风险，重新协调团队资源解决。这也是软件开发工作必须具备的提前量。 | 需要关心昨天开发工作中遇到的问题，也包含产品上可能的突发变动，或者是目标微调。这些问题需要在当日的 Daily Scrum 上提出 | 根据已知的问题和风险，重新协调团队资源解决问题，对当天的开发计划重新对齐 |
| 产品增量（Increment） | 关注产品功能和质量 | 一个开发周期（Sprint）的最终产物 | 验收确认可交付的产物 |
| 开发回顾（Sprint Review） | 评估产出的质量，找出上个周期开发不足，在下个周期时予以改正。评估本周期的工作对实现产品目标的总体进展的影响，并更新产品任务队列（Product Backlog），使下个阶段的开发价值最大化 | 上个开发周期（Sprint）的各种信息 | 找到团队问题和解法；评估产品目标进展和更新任务产品队列（Product Backlog） |
| 开发回顾（Sprint Retrospective） | 这个节点和 Sprint Review 类似，如果细分开的话可以将上一个节点视为产品价值的 review，这个节点更偏向于团队工作的 review | - | - |
Scrum 实践
理论是如何被实践的？实践过程中会遇到什么问题？解决的方案是否结合了理论？
- 各个节点和流转的负责人是谁？有什么工具可以支撑？
- 实际工作中，涉及需求理解的多方对齐，有无流程上的保障？（角色需求复述）
- 实际开发过程中，一个 WEB/APP/OTHER 项目开发会有什么特别流程？(产品试用)
- 如何做产品价值的 Review？（AB、数据分析）
- 实际工作中会有多种角色，并且角色介入产品开发的时间各不相同，如何串联起各角色的时间？（各个时间线的排期，各团队的 leader 先一步确认需求和大致排期）
#TODO
从《实例化需求：团队如何交付正确的软件》寻找部分解法
转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 [email protected]