我们这样做Scrum的评审会议

我们这样做Scrum的评审会议

在实践中，我们发现如果只在Sprint之后再做Demo，由于Sprint过程中沟通不充分，Demo展示的功能很可能不符合客户真正的需求，导致Sprint失败。于是，我们按照优先级和耦合做分组，高优先级的需求组尽早完成做Demo，让需求缺陷的风险前移。这里的分阶段 Demo不是正式的Demo，在10分钟内完成。

 

流程可以参考图：

 

 

好处：

1. 任何偏离需求的风险在Sprint期间的非正式Demo时被发现，得到及时处理

 

2. 需求组是按照优先级排序的，先做的是最高优先级，那么如果发生了任何意外（例如人员变动、技术障碍等）无法完成所有的需求，那么高优先级的需求可以在Sprint结束前被提交，以保证交付目标

 

 

我们做正式的Demo，会坚持以下原则：

1. 只是演示本次Sprint内的功能

 

2. 演示过程中，Stakeholders提出的意见，在演示会议中不做讨论，只是做记录，在会后再进行沟通。

 

3. 尽量保持Demo时间控制在60分钟

 

4. 一个人完成所有的演示

 

5. 只演示已经完成的功能。除非Stakeholders要求，否则不展示未完成的功能。因为只有已经完成的功能才是可以给客户带来价值的。

 

 

迭代结束了，如何判断迭代成功了？

迭代是否成功根据是否满足“完成标准”而定。“完成标准”会包含“需求交付”和“代码质量”等因素。我们细分了迭代失败和交付失败。如果有story不能交付，或者story的实现有较大的技术债务，但是不影响迭代目标的实现，则视为交付成功，迭代失败。如果所有的story都完成了且不存在较大的技术债务，则视为交付成功，迭代成功。失败的story放在需求列表中重新排优先级。

 

 

谁会判断迭代的状态？

PO接受只是一部分，评审也往往是关键路径做了演示。很多异常流程、非功能性需求等需要测试报告。PO需要和报告一起来决定是否可以交付，交付决定权在PO。但我们的“迭代完成目标”，除了交付外，还有技术债务等，这些由团队决定，虽不影响交付，但会影响内部迭代是否成功。