什么是文化
团队文化就像一块含有酵母的面团，酵母（团队创始人）能将菌群植入面团（新的团队），从而变出一块好吃的面包（好的团队）。
团队文化包含了团队成员们编写代码的方式和成员之间的相处之道，还包含了所有人都认可的经验、价值观、目标。团队或者公司创始人决定了团队大部分特点，同时也会随着时间不断变化发展。比如，代码审查、测试驱动开发、每个星期四去某个餐厅吃饭，等等。这些影响着团队的生产力，也可以吸引和留住优秀成员。
为什么要关心它
如果不在意团队文化，那么没法构建团队认同感和对自身工作的认同感，也会容易受新人影响而引入糟粕。
每位成员都是团队文化的一部分，都要为定义、维护和保护它做出贡献。强壮的文化能为你提供专注、效率和力量，这些可以让团队更快乐。
文化会自我选择，那些专注于编写干净、优雅、可维护代码的项目会吸引拥有相同价值观的人。
团队的自我选择是通过招聘实现的。
文化和人
优秀的人会吸引优秀的人加入。
团队的领袖需要愿意聆听团队成员的意见，让他们对产品有主人翁精神。
让团队成长，需要懂得建设性批评。
优秀团队文化中的沟通模式
同步沟通（如开会）人越少越好，而异步沟通（如Email）人越多越好。
高层面沟通
任务宗旨
好的任务宗旨要准确定义产品的方向和范围，定义哪些该做哪些不该做，这些可能会为你节省数年的时间，不会因为方向的问题而浪费时间。
Google Web Toolkit（GWT）的例子：GWT的任务是要通过让程序员利用现有的Java工具，为任何现代浏览器构建全功能的AJAX，从而彻底改善用户的网络体验。
这是个很好的例子，不但包括了方向，同时还限定的范围。
开会要有效率
常务会议是最可怕的，通常一周一次，通常是参会者一个一个发布简单的通告，这完全是浪费时间。
应该只涉及相关人员，允许人们在重要议程后离开，也可以考虑不开会而用Email来替代。
愚蠢的是，很多会议会和身份地位等同起来。
敏捷的每日站会是值得推崇的，所人有站着开会，15分钟搞定。可以委任一个主持人，防止时间被拖延。
尽量让会议保持在5人以下，超过5人就难以做出决策。
开会的5条小贴士：
- 只邀请一定要参加的人
- 开会前要决定好议程，而且要事先通知所有人
- 达成目的后应提早散会
- 注意别跑题（主持人要有果断有礼貌的打断）
- 尽量把时间安排在休息前后（如午饭，下班前）
地理上分散的团队
决策的记录和分享要用书面的形式。
沟通要保证和在一起办公一样是无摩擦的，可以利用各种工具（如聊天工具、Email、视频、电话）和团队沟通，让他们知道你的存在和你在做什么。
偶尔线下见面也是非常重要的。
设计文档
项目开始前忍住冲动，不要马上开始写代码，要先写设计文档。
设计文档一般由一个人负责，两到三个人撰写，让更多人审核。
设计文档不但勾勒出项目的前景，也告诉整个团队你想做什么以及如何做。
设计文档的好处：
- 没开始写代码，比较容易接受意见和建议，帮助改进产品和优化实现
- 定型之后可以帮助安排工作量
设计文档需要随着项目的进展而变化，不是一成不变的。
不要走另一个极端“唯设计文档论”，如果写文档的时间可以把项目写好几遍的话，那就没必要写文档了。
每日进行的讨论
邮件列表
可以从一个邮件列表开始，信息量多了之后再拆分成多个。
可以用来作为信息的集中记录点，方便以后检索。
在线聊天
不但可以随时沟通，还能培养社区感，新成员看大家聊天也能学到很多东西。
使用bug跟踪系统
重要的一点是要有一套流程来处理和分发bug，分清楚优先级。
沟通也是工程的一部分
代码注释
注释一般用来说明代码中缺失的部分，以及起得不好的名字，然后解释一遍代码的功能。应该尽量解释为什么代码要那么写，而不是代码做了什么。
注释在函数层面最有用，特别是对于API文档。
风格一致比风格本身更重要。
源文件署名
不允许给源文件署名。
每个提交都要经过审查
长远看可以提高团队集体荣誉感。
无论是提交前还是提交后，每一行代码都需要有另外一个人检查过，包括风格、质量还有粗心的错误。
保证每次提交尽量短小以保证审查的质量，如果修改超过几千行，除了挑挑格式的毛病，基本是没法修改的。
真正的测试和发布流程
测试的自动化程度越高，在修复bug和添加新特性的时候就越自信。
发布流程很重要，应该做到可以频繁发布，如每周一次。
说到底真正重要的还是代码本身
只有在组建团队是为它培养强大高效的团队文化，在团队沟通上花些时间精力，这样的团队就会有更多的时间编写和发布产品。
强大的团队不是自发形成的，是由团队领袖和创始人培育起来的。
这些努力可以极大的降低信任融入团队的门槛。
绝大部分能成为文化的努力其实都是来自沟通。
参考：《TeamGeek》（极客与团队）
