当前位置: 代码迷 >> 综合 >> 09-Scrum过程-评审会(Review Meeting) 反思会(Retrospective Meeting)
  详细解决方案

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

热度:94   发布时间:2024-01-09 12:49:39.0

http://www.cnblogs.com/enze/archive/2012/08/13/2635679.html


1.评审会(Review Meeting)

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

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

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

 

  怎样展开评审会?

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

  评审标准是什么?

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

  分析说明:

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

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

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

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

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

 2.反思会(Retrospective Meeting)

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

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

      c.指定改进计划

  怎样展开反思会?

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

     分析说明:

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

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

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


  相关解决方案