题外话：我其实想说的是一个被人所忽视的问题。形式有没有价值？我承认，形式化是不好的。但是这个世界有个东西，叫做仪式。
举个例子，在国外，有种组织叫兄弟会，（电影里很常见）他们的有些会设置很多可笑的考察仪式来考察你够不够入会的资格。有些会有危险，有些只是纯粹搞出些恐怖气氛吓你看你会不会被吓退。这种东西有价值吗？心理学告诉我们，设置准入门槛可以提高组织成员的忠诚度。如果你觉得这玩艺太可笑了，给取消掉。你会莫名其妙的发现后来加入的人对组织的认可度忠诚度都不高。这就是仪式的价值。
今天说的是Retro，全名retrospective，中文名“回顾会议”，网上有很多相关文章，就不再这里赘述了。这里提到的Retro是最常见的一种模式，分Well, Less Well, Puzzle三个维度的模式。该模式的Retro的特点是会让我们更多的关注less well，关注我们做的不好的那些。这点有好有坏。本文只揭示它好的一面。做为补充，还有一种海星图的模式，感兴趣的人可以自己查询。
我个人认为retro是敏捷开发中很重要的一道防线。是团队健康度的晴雨表，是沟通的桥梁，是共识建立的契机，是改进的开始。
对于团队本身就存在大量问题，而这些问题可能都在敏捷方法的问题域里时。Retro是一个很好的发力点。他的效果可能没有持续集成那么立竿见影，往往是润物细无声。他可以帮我们把痛点暴露出来，但是不一定是根本问题。就像医生看病也得先问你哪不舒服。而Retro就能帮团队说出来哪不舒服并达成共识。某种意义上讲，它是个报警器。
如果已经采用了大量敏捷实践的团队呢？比如我们团队，在我们团队的开发中，我们一直推进着各种改进，期望让我们的工作更有效率，交付更多价值，同时也让我们的生活更美好一些，这是一件双赢的事情。 可是我们也要看到改进是需要成本的，而且也是有风险的，所以有的时候难以推动。对于客户（ 有时是PM等内部角色）来说，他讨厌一切成本和风险，而更感兴趣的是新功能，当碰到短视的负责人，或者交付压力占了上风的时候，难以推动这点感觉尤为明显。不过商业社会里竞争如此激烈，这也无可厚非。虽然我们也知道出来混，欠下的迟早是要还的。
不过这不是我们今天讨论的角度。今天我们站在推动改进的角度来看这个问题，开发时，在开发第一线的我们往往是第一个了发现开发中的问题，然后我们会发现改进最困难的是沟通，明明这是个问题，但是让各方都接受这个问题并改进它需要证据，需要沟通，需要资源，最重要的需要时间。我曾眼睁睁得看着客户只是加几台机器提升持续集成的构建效率这件事竟然推动了近一年才成功，那么在这个问题被发现但不能改进的时间里，团队会怎样呢？首先士气会被打击，接着如果问题长期不能解决并影响了工作效率，一种不愿追求卓越的气氛会渐渐感染团队成员，进而使得大家会在其他实践上表现渐渐变差。（ 相对于每个人自己，而不是团队其他成员）改进的意愿也会不同程度的变低。这符合
破窗效应。
这时候，很容易出现的一个倾向会是干脆我们不要retro了，反正也改进不了，完全是浪费时间。 这就成了自毁长城。不能干因为报警器老响就把报警器拆了的事。出来混欠下的始终要还，学鸵鸟是没用的。当retro不能给我们提供更多实际改进价值的时候，它还能提供最后一个价值：忏悔的仪式。
曾经一直不明白西方人为什么定期去教堂忏悔，周周去，周周都有值得忏悔的，甚至犯过的错还有很多类似的。看起来没什么用。但这就像房间，天天打扫天天都有的打扫的，心灵的房间也是一样。一位有信仰的朋友告诉我，定期经常向神忏悔会更愿意改进自己，如果一段时间不去对自己的要求就会放松。人的心理就是这么奇怪。这揭示了一个道理，人是会逐渐放松对自己的要求的，所以需要一种手段让我们保持对自己的高标准。
我个人认为retro就是一个很好的手段。尤其我前面说过了，这里讨论的这种Retro的模式的特点就是让我们更关注于Less Well。定期，经常，回顾，反思。当我们无法变得更好的时候可以帮助我们反观团队自身，不要变得更差。让破窗效应难以发生。
（本来只是想写一个敏捷团队碰到让人沮丧的情况时Retro提供的价值，结果越写越多，有点跑题了⋯⋯）
在我们的开发中，有些实践的价值是容易感受到的，比如重构，比如TDD，比如持续集成。
有些实践的价值则不容易感受到，比如Retro（回顾会议），比如IPM（迭代计划会议）。
以IPM为例，在我们的IPM上我们一般会做两件事Kick off cards和Estimation。也就是选择下个迭代要做的卡和评估每张卡的点数。这两件事情似乎第一件事没必要所有人都参与，第二件事感觉一定程度上是瞎蒙，尤其是一群人来蒙，显得尤为的不靠铺。而且似乎我们IPM就是为了选出下个迭代能做完的卡，就是为了知识传递，就是为了给客户可视的数据和计划，让他们心理好过。
假设说我们不必所有人都参与就能保证选出适合下个迭代做的卡，我们通过每日Code Review等实践使得每个人都不会缺少相关卡的知识，而客户也不特别在意我们的进度（或者说我们的进度他们总是满意），是不是我们就不需要IPM了？是不是我们就不需要集体Estimation不需要集体Kick off了？
实际上，我们的项目就符合前面的假设，在项目的最后，我们真的取消了IPM。这时，才感觉出来IPM的价值。
整个团队的效率慢慢开始下降。对于目标的理解开始不一致。虽然团队整体的表现并不差，虽然没有出现任何实质的问题，但容忍度低的人开始不舒服。跟团队自己以前的状态比，确实有点退化的感觉。怎么会这样呢？
每当说到这种状态出现在敏捷团队中的时候，我最常听到就是人的问题，态度问题等等说法。其实我一直觉得，如果追究态度，空谈人的问题有用的话，我朝应该是世界第一而不是那个人人自我的美帝。人一直是有问题的，不然要管理学干什么？敏捷里提倡自组织团队，自我管理。但决不是松散组织，不管理。自组织它也需要组织，自我管理它也是管理。像IPM这样的活动，就是管理的一部分。
IPM上做的两件事，看起来完全不靠铺，实际上却非常有价值。整个IPM活动就是一个承诺的仪式。像古代行军打仗前的誓师大会一样，可以调动起团队在下一个迭代中的士气。通过集体参与评估和制定计划，通过各个角色的共同作用，使得每个人都参与到整个计划制定中来。自然而然的对下一个迭代许下承诺。而承诺一旦许下，就会像一个耳语的恶魔，暗中催促着人们的行为与其保持一致。
生活在我朝的人们，似乎对承诺这个东西的效果是完全不相信的。这也难怪，不过出于众所周知的原因，咱不谈我们为啥不信任承诺。从心理学的角度，承诺是有实际意义的。《影响力》“第三章 承诺和一致”中就讲了这个极为简单却极为有用的心理学原理：人人都有一种言行一致（同时也显得言行一致）的愿望。
其中有很多很有趣的实验，揭示了承诺的力量。 感兴趣的人推荐读一读。里面有个小例子提到，两个星期前一个愿意在自家的草地上插一个小牌子为交通安全做点贡献的小承诺，使得该社区76％的人都在两个星期后接受了在自家草地上插一个挡风景的大牌子的请求。而对照社区只有17％。巨大的反差可以让我们看到承诺的力量。
当然我们对承诺的不信任也是有道理的，当承诺真的难以完成的时候，几乎所有人都会违背承诺。在传统的瀑布式开发过程中，使得计划这种承诺难度大大上升，而可信度也就大大下降。这也是为什么我们需要迭代的原因。
一个成功的企业需要积累。当你坐在电脑旁，看着一个运行达十年之久的软件的源码时，相信我，你一定会更深刻的感受到积累这个词，确确实实是个中性词。
软件多种多样的功能支撑着一个企业帝国的运转，它源源不断的在为这个帝国创造着财富，毫无疑问它随着时间积累了很多挣钱的能力。可是如
同历史上其
他的帝国一样，在繁华的背后，很多黑暗的东西同样随着时间积累了下来，临时性的策略被固化在核心流程中，为扩展留下的空白成了每次扩展必须绕行的弯路，精妙的手法随着时间的变迁显得复杂过时，分工协作使得同样事情得处理方式大不相同，预先的设计又使得本不相同的东西硬造成了相同的样子，管理的疏忽使得简单的功能用了复杂的模式实现。
坐在代码面前，仿佛在读一本被囚禁了灵魂的魔书，你能在注释中读出兴奋与痛苦，你能在代码中看到骄傲与彷徨。每当完成一次重构就像解救了一个被困的灵魂。那代码又仿佛一个人的脸，你可以看到各个技术历史阶段在它脸上留下的岁月痕迹。畅游在代码中，有些时候我们好像穿梭在时光的河流中，你能看到一个愚昧的风格是如何从一个有价值的需求中演变而来。如今再看，仿佛一群羊在不断的跳过一个早已不存在的栅栏一样诡异。而有些时候，我们只能看到一些遗迹，原野中矗立的大石柱根本无法自己告诉我们他们到底是为何矗立在那里的。以及移动他们会不会带来什么灾难。
能力很强，问题很多。是任何一个已经有历史的公司都会有的。软件不过是公司的一个表现方面。就像一个拥有完整公司基因的细胞。准确的说，任何时候，任何公司都不可能没有问题的。但是何时解决？这个问题就跟什么时候重构一样，答案也是一样，随时。解决问题的时机会影响解决问题的难度。越晚解决，就越难解决。说起来容易，做起来谈何容易。是的，解决问题总是需要鼓励的，但是谈何容易四个字却很容易瓦解我们前进的意志。低下头埋到土里，是可以让一切都清静了。但不管我们做不做，甚至于即便我们在做，问题也永远不会停止它产生并进化的脚步。面对问题，只有应战，没有第二条路可以走。经济危机教会了很多企业只顾赚钱而忽略企业的问题会有什么后果。我相信有很多人会选择遗忘并在遥远的未来继续重犯同样的错误，但是我也相信，也会有很多人会选择记住并把教训提炼成一种知识或制度，让后世人学会警惕。
进来听闻最大的CMM堡垒DNV要搞敏捷。大票的猎头纷纷出动，四处搜罗敏捷咨询师。使敏捷这个本来只有小众在实践的一类开发方法陡然变得要大众化了。本来以为是件好事。却在昨天看到z叔大喊，敏捷要倒。当时只是觉得有点道理。晚些时候却切身体会到了。
收到某非知名公司举办的scrum培训的邮件。顿时心里一紧。在这个时间，用这个操作手法有点可怕，各培训公司都找到了敏捷里面最好切入的一个点---Scrum。
Scrum是个筐，什么都能往里装啊。为什么这么说呢，他并不能算是一个完整的开发方法。只是一个框架。不领会敏捷的精神，没有其他具体的开发方法，他只能是一个大面的东西，如果用上这种东西就号称敏捷了。那真是可怕。而且，scrum证书也在这波浪潮中量产。一个人，花几千块钱，上两天的课，拿着一张纸就号称敏捷了。没办法，谁让咱们崇拜证书这种看得见摸得着的东西呢。但这样大量量产出来的敏捷项目经理。一实践肯定不对劲，就会用自己的理解去曲解敏捷。然后大家认为敏捷就是早晨开个会，月末开个会。最后的结果就是你在骂敏捷，我在夸敏捷，可是你嘴里的敏捷和我嘴里的敏捷根本就不是一个东西。
记得曾经见过一个CMMI的咨询师，张口闭口卡耐基梅隆，一付兄弟当年在英国的时候的样子。生搬硬套的CMMI流程。最后搞的那套流程根本不可操作，大家都为流程凑数据。当下如果大家都从CMMI倒向Scrum，这种人咋生存呢？会挂掉？错，摇身一变，举起敏捷大旗开始摇旗呐喊。没这两下子怎么能在忽悠界纵横这么多年呢。像这样的人都来搞敏捷了。敏捷不臭，那除非老天开眼了。那原来搞敏捷的人呢？本来就是小众，在这大浪里面，估计很快就看不见了。。。。从今开始，我还是少说两句敏捷了。。。