距离写完还有两章左右。最近突然对生活有了新的感受，按照我以往的性格，对身边的事情都非常在意，在意人的感受、在意彼此的关系、在意别人的看法。但突然之间，很多事情、很多人，似乎都没有那么重要。人与人再紧密，彼此之间依然会活成一座座孤岛。在这其中，最重要的是要懂得珍惜自己，珍惜生活，珍惜当下。也许就是在这个时候，突然感受到了一直在追求的时间管理的下一个阶段，对当下的珍视和关注——不思量过去，不焦虑未来，投入最大的心力和注意，就在当下。
从项目开始到结束，一个需求从头脑中的想法转变成“机会”，经过“探索”找到更多细节，由设计师进行模型设计，然后进入“故事工作坊”进行周期评估，最后研发、测试、上线。开发也许到此已告一段落，然后对于团队而言，它还有一个重要环节需要进行，那就是“回顾”（或称为总结、复盘）。
我们常常会经历过这样的回顾：
- 对回顾不重视，时有时无；
- 回顾总结形式化；
- 其乐融融或者争吵不休。
大部分回顾会议似乎都很少能持续推进具体执行力、对团队有易的结论和措施。回顾之所以被忽略，想来原因很大可能是因为回顾不是“特效药”，即不可能当下就对项目、对产品产生可见的帮助，而错误的回顾方式和会议技巧，无疑加重了对这一认知的偏见。在《用户故事地图》中，回顾的作用被说明为“沉淀优化产品和开流程”，它向我们提供了两种不同目的回顾会议：
- 与项目外的角色一起回顾
- 与项目内的角色一起回顾（项目反思与回顾会议）
与项目外的角色一起回顾
此类回顾需要邀请的“项目外角色”是指团队外的重要干系人。回顾会议能帮助他们理解刚刚完成的内容和整体规划的关系，在团队讨论中对产品的一些洞察和利弊分析。团队开发需要全员参与，因为它是非常不错的、让团队成员看到他人对产品真实反应的机会，有助于提醒他们自己在做的事情有多重要。
回顾会议不需要很正式，最好带一些吃的（这是这本书中反复强调的，也许吃的东西能让人们放松一些）。在这场回顾会议中，要评估两个内容：
1. 可交付的故事
内容包括方案的目标用户和预期结果、当前方案的发布进度、每个方案构建成果。
2. 后续探索性的故事
包括当前已在处理的机会、为理解问题和解决方案做的所有工作、当前所做的原型，并讨论用户对解决方案的看法。
与项目成员一起回顾
当然，与项目成员在一起回顾的氛围可以更轻松，找一个安全的地方，带上一些吃的。这种回顾会议有三方面内容：
1. 针对产品，需要成员对产品质量进行评估
这是指项目所有成员对产品质量的一次主观评级，质量共分为1〜5级，最是最好的。我们会通过问自己一些问题，来从三个方面进行评级。具体如下：
- 用户体验质量：
- 它有预期的那么好吗？
- UI和具体使用体验是怎样的？
- 功能质量：
- 测试过程是否流畅？
- 测试人员认为测试更多内容或时间可以发现更多BUG吗？
- 是否还有许多BUG未解决？
- 代码质量：
- 维护的容易度和扩展度？
- （应该是只有开发人员才有资格对代码质量进行评级）
2. 针对过程，成员们讨论最近一次开发周期中的工作方式
它主要包括两方面的内容：
- 下一次开发周期要做哪些改变？
- 最近一次开发周期中做的改变有效吗？这些策略是继续保持还是放弃？
以上部分常常是最容易被忽略的，因为它们并不与KPI直接相关，也无法对产品有快速见效的改变。也许这就是短视之处，人们常常需要“特效药”，但我相信团队协作和效率问题，并不是一两项举措就可以有所改变而受用终生。团队，毕竟是一群人的协作，只有慢慢协调和调整，引导群体逐渐适应，才能源源不断的为团队提供向前冲的动力。
3. 针对计划
了解scrum的朋友相对更容易理解大迭代和冲刺的关系。无数个冲刺组成一个迭代，每个冲刺相当于小的开发周期。而在每个冲刺结束时，都需要进行回顾，团队成员一起目前项目的进展，已完成和未完成的故事和数量。以决策是否需要对开发内容和进度有所调整。
——end——
全部内容链接：
用户故事地图（1）：体验用户故事
用户故事地图（2）：作用
用户故事地图（3）：故事与卡片
用户故事地图（4）：创建方法
用户故事地图（5）：开发流程之“机会”阶段
用户故事地图（6）：开发流程之“探索”阶段
用户故事地图（7）：开发流程之“设计”阶段
用户故事地图（8）：开发流程之“故事工作坊”阶段
用户故事地图（9）：开发流程之“研发-评估-交付”阶段
用户故事地图（10）：开发流程之“回顾”阶段
用户故事地图（11）：故事（需求）拆分
用户故事地图（12）：后记
