原文標(biāo)題：How To Scale a Development Team

原文鏈接：http://adam.heroku.com/past/2011/4/28/scaling_a_development_team/

?

作者通過自己在Heroku的經(jīng)驗，討論了開發(fā)團(tuán)隊是如何從家庭式作坊發(fā)展到專業(yè)化團(tuán)隊的過程，在每個階段中都給出了關(guān)鍵注意點，本文對于想創(chuàng)業(yè)和正在創(chuàng)業(yè)以及創(chuàng)業(yè)成功的人士都有可以學(xué)習(xí)的地方，讓我們從頭開始吧！

作為黑客，我們對于擴(kuò)展web服務(wù)器、數(shù)據(jù)庫和其他軟件系統(tǒng)的需求已經(jīng)駕輕就熟。對于成長型公司的一個同等重要的挑戰(zhàn)是擴(kuò)展你的開發(fā)團(tuán)隊。

大多數(shù)的科技公司在發(fā)展到大約10位開發(fā)人員時會遇到隊伍可擴(kuò)展性的棘手問題。有了前幾年在Heroku成功指導(dǎo)這個過程的經(jīng)驗，這篇文章將呈現(xiàn)開發(fā)隊伍成長過程的各個階段中我所看到的以及每個階段遇到的問題和潛在的解決方案。

第1階段：家庭式作坊（Homebrewing）

一開始，你的公司有2-4男的/女的，你們在某人的住所、咖啡廳或者可以協(xié)同工作的地方工作。溝通和協(xié)調(diào)是很容易的：僅僅幾個人挨個坐著，每個人都知道其他人在做什么。創(chuàng)始人和早期的員工傾向于自我引導(dǎo)的，因此幾乎是不存在管理的需求。每個人都是通才，每件事都多多少少的插手。你有一個單獨的組聊天頻道和單獨的all@yourcompany.com的郵件列表。沒有任務(wù)跟蹤甚至是bug跟蹤的真正需求。整個公司情況以及你們的產(chǎn)品每個人都能記的清清楚楚。

這個時候，你試圖創(chuàng)建并檢查你的最小可行性產(chǎn)品，這是一個你試圖想弄清楚你在這里到底做什么的奇特方式。這個時候任何一種組織機(jī)構(gòu)或者流程的存在都將是極其不利的。每個人不得不是個通才并且能夠解決各種類型的問題——專家們會在某種程度上（最好情況)專一而又（最壞情況）高度分散，因為他們想要引導(dǎo)產(chǎn)品到他們擅長的領(lǐng)域。

第2階段：第一批員工

一旦你有了一點資金并且能夠雇用更多的開發(fā)人員，讓團(tuán)隊發(fā)展到共5-9人時，你可能會發(fā)現(xiàn)點對點方式的協(xié)調(diào)（希望坐的靠近隊友從而能夠聽到每件重要的事）開始被打破。你要多做一些事（關(guān)注其他六個人的工作是耗時的）還要放棄一些事（你結(jié)束了試圖修復(fù)相同bug，回答相同的支持郵件或者回應(yīng)相同的Nagios頁面的沖突）。

這時候，你想添加僅僅一小點的組織機(jī)構(gòu)：也許一個周一的迭代計劃、日常的短時會議、跟蹤大的待辦項目以及白板上或者簡單工具（如Lighthouse）中的bug。也許你轉(zhuǎn)而使用像Zendesk可分配傳入支持請求的支持系統(tǒng)，并通過Pagerduty為頁面添加一個簡單的呼叫旋轉(zhuǎn)。你們單獨的內(nèi)部聊天頻道和電子郵件列表仍然可以正常運行。

