09-Scrum过程-评审会(Review Meeting) & 反思会(Retrospective Meeting)

1.评审会(Review Meeting)

　　a.小组向产品经理展示迭代成果。

　　b.产品经理给出产品的评价和反馈。

　　c.以用户故事是否能成功交付来评价任务完成情况。

 

　　怎样展开评审会？

　　答：敏捷开发采用时间盒(Time Boxing)的方法，即限定时间而不限定范围。所以迭代不会延期，因为在迭代终点将放弃未完成的故事。

　　评审标准是什么？

　　答：整个故事是否已经达到交付标准，而不是从其中分解出来的任务完成了多少，因此若一个故事"差一点就完成了"，这种情况属于未完成。

　　分析说明:

　　　　常常发生很多故事都已经开始开发了，但都差一点完成的现象。因此应按迭代内的优先级逐条开发和交付故事。

　　　　一般总是优先开发MoSCoW方法中必须完成和应该完成的故事，再考虑其他可以完成的故事。

　　　　一般在迭代计划会上设定每个故事的完成标准，如是否需要测试、是否需要考虑性能、是否需要说明文档等等。

　　　　这些标准一般由项目组提前设定好。尽管有正式的评审会，但很多团队还是习惯于在单个故事完成时，就让产品负责人进行单个故事的评审，以确保交付时不会有"惊喜"。

　　　　评审会上发现的问题或改进将被累积到产品待开发项，也不会马上或在下一个迭代中马上开发，而是由优先级排序决定啥时开发。

 2.反思会(Retrospective Meeting)

　　a.在每个迭代结束后，会召开简短的反思会。

　　　 b.总结团队在开发中哪些做的好，哪些做的不好，总结经验。

　　    c.指定改进计划

　　怎样展开反思会？

　　　答：一般在反思会上讨论三个问题：我们在上个迭代中哪些事情做的好？哪些做的不好。好的继续保持，不好的希望改进，有何改进计划。

　　   分析说明:

　　    经常出现一些问题多次被提到，但却始终没有解决，应该每次仅就1~3个关键问题作出可行的解决方案，在下一个迭代中执行改进。

　　    "可行"的概念包括两个含义:a.方法简单、影响范围小、见效快；b.目标不要激进，而要显示可行、积少成多。

　　　 如果必要可以执行领导回避制度，即具有管理职能的人不参加反思会，即使这些人是产品负责人、项目经理、甚至是Scrum Master。