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記錄工具應該要記錄這些資料：
- 1. bug復現的整個操作流程
- 2. 產品需求中的正常情況
- 3. 出現bug後，變成為什麼情況
- 4. 誰將負責修復這個bug
- 5. 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，更大的記憶體，更好的編譯器，更好的編輯器，多顯示器，都是讓程式設計師儘快能回到核心業務上來，而在等待上花費更少的時間。
同時，別忘了，一把好的椅子也是維持更長高效工作時間的保證，所以，別吝嗇，給員工更好的椅子吧，他們會感到你的溫懷。
原文：Jinpu Hu