Scrum 之 Demo

Posted 2021-04-25 拥抱scrum

上周我们团队进行了sprint review会议，在这个会议上有一个环节是演示（Demo）已经完成的用户故事，最终Demo的并不是很顺利。我参加过的Demo会议上，Demo不顺利的情况也已屡见不鲜。对于Demo，个人也有一些想法，这里分享出来，希望能和大家一起学习讨论。

Demo由谁来做

Demo应该由参与特性开发的团队成员来做，不要总是Scrum master或者特定的某个人做Demo，每位团队成员都应该参与到演示者角色上来。

Demo前的准备

首先要确定Demo演示者，然后演示者就要准备资料了，我们部门现在采用的Demo的PPT模板用于整理资料、组织演示很有帮助。模板里面首先是描述特性的背景以及用户需求概要，接着是用户故事，以及针对不同的用户故事对应的接收测试用例，演示的对象正是这些接收测试用例。演示者要从整体出发，决定演示的顺序，预先组织好语言，将这些测试用例连接起来。

然后要准备好演示需要的环境，并将要演示的内容先操作一遍。对于耗费时间太长或者现场不好演示的测试用例，保留运行的日志，或者生成的相关数据等，演示时展示这些信息并阐释清楚也可达到目的。

Demo进行时

首先记住一点，你展示的是这个Sprint的成果，而不要讲你为了得到成果而做了什么什么之类。

按照你预先准备好的材料，顺着之前组织好的语言就可以边讲解边演示了。

为了更好的控制演示进度，在一个特性的所有测试用例未演示完之前，不要自己或者被别人打断演示，在整个特性演示完成后，集中收集意见和反馈信息。有些人会演示完一个测试用例或者一个用户故事后就问大家有没有什么意见，有些时候意见挺多占用了很多时间，而会议时间又受限，直接导致了后面的测试用例潦草演示甚至没有时间演示。如果演示中间有其他与会人员提出意见或者看法，主持人或者Scrum master或者演示者要回应，＂当前是演示环节，如果大家有问题请先自己记下来，都演示完之后会集中收集意见和反馈，现在我们继续演示。＂

Demo之后收集意见

可能APO会说这不是他想要的，或者更深入的需求被提出来，或者还会有bug发现，统统这些都记录下来。如果需要需求调整或者解决方案调整，就加到下个Sprint的Backlog中，如果是Bug的就修改，可能还会有一些超出特性需求范围的意见，可以先记录，团队讨论之后再答复。