极客与团队（二）：培养出色的团队文化

什么是文化

团队文化就像一块含有酵母的面团，酵母（团队创始人）能将菌群植入面团（新的团队），从而变出一块好吃的面包（好的团队）。

团队文化包含了团队成员们编写代码的方式和成员之间的相处之道，还包含了所有人都认可的经验、价值观、目标。团队或者公司创始人决定了团队大部分特点，同时也会随着时间不断变化发展。比如，代码审查、测试驱动开发、每个星期四去某个餐厅吃饭，等等。这些影响着团队的生产力，也可以吸引和留住优秀成员。

为什么要关心它

如果不在意团队文化，那么没法构建团队认同感和对自身工作的认同感，也会容易受新人影响而引入糟粕。

每位成员都是团队文化的一部分，都要为定义、维护和保护它做出贡献。强壮的文化能为你提供专注、效率和力量，这些可以让团队更快乐。

文化会自我选择，那些专注于编写干净、优雅、可维护代码的项目会吸引拥有相同价值观的人。

团队的自我选择是通过招聘实现的。

文化和人

优秀的人会吸引优秀的人加入。

团队的领袖需要愿意聆听团队成员的意见，让他们对产品有主人翁精神。

让团队成长，需要懂得建设性批评。

优秀团队文化中的沟通模式

同步沟通（如开会）人越少越好，而异步沟通（如Email）人越多越好。

高层面沟通

任务宗旨

好的任务宗旨要准确定义产品的方向和范围，定义哪些该做哪些不该做，这些可能会为你节省数年的时间，不会因为方向的问题而浪费时间。

Google Web Toolkit（GWT）的例子：GWT的任务是要通过让程序员利用现有的Java工具，为任何现代浏览器构建全功能的AJAX，从而彻底改善用户的网络体验。

这是个很好的例子，不但包括了方向，同时还限定的范围。

开会要有效率

常务会议是最可怕的，通常一周一次，通常是参会者一个一个发布简单的通告，这完全是浪费时间。

应该只涉及相关人员，允许人们在重要议程后离开，也可以考虑不开会而用Email来替代。

愚蠢的是，很多会议会和身份地位等同起来。

敏捷的每日站会是值得推崇的，所人有站着开会，15分钟搞定。可以委任一个主持人，防止时间被拖延。

尽量让会议保持在5人以下，超过5人就难以做出决策。

开会的5条小贴士：

只邀请一定要参加的人
开会前要决定好议程，而且要事先通知所有人
达成目的后应提早散会
注意别跑题（主持人要有果断有礼貌的打断）
尽量把时间安排在休息前后（如午饭，下班前）

地理上分散的团队

决策的记录和分享要用书面的形式。

沟通要保证和在一起办公一样是无摩擦的，可以利用各种工具（如聊天工具、Email、视频、电话）和团队沟通，让他们知道你的存在和你在做什么。

偶尔线下见面也是非常重要的。

设计文档

项目开始前忍住冲动，不要马上开始写代码，要先写设计文档。

设计文档一般由一个人负责，两到三个人撰写，让更多人审核。

设计文档不但勾勒出项目的前景，也告诉整个团队你想做什么以及如何做。

设计文档的好处：

没开始写代码，比较容易接受意见和建议，帮助改进产品和优化实现
定型之后可以帮助安排工作量

设计文档需要随着项目的进展而变化，不是一成不变的。

不要走另一个极端“唯设计文档论”，如果写文档的时间可以把项目写好几遍的话，那就没必要写文档了。

每日进行的讨论

邮件列表

可以从一个邮件列表开始，信息量多了之后再拆分成多个。

可以用来作为信息的集中记录点，方便以后检索。

在线聊天

不但可以随时沟通，还能培养社区感，新成员看大家聊天也能学到很多东西。

使用bug跟踪系统

重要的一点是要有一套流程来处理和分发bug，分清楚优先级。

沟通也是工程的一部分

代码注释

注释一般用来说明代码中缺失的部分，以及起得不好的名字，然后解释一遍代码的功能。应该尽量解释为什么代码要那么写，而不是代码做了什么。

注释在函数层面最有用，特别是对于API文档。

风格一致比风格本身更重要。

源文件署名

不允许给源文件署名。

每个提交都要经过审查

长远看可以提高团队集体荣誉感。

无论是提交前还是提交后，每一行代码都需要有另外一个人检查过，包括风格、质量还有粗心的错误。

保证每次提交尽量短小以保证审查的质量，如果修改超过几千行，除了挑挑格式的毛病，基本是没法修改的。

真正的测试和发布流程

测试的自动化程度越高，在修复bug和添加新特性的时候就越自信。

发布流程很重要，应该做到可以频繁发布，如每周一次。

说到底真正重要的还是代码本身

只有在组建团队是为它培养强大高效的团队文化，在团队沟通上花些时间精力，这样的团队就会有更多的时间编写和发布产品。

强大的团队不是自发形成的，是由团队领袖和创始人培育起来的。

这些努力可以极大的降低信任融入团队的门槛。

绝大部分能成为文化的努力其实都是来自沟通。

参考：《TeamGeek》（极客与团队）