1、使用分布式的版本管理系統
如果你覺得不需要使用版本管理系統，那我們溝通會有代溝，如果你是cvs、svn的粉絲，或者由于某種原因沒有使用過分布式版本管理系統，比如git，那強烈建議你去看一下“why git is better than x”。
2、一鍵式發布
這里發布的目標位置，既可以是開發機，做本地測試；也可以是測試機，為QA準備好捉蟲游戲的森林；還可以是生產環境（或者beta環境），供用戶直接訪問。
如深度xp一鍵恢復系統一樣，一鍵式發布需要自動完成很多工作：代碼自動化測試（開發階段），打包壓縮，編譯（測試階段），數據同步（外網）。也許還有很多工作要加入進來，但核心是是否能通過一個腳本的執行就全部完成所有流程，這點至關重要。如果中間多出幾個環境，那將來一定會引入發布的災難。
3、TDD / BDD 請對你自己寫的代碼負責
不要為了TDD/BDD而TDD/BDD，只要能及時獲得自己寫的代碼運行情況的反饋就行，也無需一次把test case都覆蓋全。對于沒有任何單元測試的代碼，將來想引入單位測試，將舉步維艱！如果，你認為測試完全是QA的事情，那你就花大筆的錢去招聘一個規模龐大的QA集團吧，期望他們能讓你偷懶。
4、使用靠譜的bug記錄工具
人腦的潛力雖然無限，但大腦皮層只會對進入緩存區的數據做高效的反應。記憶再好的開發，也可能被各種牛魔鬼怪折磨的忘記了昨日的痛（曾經產生的bug）。所以，從團隊第一次提測，就應該使用靠譜的bug記錄工作。所謂好記性不如爛筆頭就是這個道理。
那一個靠譜的bug記錄工具應該要記錄這些數據：
● bug復現的整個操作流程
● 產品需求中的正常情況
● 出現bug后，變成為什么情況
● 誰將負責修復這個bug
● bug最后修復沒有
至于怎么修復的bug，是重新設計還是漏提交了代碼，我覺得無關緊要。如果一個bug修復的經驗值得分享，可以單獨做一次團隊的技術分享，而這往往是由于對現有產品的（技術或者其他的）信息獲取不夠導致的。
5、盡快修復bug
我的開發經驗告訴我，一個bug越晚修復，被修復的可能性越小，將來產生危害的可能性越大。試想，你剛提測或者發布的代碼，出現的bug，往往你能最快得到解決它需求的時間，而時間在項目管理上是非常重要的。反之，如果積累了很多bug，且有一定時間了，那修復它就需要對所有相關的系統進行了解，這將花費大量你可以用來度假，娛樂的美好時光。所以，從團隊一開始就貫徹這點，可以釋放成員修復bug的壓力。
6、給團隊成員一個安靜的環境
最近很多同學告訴我，白天基本上沒有什么效率，總是受到各種騷擾。我們做一個假設：假如A同學進入最佳狀態需要30分鐘，那么如果他比較慘，在30分鐘間隔內，他總是被打斷，那么他一天都無法最高效的工作。又或者同學B google查詢一個技術問，花費2分鐘可以解決，但問同學A只要20秒鐘（好吧，同學A表達很清晰）。這樣同學B節省了100秒鐘，而同學A至少損失了30分鐘。
從這個假設，我們不難發現，如果能避免團隊成員受到外來信息的騷擾，他就有可能更加高效的工作，從而寫出更好的產品。而常識告訴我們，人不可能一直高效的工作，所以，我們應該利用好無法集中精力的時間去進行一些溝通。但分出這個界限顯然十分困難，所以我覺得不妨這樣：規定每天的安靜時間段，在這個時間段，其他人都不能來打擾這位同學，而在非安靜時間段，可以隨意訪問，從而讓這位同學形成一個新的生物鐘（人體的自我調節能力是非常強悍的）。
7、給員工最好的工具
做同樣一件事情，如果使用工具A，消耗的時間為5分鐘，而使用工具B，消耗的時間為1分鐘，那我一定給員工提供B工具，即使B工具的價格是A工具的5倍。因為，假如人在連續高效工作中的抵抗干擾時間為1分鐘，那么意味著B工具能保證高效工作的時間連續，而A將可能分散了用戶精力，導致需要更多的時間才進入最佳狀態。事實上，之所以要更好的cpu，更大的內存，更好的編譯器，更好的編輯器，多顯示器，都是讓程序員盡快能回到核心業務上來，而在等待上花費更少的時間。
同時，別忘了，一把好的椅子也是維持更長高效工作時間的保證，所以，別吝嗇，給員工更好的椅子吧，他們會感到你的溫懷。