這時候一定要抑制引入太多的組織機(jī)構(gòu)和流程的沖動。一些剛起步的公司在到達(dá)這一步的時，宣稱“我們已經(jīng)長大了，現(xiàn)在我們可以像真正的公司那樣去做了”并且立即嘗試切換到難以承受的戰(zhàn)術(shù)戰(zhàn)略上。例如：成熟的SCRUM、重量級工具如Jira、聘用項目經(jīng)理或者設(shè)計管理人員。不要做這些事。你已經(jīng)有了一個在特定方式下大家一起工作、運作良好的團(tuán)隊；在團(tuán)隊里你可能有一些天生的領(lǐng)導(dǎo)者，當(dāng)他們忙于自己手頭工作的時還可以指導(dǎo)很多的工作；同時當(dāng)你推出產(chǎn)品到用戶手中時，在很多方面你仍然在嘗試弄清楚你的公司到底意義何在。引入官僚主意到這個環(huán)境中幾乎可以肯定阻止你真正想做的任何事情，這是探索你的可擴(kuò)展商業(yè)模式的關(guān)鍵。

這個階段，專注是關(guān)鍵。每個人仍是通才，但是在特定的時間（即里程碑）整個開發(fā)團(tuán)隊?wèi)?yīng)該向著同一個目標(biāo)。如果你嘗試一心多用，每件事都會做的很糟糕。大公司更有可能死于機(jī)會太多造成的消化不良而不是由于機(jī)會太少導(dǎo)致的餓死。細(xì)心的選擇自己戰(zhàn)斗領(lǐng)域并一直保持專注！

第3階段頻臨危機(jī)

成長到10-15位開發(fā)人員時，你正處于大團(tuán)隊結(jié)構(gòu)變動的邊緣。有人告訴我許多有前途的創(chuàng)業(yè)公司未能在這些階段中經(jīng)受住轉(zhuǎn)變而失敗。

有這么多的開發(fā)人員、迭代計劃、短時會議或者任何其他類型的開發(fā)團(tuán)隊會議已經(jīng)讓這些與會者花費了太多的無聊時間。任何身處他人繁瑣的工作明細(xì)中掙扎的開發(fā)者個人將會很難找到目標(biāo)感或者共享的方向。

在編程中，當(dāng)一個類或者源文件開始變大，解決的方案就是分解成小模塊。擴(kuò)展開發(fā)組織使用相同的原則，你需要把組織分解成具有針對性的團(tuán)隊。

第3階段：分解團(tuán)隊

劃分一支通才的團(tuán)隊比說起來要難的多，劃分不得當(dāng)，將會產(chǎn)生協(xié)調(diào)問題從而讓事情更糟糕。劃分合適，你將會看到幸福和生產(chǎn)力的大幅增加。

一支好團(tuán)隊的關(guān)鍵是劃分好職權(quán)范圍，擁有清晰的接口供其他團(tuán)隊使用。團(tuán)隊?wèi)?yīng)該對他們所工作的產(chǎn)品部分擁有前景和方向。團(tuán)隊?wèi)?yīng)該擁有最大自主權(quán)來操作所擁有的一切，無需獲取許可或者來自其他團(tuán)隊的信息，除非少見的功能或者bug與其他隊伍有了交叉點。

軟件架構(gòu)與團(tuán)隊架構(gòu)的緊密對應(yīng)將會是個很大的幫助。到這個時候，你可能已經(jīng)把你的龐大應(yīng)用程序轉(zhuǎn)換成了多個組件通過REST、AMQP、或者其他RPC機(jī)制通信的分布式系統(tǒng)（如果沒有，你應(yīng)該強(qiáng)烈建議這樣做，和分解的開發(fā)團(tuán)隊步調(diào)一致）。軟件組件之間應(yīng)該有明顯的映射——每一個都有它們自己的源碼庫和部署位置/過程——和你的新生團(tuán)隊。

起初決定什么樣的人分配到哪個團(tuán)隊在某種程度上有點武斷。我的解決辦法就是大家坐下來并且深入的理解系統(tǒng)的哪部分是他們最有激情的。從這點我盡最大的努力來分配團(tuán)隊。第一次團(tuán)隊的分配，有些人找到了完美的家，其他不滿意的人需要公平快速的轉(zhuǎn)移到其他隊伍。隨著時間的推移，團(tuán)隊的領(lǐng)域就很好的形成，因此就能更容易的把新聘的員工插入到正確的崗位。讓開發(fā)人員跟隨他們自己的激情，他們將會自然的融入到團(tuán)隊并且做出最好的工作。

