敏捷开发中“可运行软件”的评审标准（兼谈敏捷开发中的迭代中期质量控制）

软件“可运行”了就可以评审且通过了？这是个问题。

在多年前参加Scrum Master培训的时候，老师拿出一个很好的表格，每行是一个故事，每列大致如此：

编码完成

功能测试

单元测试

集成测试

压力测试

自动测试

……

这样在计划会的时候，PO就告知大家每个故事他的要求是什么，一方面大家会因此对于要估计的用户故事有一个更明确的理解，另一方面就是约定了评审会上这个故事的完成标准。

 

这个方法已经不错了，不过后来又发现一个更好的：EA（一家游戏公司）将其所有故事完成标准分为5级，分别是：

1. 可提供反馈的（就是马马虎虎做出来能玩就行）

2. 可运行的

3. 可提供玩家评价的

4. 可提供玩家体验的（在体验服务器上安装（在线游戏），或发行预览版（单机游戏））

5. 完美的（可上线和销售的）

这种方法更好地从客户价值理解了“完成准则”，看到准则等级，就知道该如何使用此功能。

当然两种方法并不矛盾，因为“可提供反馈的”这种基于客户价值的完成标准一定有对应的基于实现的完成标准，比如“可提供反馈的 = 编码完成+功能测试”。

 

另一个话题是有了这些标准，如果只在最后评审会才使用，一定会制造不少“惊喜”。所以在迭代中期如果有些功能已经完成，完全可以随时评审，并基于评审结果当时就做改进。有一家公司在长度为一个月的迭代中的10、20天分别进行两次评审；而游戏公司普遍采用的是在功能完成的同时就进行评审。评审中发现的问题属于要拥抱的变更（在《迭代期内无变更与……》的两篇博文中有描述）而非要拒绝的变更，以便使得迭代能交付更多客户价值，MoSCoW会防止变更损伤承诺。