英文原文：The Best Developer Team Structure

　　在滅火時，有一種“水桶陣型”——隊伍中所有人排成一列或幾列，將水桶從水源處傳遞到火災現場。這樣在團隊協作時甚至不需要語言交流，但顯然不適用于軟件開發。

　　Scott根據自身經驗，針對軟件開發總結了以下幾點建議，不一定全面但是值得參考。CSDN編譯如下：

　　組織架構是完成工作的工具，你需要好的工具來增加工作效率。沒有永遠最佳的組織架構，每一個項目都有最適合它的架構。

　　我個人的工作經歷主要是關于網站早期開發，這是一門非常特定的工作，因此非常偏向于敏捷/迭代的工作模式，如果你是為銀行或者航空公司做開發，肯定需要不同的工具和組織架構。

　　根據我的經驗，通常3-5個開發者圍繞這一個PM（項目經理）能夠達到最佳的工作效率。PM是一個過于復雜并且常被濫用的術語，坦率地說，我非常討厭這個詞。這里我所說的PM是指“解釋、闡明項目需求的人”，因此從產品戰略的角度PM需要有強烈的想法，清楚需要構建的是什么，但他們更重要的任務是權衡從客戶到設計師等等的全部利益相關者的需求，并據此制定計劃。

　　工程師可以是PM，我也見到過很多成功的案例，但需要注意的是，實際上他們的職能完全不同。作為一個PM，你需要理解“團隊”和“一群人”之間的區別：團隊的工作方式更像一個單位；團隊中有角色之分，比如四分衛、組織后衛，游擊手等等，但每個人都為了同一個目標努力完成自己的任務。一群人則是指很多聚集在一起的人，而非一起工作的人。你需要構建的是一個團隊而非一群人。

　　組建團隊的方式有很多種，這里列舉一些：強制結對編程；通過將項目按組件分解，保證多人同時作業；技術設計與編碼分離；降低WIP（Work-in-Progress）能夠驅動結對乃至多人編程項目。

　　注：保持低的WIP度是一個非常神奇的解決方案，當你不知道該做什么時，降低WIP！

　　每當我的團隊增長到7-10個開發者時，我總會將它分為兩個團隊。不論是什么項目，10人的團隊都過于龐大，這時候你需要以子團隊為行動單位。團隊劃分應該很自然，需要能夠明顯地區分兩個團隊。有個非常有名的原則叫做“pizza原則”，就是說：如果兩張pizza喂不飽你的團隊，那么它太龐大了！

　　記住，團隊復雜度不是線性的，而是指數式，當你有更多的員工、更多的團隊，花費在溝通上的時間也就會更多。

　　新團隊的組建不能湊合，不是隨便雇5個人就能稱之為一個團隊，最好的方式是“有絲分裂”（類似于舉薦）。

　　如果你擁有多個團隊，那么就需要有人來擔當“首席架構師”一職。隨著時間和團隊人數的增長，這會很自然地成為一個任務。首席架構師不需發號施令，這只是一個頭銜，但總需要有人頂著這個頭銜！記住，他絕不是“軟件設計之神”。如果你真的這樣認為，你會失去招聘好員工的機會，因為好的員工應該對“什么是好的軟件設計”有自己的觀點。這個角色更像是“軟件設計協調者”，幫助所有人取得架構設計的共識。首席架構師如果做得稱職會非常辛苦，因為他需要車前馬后地與人辯論，并最終保證大家得到共識，但這正是關鍵！

　　如果你的公司非常大，就像財富500強那樣，也許這時候你需要有一個能輕而易舉地決定軟件架構的“軟件設計之神”，但我并沒有這樣的工作經驗。

　　根據我的經驗，最好還需要有一個“團隊主管（Team Lead）”。這個職位應該從項目經理那里分離出來，經理負責績效考核，主管負責幫助員工完成工作。當然，團隊主管的職責更應該依項目而定，有時甚至不是必須的。

　　團隊從組建到揉合一般需要六周時間，這僅僅是針對公司的正式員工，新員工融進團隊的時間還會更長。

　　另一方面，不要害怕修改團隊的組織架構。和運動一樣，隊員間的化學反應非常重要！有些人在一起工作時能發出更高的工作效率，同時讓員工做自己關心的事也很重要，致力于自己關心的工作通常也能帶來更高的工作效率。我通常會安排合適的人去做他喜歡的工作。

　　當然，沒有任何人愿意做的事，應該讓所有人都輪流去做。如果你的團隊是真正的團隊，這就不會是什么問題，他們會愿意投入這些骯臟的工作。

　　最后，隨著組織的增長，“軟管理”會變得越來越重要。你需要將組織或者公司的使命、價值觀、愿景這樣的東西文檔化，比如寫在紙上或者wiki上。只有愚蠢的老板會認為這是在浪費時間。

it知識庫：打造最佳開發團隊的幾點建議，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。