另外，這個時候你應(yīng)該找到了合適的產(chǎn)品/市場。如果你的公司發(fā)展到這個規(guī)模并且仍在尋找公司的意義所在，那么你們的麻煩就大了。如果是這種情況，抓緊停止規(guī)模的擴(kuò)大并縮減規(guī)模，直到你捕捉到了合適的產(chǎn)品/市場。

專業(yè)化

分解團(tuán)隊的另一個原因是專業(yè)化。工程類專家包括OPS工程師/系統(tǒng)管理員、基礎(chǔ)構(gòu)架開發(fā)人員、前端web開發(fā)人員、后端web開發(fā)人員、業(yè)務(wù)工程師/數(shù)據(jù)分析師以及開發(fā)人員，他們關(guān)注特定的語言。語言專家越來越普遍，因為許多網(wǎng)絡(luò)規(guī)模的公司使用像Erlang、Scala或者Clojure函數(shù)語言編寫高并發(fā)的組件，通常由不同的一組開發(fā)人員來處理而不是Ruby、Python或者PHPweb組件的作者。

在早期，專家是很少令人向往的。相對能做出貢獻(xiàn)的人的數(shù)量，在產(chǎn)品線上有太多人工作在不同層次上。因此每個人在每件事上都做出了貢獻(xiàn)。這種情況可能把一個開發(fā)人員分配到非常寬泛的工作崗位上，例如：在操作系統(tǒng)上更新內(nèi)核的OPS項目，為用戶界面編寫JQuery效果的前端項目。

一旦你達(dá)到了擁有十幾個開發(fā)人員的時候，你的產(chǎn)品已經(jīng)達(dá)到了使用性和成熟度問題變得更難的層次。因此縮放數(shù)據(jù)庫不僅是一個全職的工作，而且如果這個人同時通過學(xué)習(xí)成為一個JQuery的專家、iOS專家和Erlang的專家，更需要一個不可被收購的深層次的專業(yè)知識。

你需要的僅僅是幾個可以并愿意密切關(guān)注相關(guān)領(lǐng)域的人，因此他們可以在這些領(lǐng)域建立非常深厚的造詣。其中一些將會是現(xiàn)有通才中決定專業(yè)化的人而且還會有一些新員工。現(xiàn)在，當(dāng)你的公司還比較小的時候，你可以聘用這類并不是相稱的專家。通才在身邊通常是很有用的，其中有些可能進(jìn)入了管理層——為團(tuán)隊灌輸企業(yè)所有者的角色，而不是親自動手開發(fā)。

Heroku公司的第一批團(tuán)隊

Heroku的初始團(tuán)隊分類看起來像這樣：

• API團(tuán)隊——擁有面向用戶的web應(yīng)用程序和匹配Heroku的客戶端gem。
• Data團(tuán)隊——構(gòu)建并運行我們PostgreSQL作為一種服務(wù)數(shù)據(jù)產(chǎn)品。
• Ops團(tuán)隊——指導(dǎo)并保護(hù)產(chǎn)品系統(tǒng)的可用性。
• Routing團(tuán)隊——管理一切必要的路由到用戶web的HTTP請求過程。
• Runtime團(tuán)隊——處理部署的包裝碼和開始/停止/管理用戶進(jìn)程。

這些隊伍擁有一到五個組件，例如，API團(tuán)隊擁有運行在api.heroku.com和Heroku客戶端上的Rails的應(yīng)用程序gem。Data團(tuán)隊擁有數(shù)據(jù)庫服務(wù)的配置和監(jiān)測工具，以及所有單獨運行的數(shù)據(jù)庫。（Peter van Hardenburg是位有膽識的內(nèi)部管理者，他創(chuàng)立數(shù)據(jù)團(tuán)隊并且現(xiàn)在領(lǐng)導(dǎo)著我們。在這個視頻后部分他談到了一點相關(guān)的故事。）

