敏捷团队常常会发现，在做回顾（retrospectives）的过程中，他们往往很容易就总结出一箩筐需要改变的方面，但现实中却很难去实现这些改变。 Esther Derby 对软件开发过程中的人文因素颇有研究，参与撰写出版了 Agile Retrospectives: Making Good Teams Great一书。这次，她以自己的健身经历为例阐述了上面提出的问题，同时也列举了几条成功实现改变的建议。
很多敏捷团队都会不由自主地沦陷到同一个陷阱中，那就是光顾着对项目做回顾，却忽略了做回顾的真正目的。回顾是为了总结经验教训，根据总结改进之后的工作，制定出详尽的改进计划。简而言之，如果一个团队不能好好利用这些经验教训的话，做任何回顾基本上都只是浪费时间而已。
Esther 强调：“问题不在于回顾本身，而在于团队是如何看待这些回顾中总结出来的所需要做的变化。”为了详细阐述这个问题，她举了自己生活中曾经计划 要做的两个改变为例。其一是相对“简单”的改变——在没有私人教练的前提下去健身房锻炼，她以失败告终。而另一个相对“较难”的改变——减轻 10 磅，她最 后却成功地实现了。
从这两件事情上，Esther 总结出这样两条教训：
经验一：对于第一个改变，我没有一个明确的目标。无论去不去健身房，我都省下了雇教练的钱。也许你会说这也可以算是种成功。但这 件事背后其实还隐藏着我另一个目的，那就是要保持健康的形体。如果当时我把目标明确设定在“实现独立做健身运动”的话，最后的效果可能要好的多。团队也一 样，要看到在回顾活动的背后所隐藏的目的，确保明确申明的目标跟背后隐藏的目标两者相一致。 但即使有明确的目标，我想如果没有下面的经验二，最后也未必能够实现改变。
经验二：我本以为第一个目标很容易实现，因为我觉得这个目标太简单了，根本就不需要思考，也就没有好好去做原本可以让我成功的计划。团队有时候也会觉得自 己面对的是很容易实现的改变，他们没有意识到再简单的习惯其实都很难改变。如果他们一直认为改变是及其容易的一件事，这样的态度带来的往往都是最终的失 败。
Esther 接着又对如何提高团队实现改变的成功率提出了一些建议。这些建议可以大体概括为以下几点：
- 反馈：事先弄清楚将采用怎样的评估成功和追踪进度的反馈机制。
- 结构：以某种结构化的方式给明确给自己一个时机来实现所计划的改变。
- 支持：确保有人鼓励你支持你。
Esther 的最后一个建议是使用类似 Force Field analysis 的方法列举出推动或阻碍改变的各项因素，充分利用这些信息来完善之后的计划。 你可以完整地阅读她的这篇文章，和大家分享你独到的见解。
暂无签名
中国开发者画像洞察报告 2022
本次报告为你深度解读开发者人群背景，分析开发者群体面临的挑战，洞察开发者人群特征，预测开发者生态发展...
评论