辩论的目的不是让自己的意见获胜, 而是让团队找到更好的规则, 达成共识。

为什么会反复出现一件看起来不应该发生的事却一再发生, 直到Team中的某个人忍无可忍跳出来干预呢? 一个原因在于你认为不应该发生的事, 未必别人也认为不该发生, 即使是那些所谓的最佳实践, 或者, 尤其是那些所谓的最佳实践, 因为它们往往被缺省配置, 没有经过Team的讨论, 实际上是Team基于传统, 基于圈子文化, 被动的无意识的接受了这些规则. 于是它顺理成章的也会被无意识的违反.

于是经常发生的, 忍无可忍的人跳出来, 带点气场, 带点愤世嫉俗, 带点恨铁不成钢, 把大家数落一通, 让大家觉得自己对Team很没有责任心, 很心虚的但又有点哑吧吃黄连似的把规则修复. 但问题在于, 这依然是隐式的规则, 依然是那个忍无可忍的A的规则, B的规则, 但不是C的规则, D的规则, 不是Team的规则, 不是你的规则. 换一个环境, 换一个Team呢? 强势的人不在了呢? Team是否还能按规则行事? 你是否还能按规则行事?

问题在于我们缺少了接受规则前的一个重要环节: 理性批评. 批评性讨论. Team中的每个人都应该表明自己的观点, 立场, 并说明理由, 意见不一致的话就要辩论. 但辩论的目的不是让自己的意见获胜, 而是让Team找到更好的规则, 达成共识. 没有人可以说我无所谓, 到时大家怎么说我就怎么做. 也没有人可以仅仅表明观点而不说明理由. Team也会尊重每个人的意见, 给予平等的机会来表达和辩论. 这么做的前提是每个人需要有独立的观点. 大家都是30岁的人了, 而不是13岁. 我们不应该像学生那样习惯于老师或者有经验的人来告诉我们应该怎么做. 大学的目的在于培养人的独立性, 中国大学目前在这一点上是失败的. 这是你的团队, 难道不希望让你的想法成为团队都遵守的规则或者更好规则的一部分吗? 是不是陈词滥调? 没错, 至少在回顾会议中, 我们也是"这么"做的. 然而我们注意到的现象是, 每次发言争论的总是那几个人, 其他人都选择了旁听. 一旦他保持沉默, 那我们根本就无从知道他真实的想法, 既不知他是否同意, 也不知是否不同意, 最终讨论的结果的客观性也就无从保证, 无法代表Team的观点, 仅仅是那几个活跃的人的观点. 这是我们做的不好的地方, 注意到了这种现象, 却没有采取进一步的措施, 仅仅是每次鼓励大家多参与. 然而我们这次做一点改变, 强迫每个人履行发表观点的义务. 是的, 发表观点不仅仅是权利, 也是义务. 虽然这跟"我们要尊重每个人的选择"的观点有点冲突, 但这是让我们真正履行"尊重每个人的选择"的前提, 因为你不说的话, Team根本就没法知道你的选择.

于是开始轮流说出自己的观点, 我们终于第一次了解了团队真实的想法. 统计结果是60%的人选择了根据现状打破传统惯例, 认为即使Smoke测试失败的时候也可以提交新代码. 多少有点出乎意料, 不是吗? 尤其是对那些认为测试失败就不应该再继续提交的人而言, 他们居然是少数

传统上到此就可以结束了, 少数服从多数. 理性批评不是这样的. 民主与专制的区别不在于多数人统制还是少数人统治, 而在于是否可以不经过流血牺牲仅仅通过批评就能限制权力的滥用. 于是辩论开始. 各种原先藏在心底被压制的concern被说了出来, 各种可能的方案也被提及. 又有人习惯性的选择沉默, 没办法, 这次只好强迫, 只好强调希望结束辩论走出会议室的时候, 有尽可能多的人能有一种自己的想法终于成为团队的想法的喜悦. 辩论朝着它应该的方向进展, 即重点不是证明你是错的我是对的, 而是讨论后我们对事情看的更清楚

最终的结果是所有的人都决定不再继续提交, 当smoke测试失败的时候. 并且愿意承担带来的后果, 以及主动解决带来的问题. 当时列出了这些问题, 以及需要尝试的方案, 并约定了规则的有效期. 理性批评应该是伴随始终的. 规则被接受后不意味着永远被接受, 回顾是必要的, 我们总能通过理性批评前进到更好的规则

对我来说, 关心的不是最后的具体结果, 而是结果产生的过程. 所以把结论写下来,每个人都签字,张贴在工作区, 这都只是心理学上的trick. 真正重要的是结果不是不经思索接受的传统, 也不是强势成员的意见, 而是团队集体理性讨论的结果.

除此之外, 还有几点想强调:

1. 团队文化方面的风险. 你的团队未必是你以为的. 一个运转了一年多的所谓敏捷团队, 居然到现在才得出一个早就被公认的规则, 不是很失败吗? 时间是久了点, 这一点是失败的. 但我想说的是, 真正的风险是根本不知道自己的团队是否有共识. 我们的团队里有不少从别的团队里刚过来的, 他们带来了他们的观点, 并不意外, 在辩论的过程中发现并不是所有的人都认同那些你认为他们认同的实践和规则. 采取理性批评的手段取得真正的共识是必要的

2. 知识是如此易错, 简直不值得有任何"权威". 无意识接受的或者被灌输的理论, 都是风险. 极端一点的建议是每次组建团队开始新项目的时候, 采取的实践都从零开始. HW的人称之为"空杯"的心态. 难道TDD跟持续集成也要讨论一下才决定用不用吗? 严格一点的回答是, 是的. 当然你也可以在缺省配置下工作, 但出问题或者有苗头的时候要立即采取措施取得共识. 这里推荐一下关于REST的那篇论文. 除了REST本身, 那篇论文另一个有价值的地方是提供了推导出一种架构的一般性方法. 即从问题出发, 不断的添加约束. REST是你的缺省选择吗? 它其实是从"空风格"开始的. 如果你的问题域并不包含所有REST的约束, 你也许可以采用别的风格.

3. 分歧是很珍贵的, 它通常能导致更好的理论, 就看你怎么对待它