什么是文化
團隊文化就像一塊含有酵母的面團，酵母（團隊創(chuàng)始人）能將菌群植入面團（新的團隊），從而變出一塊好吃的面包（好的團隊）。
團隊文化包含了團隊成員們編寫代碼的方式和成員之間的相處之道，還包含了所有人都認可的經(jīng)驗、價值觀、目標。團隊或者公司創(chuàng)始人決定了團隊大部分特點，同時也會隨著時間不斷變化發(fā)展。比如，代碼審查、測試驅(qū)動開發(fā)、每個星期四去某個餐廳吃飯，等等。這些影響著團隊的生產(chǎn)力，也可以吸引和留住優(yōu)秀成員。
為什么要關(guān)心它
如果不在意團隊文化，那么沒法構(gòu)建團隊認同感和對自身工作的認同感，也會容易受新人影響而引入糟粕。
每位成員都是團隊文化的一部分，都要為定義、維護和保護它做出貢獻。強壯的文化能為你提供專注、效率和力量，這些可以讓團隊更快樂。
文化會自我選擇，那些專注于編寫干凈、優(yōu)雅、可維護代碼的項目會吸引擁有相同價值觀的人。
團隊的自我選擇是通過招聘實現(xiàn)的。
文化和人
優(yōu)秀的人會吸引優(yōu)秀的人加入。
團隊的領(lǐng)袖需要愿意聆聽團隊成員的意見，讓他們對產(chǎn)品有主人翁精神。
讓團隊成長，需要懂得建設(shè)性批評。
優(yōu)秀團隊文化中的溝通模式
同步溝通（如開會）人越少越好，而異步溝通（如Email）人越多越好。
高層面溝通
任務(wù)宗旨
好的任務(wù)宗旨要準確定義產(chǎn)品的方向和范圍，定義哪些該做哪些不該做，這些可能會為你節(jié)省數(shù)年的時間，不會因為方向的問題而浪費時間。
Google Web Toolkit（GWT）的例子：GWT的任務(wù)是要通過讓程序員利用現(xiàn)有的Java工具，為任何現(xiàn)代瀏覽器構(gòu)建全功能的AJAX，從而徹底改善用戶的網(wǎng)絡(luò)體驗。
這是個很好的例子，不但包括了方向，同時還限定的范圍。
開會要有效率
常務(wù)會議是最可怕的，通常一周一次，通常是參會者一個一個發(fā)布簡單的通告，這完全是浪費時間。
應(yīng)該只涉及相關(guān)人員，允許人們在重要議程后離開，也可以考慮不開會而用Email來替代。
愚蠢的是，很多會議會和身份地位等同起來。
敏捷的每日站會是值得推崇的，所人有站著開會，15分鐘搞定。可以委任一個主持人，防止時間被拖延。
盡量讓會議保持在5人以下，超過5人就難以做出決策。
開會的5條小貼士：
- 只邀請一定要參加的人
- 開會前要決定好議程，而且要事先通知所有人
- 達成目的后應(yīng)提早散會
- 注意別跑題（主持人要有果斷有禮貌的打斷）
- 盡量把時間安排在休息前后（如午飯，下班前）
地理上分散的團隊
決策的記錄和分享要用書面的形式。
溝通要保證和在一起辦公一樣是無摩擦的，可以利用各種工具（如聊天工具、Email、視頻、電話）和團隊溝通，讓他們知道你的存在和你在做什么。
偶爾線下見面也是非常重要的。
設(shè)計文檔
項目開始前忍住沖動，不要馬上開始寫代碼，要先寫設(shè)計文檔。
設(shè)計文檔一般由一個人負責(zé)，兩到三個人撰寫，讓更多人審核。
設(shè)計文檔不但勾勒出項目的前景，也告訴整個團隊你想做什么以及如何做。
設(shè)計文檔的好處：
- 沒開始寫代碼，比較容易接受意見和建議，幫助改進產(chǎn)品和優(yōu)化實現(xiàn)
- 定型之后可以幫助安排工作量
設(shè)計文檔需要隨著項目的進展而變化，不是一成不變的。
不要走另一個極端“唯設(shè)計文檔論”，如果寫文檔的時間可以把項目寫好幾遍的話，那就沒必要寫文檔了。
每日進行的討論
郵件列表
可以從一個郵件列表開始，信息量多了之后再拆分成多個。
可以用來作為信息的集中記錄點，方便以后檢索。
在線聊天
不但可以隨時溝通，還能培養(yǎng)社區(qū)感，新成員看大家聊天也能學(xué)到很多東西。
使用bug跟蹤系統(tǒng)
重要的一點是要有一套流程來處理和分發(fā)bug，分清楚優(yōu)先級。
溝通也是工程的一部分
代碼注釋
注釋一般用來說明代碼中缺失的部分，以及起得不好的名字，然后解釋一遍代碼的功能。應(yīng)該盡量解釋為什么代碼要那么寫，而不是代碼做了什么。
注釋在函數(shù)層面最有用，特別是對于API文檔。
風(fēng)格一致比風(fēng)格本身更重要。
源文件署名
不允許給源文件署名。
每個提交都要經(jīng)過審查
長遠看可以提高團隊集體榮譽感。
無論是提交前還是提交后，每一行代碼都需要有另外一個人檢查過，包括風(fēng)格、質(zhì)量還有粗心的錯誤。
保證每次提交盡量短小以保證審查的質(zhì)量，如果修改超過幾千行，除了挑挑格式的毛病，基本是沒法修改的。
真正的測試和發(fā)布流程
測試的自動化程度越高，在修復(fù)bug和添加新特性的時候就越自信。
發(fā)布流程很重要，應(yīng)該做到可以頻繁發(fā)布，如每周一次。
說到底真正重要的還是代碼本身
只有在組建團隊是為它培養(yǎng)強大高效的團隊文化，在團隊溝通上花些時間精力，這樣的團隊就會有更多的時間編寫和發(fā)布產(chǎn)品。
強大的團隊不是自發(fā)形成的，是由團隊領(lǐng)袖和創(chuàng)始人培育起來的。
這些努力可以極大的降低信任融入團隊的門檻。
絕大部分能成為文化的努力其實都是來自溝通。
參考：《TeamGeek》（極客與團隊）
