敏捷开发 II 什么是Sprint?!

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。

然后团队需要在此基础上制定一个计划，说明他们将如何构建Product 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去完成。

如果听到团队成员表达的担忧，无论是关于团队速度、低确定性工作，还是他们认为超出预估的工作量，都不要忽视这些声音。解决他们提出的问题，并在必要时重新校准。