共计 1756 个字符，预计需要花费 5 分钟才能阅读完成。
Sprint 指 Scrum 团队完成一定数量工作所需的短暂、固定的周期。Sprint 是 Scrum 和敏捷的核心，找到正确的 Sprint 周期将帮助您的敏捷团队交付更高质量的产品。
“在 Scrum 框架中，庞大且复杂的产品将被拆分成一个个小的片段，通过一系列被称为“Sprint”的迭代来完成。”
Sprint 使项目更易于管理，让团队更快、更频繁地交付高质量的工作，并使团队能够更灵活地适应变化。
许多人将 Scrum 的 Sprint 与敏捷软件开发联系起来，以至于不明就里的人将 Scrum 和敏捷当成是同一件事。但实际上，两者根本不是一回事儿。敏捷是一套开发的原则，而 Scrum 则是一个能够帮助你把活儿搞定的框架。
如何规划和执行 Scrum Sprints？
Scrum 践行者们考虑十分周到。通过召开 Sprint planning 会议，用于规划即将开始的 Sprint。Sprint Planning 是一个团队协作活动，这个过程中，团队需要回答两个基本问题：本次 Sprint 要完成哪些工作？如何完成？
Product Owner，Scrum Master 和开发团队需要协作选定每个 Sprint 中要做的工作项。Product Owner 则需要商讨 Sprint 要达成的目标，以及在 Sprint 结束时可以确保目标实现的 PBI。
然后团队需要在此基础上制定一个计划，说明他们将如何构建 Backlog 列表并在 Sprint 结束之前将其“完成”。选择工作事项以及如何完成这些工作事项的计划被称为 Sprint Backlog。Sprint Planning 结束时，团队已经准备好开始 Sprint Backlog 的工作，将 Backlog 列表中的工作推进到“进行中”和“已完成”。
Sprint 期间，团队通过每日站会汇报工作进展。站会的目标是展示可能影响到团队顺利交付 Sprint 目标的阻碍或挑战。
Sprint 完成之后，团队将在 Sprint Review 上展示他们在 Sprint 期间完成的工作。这也是在产品正式上线前，团队向利益相关者和团队其他成员展示工作成果的机会。
最后，以 Sprint Retrospective 来为整个周期画上一个圆满的句号。这也是确定团队在下一个 Sprint 中需要在哪些地方做出改进的机会。在此基础上，就可以着手开始下一个 Sprint 周期了。
要和不要
即便在掌握了前述基本准则的情况下，大多数团队在刚刚开始尝试 sprint 实践时也会遭遇诸多困难。以下是一些建议的做法和注意事项。
推荐要做的事项：
- 一定要确保团队设定并真正理解了 Sprint 目标以及 Sprint 成功与否的标准。这是确保每个成员协同一致并朝着共同目标前进的关键。
- 确保 Backlog 中所有的工作项按照优先级和关联关系顺序进行排列。如果管理不当，这可能会是一个极大的挑战，并且还会破坏整个过程。
- 确保团队对速度有很好的理解，并且要体现休假和团队会议等事项。
- 用 Sprint Planning 会议来充实需要完成工作的具体细节。鼓励团队成员为 Sprint 中的所有需求、bug 和任务草拟工作任务。
- 如团队无法判断相关性，例如来自另一个团队、设计和法律签署的工作则应该暂时搁置。
* 最后，一旦做出决策或计划，请确保有人在项目管理或协作工具中能获取该信息。这能够确保每个人都可以轻松地查阅相关决定及其理由。
当我们致力于成为完成前述所有“推荐要做的事项”的 Scrum 团队时，也要避免下面这些危险事项：
需要避免的事项：
- 不要一次性设计太多用户故事、高估团队速度，或在 Sprint 中加入无法完成的任务。尽量避免设定那些注定会导致团队失败的目标。
- 不要忘记质量或技术债。要为像 bug 和工程师健康等这样的 QA 和非功能性工作预留缓冲时间。
- 不要让团队对 sprint 中工作内容存在不清楚的地方。确保每个人都清楚地了解，不要太专注于快速推进而忘记确保每个人都朝着同一个方向前进。
- 此外，不要承担大量未知或高风险的工作。将庞大或具有高度不确定性的用户故事进行拆解。可以大胆地将部分工作留到下一个 Sprint 去完成。
- 如果听到团队成员表达的担忧，无论是关于团队速度、低确定性工作，还是他们认为超出预估的工作量，都不要忽视这些声音。解决他们提出的问题，并在必要时重新校准。
文章来源：Worktile 敏捷博客
欢迎访问交流更多关于技术及协作的问题。
文章转载请注明出处。
