過早擴充

軟體的一大好處在於，人們似乎需要它，而且需要得很快。組織通常會要求團隊加快軟體製作速度，而組織偶爾會尋求真正展現承諾的方式來協助，例如花錢為團隊增加更多人手。

現在有很多爭論在探討為軟體團隊增加人手是否真的有益。在我看來，很明顯的是，你無法獲得線性效益，團隊人數加倍並不會讓生產力加倍，因為溝通和協調成本會產生影響，並抑制成長。我完全不科學的經驗法則認為，任何生產力提升都可能與人手增加的平方根成正比，因此團隊人數加倍會讓生產力提升約 50%。但實際上，這會根據個人因素而有很大差異。我認識有些人，他們很可能憑一己之力就讓規模不小的團隊生產力加倍，而我們也遇過會降低團隊生產力的人。

但我想在此強調的問題是擴充。你有一個運作良好的小團隊，但你想要更多軟體，而且你準備花錢來獲得它。你很樂意花四倍，甚至是六倍的錢來讓進度加倍。一個重要但未被充分理解的因素是，你可以安全地將人員新增到團隊中的速度。

我曾不止一次遇過在短時間內加入太多人的專案。這會導致程式碼庫本身的凝聚力崩解。重複執行的情況會變得很嚴重，我認識的幾個朋友知道一個專案在單一應用程式中使用了三個物件關係對應架構。這種崩解會發生，是因為新加入的人員不了解程式碼庫目前運作的方式，因此他們會做出與程式碼庫不符的行為，例如加入競爭架構。如果新加入的人員太多，團隊領導者無法追蹤所有狀況，而程式碼庫就會產生問題。這些問題會互相強化，因為沒有人能找到一致的方法來做事，破碎窗戶症候群就會發生，而且你會得到一個正向回饋迴路。（而正向回饋迴路通常是件壞事。）

此外，過於快速的擴充會導致人際溝通機制崩解。人們需要時間才能習慣與彼此共事，而快速的擴充可能會阻止大型團隊建立成功所需的關係。

那麼，你可以安全地擴充多少？很難在此提供具體建議，因為我詢問過的任何經驗豐富的專案經理都會正確地指出，有許多變數必須考量在內。我詢問了我最信任的專案管理來源之一喬·澤內維奇，他表示他絕不會一次讓團隊人數增加超過一倍。即使增加一倍也會是一個冒險的決定，如果現有團隊已經有十幾個人，或有大量的初階人員，風險就會增加。

如果你大幅增加團隊規模，不應在新人融入團隊之前再增加更多人。這需要幾週的時間才能發生。開發人員需要了解程式碼庫和領域，商業分析師需要熟悉領域專家，每個人都需要彼此認識。在 Thoughtworks，我們期望人們能快速上手，畢竟我們雇用的是聰明、高度積極且學習速度快的人。但即便如此，仍需要一或兩週的時間。對於大多數團隊，你應該允許更長的時間。

當你將人員加入團隊時，你的能力並不會立即提升。人員需要花時間才能在新專案上發揮生產力。更糟的是，現有員工必須花時間協助他們加快腳步，因此你的速度一開始可能會下降。喬·Z對Thoughtworks團隊的觀察是，前幾週並不會有淨效應，因為新人員和現有人員的影響會互相抵銷。[1]大多數ThoughtWorkers都喜歡指出，結對程式設計有助於更快速地讓人員上線。Pat Kua也有一些好建議，說明如何有效地讓新人員加入團隊。

另一件要注意的事是，不要在專案太早階段就擴充。我從從事大型專案（超過50人）的人員那裡聽到的最堅定的建議之一是，專案應該從小規模開始，可能只有十幾位開發人員。他們應該透過建構專案的早期部分，找出系統的主要設計元素和互動。只有在設計穩定後，你才應該考慮將團隊規模擴充到最大規模。在穩定的過程中，花時間移除你認為不應該複製的任何設計元素。人員自然會複製已經存在的事物，因此你應該確保現有事物都能成為進一步開發的良好平台。這是過度關注程式碼整潔性的時候。

最後，在考慮擴充時，請仔細考慮是否值得。我很少遇到一個大型團隊，而團隊沒有覺得在不降低生產力的情況下，可以大幅縮減。正如我曾經說過的"擴充敏捷是你最不想做的事”。

進一步閱讀

我的同事Francisco Trindade談到他曾經在幾週內一次帶入幾位開發人員的良好經驗。