项目实践二：3-评审会

项目组向产品负责人展示迭代工作结果，成为评审会。在评审会，产品负责人给出评价和反馈。

1. 评审会

• 小组向产品负责人展示迭代工作结果。
• 产品负责人给出评价和反馈。
• 以用户故事是否能成功交付来评价任务完成情况。

评审会开展

• 评审标准：整个用户故事是否已经达到交付标准。

  评审的标准是整个故事是否已经达到交付标准，而不是从其中分解出来的任务完成了多少，因此若一个故事“差一点就完成了”也算没有完成。

• 评审标准在迭代计划会上设定。

  一般在迭代计划会上设定每个故事的完成标准，如是否需要测试，是否需要考虑性能，是否需要说明文档等等。这些标准一般由项目组提前列好，每个故事只需要选中是否需要即可。

• 单个用户故事评审

  尽管有正式的评审会，但很多团队习惯在单个故事完成时，就让产品负责人进行单个故事评审，以确保交付时不会有“惊喜”。

• 发现的问题被累积到产品待开发项

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

这个活动的关键是 检视与调整 sprint过程中产出的产品增量。

1. 第一步是回顾sprint目标和承诺的特性集，并和实际完成的情况进行对比。
2. 第二步是演示和讨论完成的特性，并对产品backlog或者发布计划做出必要的调整，以反应讨论中新的认知，然后重复这个步骤。这个循环直到讨论完所有完成的特性之后才结束。

在这个方法中，演示只是sprint评审会议中的一个活动，它不是sprint评审的目的。

sprint评审会议的目标是 检视与调整 构建的产品。成功的评审结果是双向的信息流动。不属于Scrum团队的人也可以得知开发的成果并帮忙指出方向。

同时，Scrum团队成员通过频繁的反馈而加深了对产品的业务和市场认识。所以，sprint评审会议是一个 检视和调整 产品的预定机会。

2. 评审会问题和改进

1. 问题反馈
2. 改进积累到Product Backlog

3. 评审会示例

1. 计划会认领的需求（任务）：讲解和最初估计时间。
2. 展示一页纸测试计划，简单描述测试方案
   • 关于Tower 日历的测试场景：
     1. 日历表中，高亮今天的日期
     2. 创建多个日历簿，每个日历簿上创建日程
     3. 在项目日历簿，创建日程
     4. 在项目中添加任务，到当前日历中查看
     5. 日历中的任务，点击跳转
     6. 在项目中创建日常，到日历中查看
     7. 日历的重复功能
     8. 日历的提醒功能
     9. iCalendar订阅
3. 打开禅道，找到指定的迭代和需求。展示需求的测试任务。
4. 在测试模块，找到用例，简单讲解用例
5. 在Tower中演示测试过程
6. 如果有测出缺陷，描述缺陷。

4. 评审会总结：

• 经验的积累：分析需求需要更加细致，不可以放过页面上的任何一个元素

• 测试要注意关联：模块之间的关联容易寻找，但是模块内部的关联也是很重要的

• 用例的编写：需要留意用例的标题，标题不可以有是否这样的寻求答案的字眼出现，而是应该以预期结果为导向的出现。

  • 例如
    1. 注册用户时，输入过长的团队名称，可以注册成功。（错误用例）
    2. 注册用户时，输入过长的团队名称，是否可以注册成功。（错误用例）
    3. 注册用户时，输入过长的团队名称，不可以注册成功，提示用户名称过长。（正确用例）

• Bug提交：Bug的描述，Bug的重现步骤，截图等需要认真描述。另外在禅道中学会使用用例的转Bug功能。

  Snap1.jpg
  Snap2.jpg
  • 上述用例的执行失败，会产生Bug。那么bug的标题：注册用户时，输入过长的团队名称，用户可以注册成功，团队创建失败。

• 禅道中，有两个地方的版本菜单。项目（迭代）中的版本，由开发创建，创建后，关联该版本的以下内容：

  Snap4.jpg
  • 完成的需求
  • 解决的Bug
  • 遗留的Bug

  然后提测。

  测试中的版本，由测试操作，关联用例，并执行用例。具体步骤如下

  • 开始测试

    Snap5.jpg Snap6.jpg

  • 关联用例

    Snap3.jpg

  • 执行用例

  • 关闭测试