一直想写一篇关于文化的文章，毕竟文化一词在 ThoughtWorks 有着的举足轻重地位。但奈何毫无思路，找不到任何切入点，话题太大也无法驾驭。

好在万能的21天写作课，好在万老板昨儿新鲜出炉的《文化四象限》，更妙的地方是文中给出了他对文化的定义。

说得简单一点，就是在一个组织内做什么事情，会被大家认可、鼓励。这就是文化。
                        — Xuefan 《文化四象限》

那么，文化源自于哪里？

我特别喜欢和赞同《DevOps Handbook》的作者 John Wills 在他的文章 《DevOps Culture Part 1》中引用的一句话：

You can’t directly change culture. But you can change behavior, and behavior becomes culture.

你没办法直接改变文化，但是你可以改变行为，行为最终会形成文化。

是的，文化源于行为。那么对于一个团队来说，怎么才能通过行为来形成文化呢？在 TW 快 9 个月的经历中，我总结了「文化建设三板斧」这一套还谈不上方法的方法。

强化正确的行为

在交付项目中我们每天都会基于故事卡来「Kick Off」 和 「Sign Off」，BA、Dev、QA 有时候还有 Ops，会就一张故事卡的价值、需求、验收条件等进行信息上的同步。

那么多的客户需求，那么多的故事卡，每一张都要这么去做，这种频繁且大量的沟通成本无疑是巨大的。但我相信公司的每个交付团队都依然坚持着这种方式。为什么？

沟通固然会带来成本投入，但我们认为团队成员之间对「目标」和「完成」达成共识会更有价值，信息的不匹配带来的成本可能会更加巨大。比如说返工，这种被精益思想所定义的浪费。

在持续交付的实践中，Pipeline 要始终保持在可工作状态。因此我们建立了 CD 安灯系统，可视化所有 Pipeline 的状态，并在 Pipeline 挂掉的时候产生告警。

“xxx,你把 pipeline xxx 搞坏了!”，在安灯系统告警后我们会采取一些善意的惩罚措施，目的是要求搞挂 Pipeline 的人赶紧去修复，Pipeline 必须要一直可工作。例如修不好就会一直告警，让整个团队都知道是你弄挂的，又或者给你一些比较违和但不失尊重的措施，「兔子耳朵法」和「粪发图强法」是我们惯用的伎俩。

可工作的流水线是我们软件交付实践中的最基本要求，流水线正向流以高度自动化的方式提升交付速度，反向流提供快速的错误反馈机制，能够让我们第一时间发现问题、识别问题和解决问题，最终提高整个软件交付的质量。

哪怕花样百出，保证 Pipeline 常绿就是我们所认可的正确的事情。又快又好，有谁不爱呢？

激励优秀的行为

我所在的项目中每 Q 都会有一次庆功会，在这个会议最后会有一个非常重要的环节，那就是为这个季度表现优秀的团队成员进行颁奖，我们称之为「每 Q 惊喜」。

惊喜在于，直到最后一刻也没有人知道嘉奖名单里会不会有自己。并且， PM 会基于客观事实，写一段幽默但是不失真诚的话来阐述成员被嘉奖的原因。在得到团队认可，精神上得到极大的鼓舞之后，还有物质上的奖励，一件带有特殊 LOGO 字样的纪念 T 恤。例如，「Tech Champion」就是给那些在项目上作出重大技术改进的成员的。

下面的内容是走心的 PM 在给我们刚过来的 (Dev)Ops 同事颁奖时的话术。

Pipeline 里最不起眼的下载代码也暗藏玄机。一次 Gitlab 迁移、两次 GoCD 配置优化，背后是更多次方案的讨论与摸索。磨砺技术珠矶；追求价值卓越。一句「Pipeline 将由我们来守护」的承诺，展现的是对技术的底气和践行「没有最好，只有更好」的决心！

荣誉感是一个很奇妙的东西。客观的描述的事实，不但是对被嘉奖者最大的尊重，也是向团队说明什么样的行为才是优秀且值得被鼓励的。团队中的每个人都进步了，那团队也自然而然的进步了。

改善不足的行为

无论我们最终发现了什么，我们必须理解并且完全相信：每个人在他当时所处的情况下，在能力范围内，做了最大的努力！

开场最具仪式感的宣言，加以入会成员对在场安全度的打分，一个好的回顾会议的基调基本就被定下了。

回顾会议客观的通过「Well」 和 「Less Well」描述事实，在一段时间内(通常是上次 Retro 到这次)，我们有哪些做得好的事情，有哪些做得不足的事情。主观的通过「Suggestion」来提出经过思考后的建议。目的是为了产出的可执行、可量化和可验证的「Action」，这些 Actions 才是 Retro 的精华。

作为团队的 (Dev)Ops，我们时常扮演着救火队员的角色。曾经在一次和客户重要的 Show Case 过程中，UAT 环境莫名的不可用导致整个 Show Case 整段垮掉...

后续团队专门为这件事情进行了复盘，问题的导火索是 (Dev)Ops 在清理临时表以节省数据存储空间的时候，误删除了 UAT 环境某个数据库里的一张数据表。

作为一名老运维，这种事情在大多数的团队中就算“给跪了”也是“难逃一死”，轻则上黑榜全公司批评，重则作为“临时工”给舆论一个交代...但我们根因分析的时候，却总结了这样一条原因

在午饭过后操作数据库，因为大脑中的血液流向胃部，供氧不足导致注意力不集中和犯困，所以出现误操作。

最后的 Actions 有一项是：避免午饭过后操作数据库。

是不是觉得特别有趣呢？其实最终我们需要执行的 Action 有好多好多，比如操作数据库需要 Pair 执行，成立数据库脚本 review 小组，梳理数据库访问权限等等等等。

这里是想说明，找到 Root Cause 可能并没有我们想象的那么重要，可执行的改进高于一切。

总结

三板斧的意义在于从团队的价值共识、卓越追求和持续改善三个方面入手，通过一系列的行为去坚持我们认为正确事情、认可我们认为优秀的人和改进我们发现的一些不足，最终形成一种生机型的团队文化。

在 ThoughtWorks 规模化的今天，会不断的有刚出校门的毕业生和混迹职场的老司机加入，不同背景的人必然会造成整个 TW 原有文化的稀释。有些时候我也会有一些担忧，这些现在被我们所认可的东西，在商业化和规模化的变革下，有朝一日会不会失去？最后回过头来，会不会可笑的发现那些曾经我们所拥有的东西，才是我们安生立命的根本。