團(tuán)隊的規(guī)模和角色

對于我們來說，理想的團(tuán)隊構(gòu)成由兩個開發(fā)者和一個公司的老板組成。一位開發(fā)人員長期來說是不足夠的（他們需要在代碼上的第二雙眼睛，另外，一個人是孤單的）。三位開發(fā)人員也可以工作的很好。發(fā)展到四至五位事情開始變得有點擁擠；未必有足夠的空間區(qū)域讓他們?nèi)抗ぷ鞫徊鹊狡渌说哪_。幾乎所有的Heroku的團(tuán)隊都有兩位開發(fā)人員。

“企業(yè)老板”在某成程度上是愚笨的術(shù)語，但是它是我們描述這個人為團(tuán)隊做一些產(chǎn)品管理、項目管理和一般管理組合的最好詞匯。企業(yè)老板在了解團(tuán)隊的工作對于企業(yè)的價值以及如何適用較大的產(chǎn)品中充當(dāng)重要的角色。他們可以跨團(tuán)隊溝通交流，通過商業(yè)價值幫助合理處理項目和任務(wù)，還可以提供團(tuán)隊的進(jìn)展及表現(xiàn)狀態(tài)報告給高級行政人員和/或整個公司來判定團(tuán)隊的持續(xù)存在性。

在企業(yè)家中我是一個黑客企業(yè)家的粉絲：強(qiáng)大的技術(shù)背景意味著他們對將要開始的工作擁有深入的了解，并有能力贏得被指揮人員的敬重。這種人并不是所有的團(tuán)隊都能找到的，但是如果能，盡力找出他們。在許多情況下，它涉及到需要具有相當(dāng)?shù)恼f服力才能讓黑客放棄他們重要的編碼生涯。

防止開發(fā)人員屬于多個團(tuán)隊。他們是制造者，需要能夠?qū)Ｗ⒂谒麄儓F(tuán)隊的當(dāng)前項目，避免分心或者試圖參與多任務(wù)。然而，有時，公司老板可以屬于多個團(tuán)隊。這并不總是一個全職的工作，通過同一個老板的兩個或者多個相關(guān)的團(tuán)隊進(jìn)行跨團(tuán)隊交流是有益處的。

凝聚力

在早期階段，你應(yīng)該避免一心多用，為了公司應(yīng)該保證所有的開發(fā)人員關(guān)注單一的目標(biāo)。隨著每個團(tuán)隊領(lǐng)域的建立，這種情況已經(jīng)改變。現(xiàn)在你可以并且應(yīng)該選擇多個目標(biāo)。每個團(tuán)隊?wèi)?yīng)該朝著自己的目標(biāo)執(zhí)行自己的任務(wù)，不用擔(dān)心別的團(tuán)隊在干什么。

同時能夠進(jìn)行三個、四個、五個大的目標(biāo)真是太棒了。在Heroku劃分團(tuán)隊后的幾個月，我們有一天三個不同的團(tuán)隊同時發(fā)布了主要的新功能。真是一種難以置信的感覺。

但是現(xiàn)在你有了一個新問題：缺乏凝聚力。你的松散的團(tuán)隊正在制定各自的路線圖以及各自的功能決定。但是為了避免你的產(chǎn)品零零碎碎，有人需要來決定總體的方向及產(chǎn)品的功能集。更簡潔的說：你需要一個戰(zhàn)略方案。

但是，這篇文章已經(jīng)足夠長，就像團(tuán)隊的成長。另有時間我們再討論凝聚力和戰(zhàn)略方案吧。

?

轉(zhuǎn)載于:https://www.cnblogs.com/derek-hu/p/4062362.html

總結(jié)

以上是生活随笔為你收集整理的如何扩展开发团队(转)的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。