中期评审
不知道你的团队是否经历过所谓的“Sprint 中期评审”？如果有的话，那么恭喜你，你不是一个人。
不少团队都会选择加一个“中期评审”以保证工作可以顺利进行。就我遇到的情况，主要的原因有以下几种：
- 团队成员之间信息同步
- 确认Sprint 目标是否能实现
- 确认是否要对Sprint Backlog进行增删（这点跟2有点接近）
- 希望以此从PO 处获得一些反馈
在我看来，这都不是好的原因，虽然很多团队觉得理由还挺充分的。
其实这些理由，都给了我们一个信号：Sprint 太长。
我们一条一条来看。
如果每天的站例会依然不能满足“同步”信息这个工作，以至于需要一个专门的行动来进行同步，那我们是不是应该认为Sprint太长了，导致团队成员精力已经开始（因为事务太多）偏移了？而团队成员通过每天同步，已经不能完全达到同步的目的，这就是一个很危险的信号——你的团队成员在处理过多的事情。那么最有可能的原因是什么？也许就是Sprint 过长。
同样，如果一个Sprint 中我们需要考虑对范围进行改变，是不是也可以认为太长，导致我们在一开始的Planning 阶段是有很大问题的？所以我们才需要中期评审来进行弥补？
尽量多的从PO 处获取反馈看起来是个合理的理由，但是如果需要强迫性质的通过本来不该存在的中期评审来获取，那为何我们不在一开始就将Sprint拆分为两次呢？
不可否和，中期评审让团队成员有机会来思考当前迭代中需要完成的种种工作，并作出调整，但这些都是“额外”的工作，在敏捷中应该被认为是“浪费”，这些应该是从根本上被杜绝的。
所以下次当你发现你需要一些中期评审的时候，也许你真正该思考的是“我们的Sprint 是不是太长了？”
