用单元测试的套路进行敏捷回顾

最近和小崔同学聊天，谈到即将到来的一次年度回顾会议，回顾一下我司2017年的技术论坛活动，下面是我们的谈话片段：

我：你觉得这次回顾会议应该怎么开？
崔：这还不简单，首先回顾一下我们的预期，然后看下实际结果和预期的差距，最后制定一下行动计划。
我：废话，这还要你说。

虽然嘴上说是“废话”，我心里却在反思我们以往的回顾会议真的是这么开的吗？我们真的做到了小崔提到的三个要点吗？在反思的过程中，我突然发现，回顾的过程和单元测试竟然有点像，不是有点像，是相当地像。

一个好的单元测试首先会有一个预期结果，跑完测试之后会得到一个实际结果，当实际结果和预期结果不一样时，你会分析现有的代码，找到问题所在，然后修改代码让测试通过。敏捷回顾不也是这样吗？首先你得有个目标或预期结果，然后你得行动和努力去实现预期结果，这不就是写实现代码吗？当实际结果和预计结果有差距时，你得制定新的行动计划并执行，这不就是修复已有的代码让测试通过吗？做好一次回顾就像跑好一次单元测试。

巧合的是《原则》的作者总结出来的第一条原则也是这个套路。

原则

我司技术论坛的主要目的是为了增进项目组之间的技术交流，传播好的技术、工具或实践到每一个项目组，技术论坛总坛下面有三个分舵，分别是数据库分舵、前后端分舵和DevOps分舵，下面就以2017年我们对每个分舵的一个共同的预期为例，解释一下怎么用单元测试的套路进行回顾：

预期结果：每个分舵要定期聚在一起交流，交流不能流于形式，要使分舵大部分成员切实感受到交流的价值。

实现代码（做了哪些行动和努力）：每次聚会都会好吃好喝招待与会人员；参加好的外部培训或会议；分享大家感兴趣的话题。

实际结果：某些话题/人的分享质量不高；分享的内容比较散，不够聚焦；项目紧张的时候会有不少人缺席。

修复代码（还要做哪些行动和努力）：等明天的回顾会议之后再和大家分享：）

谈到单元测试，一般都绕不开TDD，把单元测试做到极致就是TDD，TDD的一个核心理念就是通过把实现难度大的预期结果分解成一个一个实现难度小的预期结果，实现小步快跑和尽早反馈。同理，如果我们把回顾做到极限，年度回顾就会变成每月回顾、每周回顾甚至是每日回顾。

总结一下，敏捷回顾和单元测试的套路本质是一样的，它们都逃不出下面4步：

1. 预期结果是什么？
2. 实际结果是什么？
3. 做了什么行动和努力？（写了哪些实现代码）
4. 实际和预期的差距在哪，还要做哪些行动和努力？（怎么修复和改进代码）

这个套路很简单，相信大家都知道，但是你就是这样做的吗？你真的做到了吗？