如何提升Sprint Review的质量？

Sprint Review不是回顾，其目标是演示这个Sprint中本身的工做成果，参会人员包括设计师、开发人员和Product Owner。在Worktile，咱们尽可能保持Sprint评审会的轻松随意氛围。团队成员们会汇集在桌子周围进行非正式的演示，讲述本身在本次迭代中完成的工做。在这期间团队成员能够相互提问、尝试新的功能并提供反馈。成功的分享是构建敏捷团队的重要工做。

首先，咱们回顾一下为何团队对“完成”的定义对Sprint review如此重要：

第一步：定义“完成”

若是你在使用敏捷开发工具，那么你就应该清楚将任务卡从“测试中”拖到“已验收”这个操做会令你很是有成就感。这个任务卡的流转表明着一项工做终于完成了！

 

 

在截止时间前完成工做须要合理的规划、定义清晰的“完成”和专一的执行力。虽然大多状况下，这些工做是在Sprint规划阶段要作的事，但为了确保Sprint和review能顺利进行，团队要作的远不止规划，还要造成一种清晰的交付文化以及明确“完成”的定义。

交付文化

高效团队可以将清晰的流程和开发文化带到每一个工做项中。你能够用下面这些问题来评估一下你的流程，确保该流程能让团队保持最佳状态：

• 实施前，Product Owner、设计师和研发团队对用户故事的定义是否明确？
• 每一个人是否都理解并践行团队的工程价值观和文化？
• 关于代码审查、自动化测试和持续集成是否有明确的定义和需求来鼓励可持续的敏捷开发？
• 团队每完成一个用户故事，是否会有不少bug？ 换句话说，“完成”是否真的意味着“完成”呢？

团队的质量和完成文化应该在每一个用户故事、工程工做项和bug之上。这种文化反映了团队交付软件的方式。

为每一个工做项定义“完成”

明确 “完成”的定义能够帮团队聚焦每一个工做项的最终目标。当Product Owner在团队的backlog中添加工做时，定义验收标准是他工做流程中很是关键的一部分。用户故事的完成意味着什么？在Worktile，团队也会跟踪其余用户故事的验收标准和测试说明。这样，整个团队就可以明确掌握每一个工做项的完工状况。那么什么是验收标准和测试说明呢？

• 验收标准：Product Owner用于确认故事已知足其需求的指标。
• 测试说明：来自质量支持团队的简短、有针对性的指导，可帮助开发工程师编写更好的功能代码进行自动化测试。

定义明确的事项在实施过程当中更容易成功。经过使用Worktile，团队能够轻松添加字段及描述，让每一个任务都有清晰的定义。

 

 

第二步：庆祝团队成果

Sprint review是庆祝团队和我的在迭代过程当中所取得成就的好时机。因此在Worktile，咱们一般在周五下午进行Sprint review。Sprint review并非回顾的同义词，因此要确保在迭代完成以后，回顾以前举行Sprint review会议。虽然咱们欢迎外部人员加入会议，但一般状况下是Product Owner、整个开发团队和Scrum master参与会议。为了取得最佳效果，建议每一个迭代花费30分钟到1小时的时间。

咱们喜欢Sprint review，由于它能够保证团队的健康和士气。Sprint review的核心目标就是团队建设。review并非对抗，也不是考试——而是整个团队的协做活动，让成员能够展现本身的工做，现场交流并得到反馈。

若是Sprint review没能在团队中产生积极影响，缘由多是：

• 团队任务太多以致于迭代期间没法完成；
• 团队深陷现存的技术债；
• 功能开发未能确保持续性，以免在代码库中引入新的bug；
• 团队的开发习惯没有适时调整；
• Product Owner在迭代过程当中更改了优先级，而开发团队则因范围的变动陷入困境；

注意：团队在迭代中遇到困难是常有的事。迭代回顾会议时，团队能够花费点时间探讨一下为何迭代过程当中会发生变动，并制定计划在下一个Sprint中解决问题。

最后建议

对于那些不熟悉sprint review的团队来讲，它们很容易就将其并入sprint回顾会议。Sprint review是独立于sprint回顾会议以外的独立仪式。经过sprint review，咱们能够花点时间享受工做成果、自由地庆祝成就。有效的sprint review能够加强团队的士气和动力。

 

文章来源：Worktile敏捷博客

欢迎访问交流更多关于技术及协做的问题。

文章转载请注明出处。