原文標題：How To Scale a Development Team

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

?

作者通過自己在Heroku的經驗，討論了開發團隊是如何從家庭式作坊發展到專業化團隊的過程，在每個階段中都給出了關鍵注意點，本文對于想創業和正在創業以及創業成功的人士都有可以學習的地方，讓我們從頭開始吧！

作為黑客，我們對于擴展web服務器、數據庫和其他軟件系統的需求已經駕輕就熟。對于成長型公司的一個同等重要的挑戰是擴展你的開發團隊。

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

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

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

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

第2階段：第一批員工

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

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

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

這個階段，專注是關鍵。每個人仍是通才，但是在特定的時間（即里程碑）整個開發團隊應該向著同一個目標。如果你嘗試一心多用，每件事都會做的很糟糕。大公司更有可能死于機會太多造成的消化不良而不是由于機會太少導致的餓死。細心的選擇自己戰斗領域并一直保持專注！

第3階段頻臨危機

成長到10-15位開發人員時，你正處于大團隊結構變動的邊緣。有人告訴我許多有前途的創業公司未能在這些階段中經受住轉變而失敗。

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

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

第3階段：分解團隊

劃分一支通才的團隊比說起來要難的多，劃分不得當，將會產生協調問題從而讓事情更糟糕。劃分合適，你將會看到幸福和生產力的大幅增加。

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

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

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

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

專業化

分解團隊的另一個原因是專業化。工程類專家包括OPS工程師/系統管理員、基礎構架開發人員、前端web開發人員、后端web開發人員、業務工程師/數據分析師以及開發人員，他們關注特定的語言。語言專家越來越普遍，因為許多網絡規模的公司使用像Erlang、Scala或者Clojure函數語言編寫高并發的組件，通常由不同的一組開發人員來處理而不是Ruby、Python或者PHPweb組件的作者。

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

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

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

Heroku公司的第一批團隊

Heroku的初始團隊分類看起來像這樣：

• API團隊——擁有面向用戶的web應用程序和匹配Heroku的客戶端gem。
• Data團隊——構建并運行我們PostgreSQL作為一種服務數據產品。
• Ops團隊——指導并保護產品系統的可用性。
• Routing團隊——管理一切必要的路由到用戶web的HTTP請求過程。
• Runtime團隊——處理部署的包裝碼和開始/停止/管理用戶進程。

這些隊伍擁有一到五個組件，例如，API團隊擁有運行在api.heroku.com和Heroku客戶端上的Rails的應用程序gem。Data團隊擁有數據庫服務的配置和監測工具，以及所有單獨運行的數據庫。（Peter van Hardenburg是位有膽識的內部管理者，他創立數據團隊并且現在領導著我們。在這個視頻后部分他談到了一點相關的故事。）

團隊的規模和角色

對于我們來說，理想的團隊構成由兩個開發者和一個公司的老板組成。一位開發人員長期來說是不足夠的（他們需要在代碼上的第二雙眼睛，另外，一個人是孤單的）。三位開發人員也可以工作的很好。發展到四至五位事情開始變得有點擁擠；未必有足夠的空間區域讓他們全部工作而不踩到其他人的腳。幾乎所有的Heroku的團隊都有兩位開發人員。

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

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

防止開發人員屬于多個團隊。他們是制造者，需要能夠專注于他們團隊的當前項目，避免分心或者試圖參與多任務。然而，有時，公司老板可以屬于多個團隊。這并不總是一個全職的工作，通過同一個老板的兩個或者多個相關的團隊進行跨團隊交流是有益處的。

凝聚力

在早期階段，你應該避免一心多用，為了公司應該保證所有的開發人員關注單一的目標。隨著每個團隊領域的建立，這種情況已經改變。現在你可以并且應該選擇多個目標。每個團隊應該朝著自己的目標執行自己的任務，不用擔心別的團隊在干什么。

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

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

但是，這篇文章已經足夠長，就像團隊的成長。另有時間我們再討論凝聚力和戰略方案吧。

?

轉載于:https://www.cnblogs.com/derek-hu/p/4062362.html

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。