敏捷开发 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去完成。
如果听到团队成员表达的担忧,无论是关于团队速度、低确定性工作,还是他们认为超出预估的工作量,都不要忽视这些声音。解决他们提出的问题,并在必要时重新校准。