题外话：我其实想说的是一个被人所忽视的问题。形式有没有价值？我承认，形式化是不好的。但是这个世界有个东西，叫做仪式。
举个例子，在国外，有种组织叫兄弟会，（电影里很常见）他们的有些会设置很多可笑的考察仪式来考察你够不够入会的资格。有些会有危险，有些只是纯粹搞出些恐怖气氛吓你看你会不会被吓退。这种东西有价值吗？心理学告诉我们，设置准入门槛可以提高组织成员的忠诚度。如果你觉得这玩艺太可笑了，给取消掉。你会莫名其妙的发现后来加入的人对组织的认可度忠诚度都不高。这就是仪式的价值。

今天说的是Retro，全名retrospective，中文名“回顾会议”，网上有很多相关文章，就不再这里赘述了。这里提到的Retro是最常见的一种模式，分Well, Less Well, Puzzle三个维度的模式。该模式的Retro的特点是会让我们更多的关注less well，关注我们做的不好的那些。这点有好有坏。本文只揭示它好的一面。做为补充，还有一种海星图的模式，感兴趣的人可以自己查询。

我个人认为retro是敏捷开发中很重要的一道防线。是团队健康度的晴雨表，是沟通的桥梁，是共识建立的契机，是改进的开始。

对于团队本身就存在大量问题，而这些问题可能都在敏捷方法的问题域里时。Retro是一个很好的发力点。他的效果可能没有持续集成那么立竿见影，往往是润物细无声。他可以帮我们把痛点暴露出来，但是不一定是根本问题。就像医生看病也得先问你哪不舒服。而Retro就能帮团队说出来哪不舒服并达成共识。某种意义上讲，它是个报警器。

如果已经采用了大量敏捷实践的团队呢？比如我们团队，在我们团队的开发中，我们一直推进着各种改进，期望让我们的工作更有效率，交付更多价值，同时也让我们的生活更美好一些，这是一件双赢的事情。 可是我们也要看到改进是需要成本的，而且也是有风险的，所以有的时候难以推动。对于客户（ 有时是PM等内部角色）来说，他讨厌一切成本和风险，而更感兴趣的是新功能，当碰到短视的负责人，或者交付压力占了上风的时候，难以推动这点感觉尤为明显。不过商业社会里竞争如此激烈，这也无可厚非。虽然我们也知道出来混，欠下的迟早是要还的。

不过这不是我们今天讨论的角度。今天我们站在推动改进的角度来看这个问题，开发时，在开发第一线的我们往往是第一个了发现开发中的问题，然后我们会发现改进最困难的是沟通，明明这是个问题，但是让各方都接受这个问题并改进它需要证据，需要沟通，需要资源，最重要的需要时间。我曾眼睁睁得看着客户只是加几台机器提升持续集成的构建效率这件事竟然推动了近一年才成功，那么在这个问题被发现但不能改进的时间里，团队会怎样呢？首先士气会被打击，接着如果问题长期不能解决并影响了工作效率，一种不愿追求卓越的气氛会渐渐感染团队成员，进而使得大家会在其他实践上表现渐渐变差。（ 相对于每个人自己，而不是团队其他成员）改进的意愿也会不同程度的变低。这符合破窗效应。

这时候，很容易出现的一个倾向会是干脆我们不要retro了，反正也改进不了，完全是浪费时间。 这就成了自毁长城。不能干因为报警器老响就把报警器拆了的事。出来混欠下的始终要还，学鸵鸟是没用的。当retro不能给我们提供更多实际改进价值的时候，它还能提供最后一个价值：忏悔的仪式。
 
曾经一直不明白西方人为什么定期去教堂忏悔，周周去，周周都有值得忏悔的，甚至犯过的错还有很多类似的。看起来没什么用。但这就像房间，天天打扫天天都有的打扫的，心灵的房间也是一样。一位有信仰的朋友告诉我，定期经常向神忏悔会更愿意改进自己，如果一段时间不去对自己的要求就会放松。人的心理就是这么奇怪。这揭示了一个道理，人是会逐渐放松对自己的要求的，所以需要一种手段让我们保持对自己的高标准。

我个人认为retro就是一个很好的手段。尤其我前面说过了，这里讨论的这种Retro的模式的特点就是让我们更关注于Less Well。定期，经常，回顾，反思。当我们无法变得更好的时候可以帮助我们反观团队自身，不要变得更差。让破窗效应难以发生。

（本来只是想写一个敏捷团队碰到让人沮丧的情况时Retro提供的价值，结果越写越多，有点跑题了⋯⋯）