结合工具来实现敏捷开发 - 14

现在开始说说完成一个Sprint以后的事情了，第一件事情当然是评审会了，所谓的评审会就是产品的负责人来检查是否这个Sprint的功能是完全按照设计文档来的，是否真的100%满足了客户的需求，这个会议中就需要把各个功能实际演示一遍。

 

理想情况就是所有计划会上要求的功能都很完美地实现了，大家都很满意，都很兴奋，甚至用户代表也参加了也觉得满意。不过，往往实际情况并非如此，主要会有以下几种情况：

1.       功能到Sprint结束还没完成：这种情况下会议上就不需要看这个功能，直接略过，等到下个Sprint结束时再来看这个Feature

2.       功能已经完成，但是测试还没完成：这种情况，我们是建议等到测试完成后再去演示这个功能，因为开发人员自己认为的“完成”是完美的，没有任何Bug的，但是很多时候会在测试中发现很多问题，所以开发说做完不是真正的功能完成，一定得测试完成以后才是真正完成。

3.       功能开发和测试都完成了，但是发现设计思路不对，需要重新改：这种情况下，建议新建新的功能点，然后添加到Backlog中，以后作为一个新的功能点任务分配出去。

 

对于一个评审会而言，很重要的一点就是我们得看到一个可以工作的产品来演示这个Sprint实现的功能点，演示的目的是让大家知道这个产品是不是按照计划，按照正确的方向，按照客户的需求在前进，所以每个Sprint都不能无故推迟，即使你有一个重要功能没完成，没关系，把这个功能推迟到下一个Sprint完成，这个Sprint中其它功能得正常的在产品里演示出来。所以一般我们要求开发，没实现的功能不要提交代码，否则可能会引起Build失败或其它无法预知的问题，要确保已经实现的功能能正常的工作。我们公司就出现过开发提交了没做好的功能代码，导致了两天拿不到一个可用的Build来测试，影响巨大。