最近几天经常在一些群里看到这样一个命题：迭代结束时间到，如果迭代没有完成怎么办？

各路大神的观点混战让人如同再看一遍奥本海默般上头。比如：

• 上来就开始甩锅的

• 要拿SM祭天的

• 向领导表决心的

• 加班加点干出来的

• 加资源的

• 调后续迭代的

• 没啥迭代周期不能动的

• 要调交付日期的

• 置换需求的

• ……

难道不应该复盘再决策吗？当然也有要先冲上去搞定再反醒的。可能内心戏半夜都能笑醒了吧。

源起

我们来呈现一个源起。假设一个迭代的完成定义（DoD）是可随时上线。那么可能意味着，在迭代结束之时，或者移测的最后截止日期，并不是所有计划里的故事都已经完成了。

说到迭代，也意味着，对于这个周期，显然是失败了。如果跟领导汇报的话，就很麻烦：你们是不是团队能力不行？或者资源不足还是什么其它原因？你是不是个人的努力不够？

在很多组织里，这种情况屡见不鲜。问题的产生原因应该有许多，表相原因极为清晰，开发没有做完。或者迭代计划里的故事还有些没有开始做。迭代没有完成，自然是不好看的。既然说好了要把这一“堆”做完，总要有个交待吧：

• 怎么追？

• 能不能完成？

• 谁来干？谁的责任？

决策

面对这种情况，至少有两种差异极大的决策是可能做出来的。

其中一种是救火式的。比如既然开发还有一些没做完的，那些做完的要不要在这个迭代全部交付完成呢？救火派一定是可以做完的，实在不行就延期做完它。现在想像一下那些画面：

• 赶快把锅甩出去，一定不是我们的问题

• 报告风险并向领导保证风险可以被控制

• 跟领导汇报并做出承诺，保证保证再保证

• 堵住团队的门让他们加班干完

• 降低质量，声明已经做完了它。于是原来需要完成的测试工作被切分成数块，只做单体测试，让工作看起来是完成了。因为每一个任务都做了嘛

• 团队规则被打破

• 把其它的工作放到后边去解决

• 重要的是这个时候可以讲一讲困难，压力如何大，我们如何努力

• 态度诚恳。可以能力不足，不能在困难面前低头，让领导知道在关键的时候我们可以冲上去

• 向领导发誓说

• 报告这次迭代的成功

• 然而完全不能上线

• ……

另一种是保养式的。做没做完都需要演示一下成果，回顾一下过程。已经完成并确认的部分是本迭代的团队产能。已经做完了迭代计划中“必须完成”的部分吗？相关的根本原因是什么呢？我们也来想像一下画面：

• 回顾和复盘。反思未完成的根本原因是什么，明确重要且紧急以及重要不紧急的解决方案。加急处理重要且紧急，优先处理重要不紧急。

• 团队做出努力但遵守真的“完成约定（DoD）”，即完成的内容可以上线

• 团队规则被遵守

• 迭代产能越来越准确

• 后边的工作是新的需求，而不是遗留的任务

• 有问题会及时发现（晨夕会以及Showcase）

• 已经完成那些部分都能上线

• ……

当然还有其它的决策。决策的成功看效果。效果有很多方面，比如：

• 团队能力越来越强

• 领导认可的是什么：工作成果还是加班表现？

• ……

我们都是“结果”导向的，因为结果会改变决策的方式。

工具

现在想像有一枚绣花针。用它来扎一下团队。这个绣花针扎了不会致命，但它真的疼。假设这个绣花针扎完之后我们就知道这个团队靠不靠谱，他们的能力够不够，承诺是不是值得信任，那很多事根本就和敏捷就没有什么关系的。

显然事后解决型的、浮于表现的解决方案看起来勤勤恳恳，慌慌乱乱，铁锅满天飞，其实是在将水越弄越浑，这样才可以摸鱼，才显示出重要性。而这样形成的文化就会：

• 不承认

• 不负责

• 不改进

无规矩，人就是规矩。

而事后复盘型的、基于根因的解决方案看起来有章可循，稳步解决，团队承认现状，并从自己出发，一边改进自己形成能力，一边解决问题，团队是一个整体。而这样形成的文化就会：

• 遵守约定

• 信守承诺

• 不停演进

因为规矩，团队自成方圆。

我们把“演示”作为一个绣花针，对团队检测很容易进行：

• 迭代末进行迭代演示会，在UAT环境中由产品经理向业务方演示迭代成果，那整个迭代的能力和承诺交付就会一览无余。

• 每一天进行单个用户故事的移测演示（Showcase），在SIT环境中由开发向测试和产品经理演示故事的交付结果，那么成员的能力和承诺交付就会质量和时效都靠谱很多。

这枚绣花针，扎人虽然疼，然而，如果团队靠谱，他们就不会被扎到。如果暂时不靠谱，扎到痛处，那就改进。怕就怕扎多了，团队疲了，怎么扎都不疼了。索性你想完成就完成，为了救火，开始放火给你看，再表演救火了。而且，因为你爱看。