許多對敏捷式開發方法有興趣的客戶，經常會問我一個問題：「老師，敏捷式專案管理鼓勵以小規模團隊來做專案，可是我們公司的專案都很大，專案團隊的成員也很多，我們能用敏捷式管理方法嗎？」
先暫時把大專案要怎麼導入「敏捷式開發與專案管理方法」的這個問題放在一邊，我們先來簡要地回顧一下敏捷式方法鼓吹的小團隊到底有哪些好處再說。
只跟少數人面對面地溝通
沒錯，「敏捷式開發與專案管理方法」的確鼓勵以７到９人左右的小規模團隊來做產品、做專案，而且還鼓勵讓這些人都在同一個辦公空間內工作，以利這些人能即時地、無延遲地溝通所有的事情，迅速排除所有會阻礙專案進度的障礙。
面對面地溝通，一直都是最快、最不易產生誤解的溝通方式，也因此，團隊的生產力才有可能達到最高的境界！但是，這並沒有解釋到為什麼需要是「小」團隊！
假設，團隊內只有兩個人，那麼，這個團隊內的總溝通管道就是１；如果團隊內有三個人，那麼，總溝通管道就會變成是３；如果團隊內有四個人，總溝通管道就會變成是６；如果團隊內有五個人，總溝通管道就會變成是１０，當人數到達９人時，總溝通管道數將達到３６！
從上例來看，團隊內的人數只是等差級數地從２增加到９，團隊內的總溝通管道卻是等比級數地從１增加到３６！其實我們可以用以下的簡單公式來表示，團隊人數和總溝通管道之間的關係：
總溝通管道數＝Ｎ（Ｎ－１）／２，其中Ｎ代表團隊人數
試想一下，我們能夠同時處理跟多少人的溝通量，然後還不會影響到自己的工作效率的？
所以，團隊內的總溝通管道數當然是愈少愈好，每個人需要跟其他人的溝通（Ｎ－１）當然也是愈少愈好！９個人的團隊，每個人「最多」只要跟其他８個人溝通就可以了！
用腦袋快速記憶處理所有工作細節
鼓勵小團隊，其實還有另外一個重要的原因，那就是，因為這個團隊「小」，所以團隊內的每一位成員，都可以很清楚地知道其他人在做些什麼？跟我有沒有關係？需不需要調整、協調彼此的工作順序和步調？
試想一下，我們能夠在腦袋裡同時記住多少位他人的工作狀況，然後還可以在進行自己工作的時候，不會遺漏掉需要跟他人工作相搭配的細節部份呢？根據經驗，這個地方往往就是專案之所以產生大量 bug 之處！
您也許會說，「需要跟他人工作搭配的細節」用文件記錄下來不就好了？
我並沒有說文件不重要，但是，人性有時候就是這樣，有經驗的您可以再仔細回想一下，您在工作的時候，有多少時刻是真的拿著文件，照著文件在做事，而且還不會誤解文字敘述的？
有太多的實務經驗和案例告訴我們，很多人根本就不看規格書，就直接自己想像，或憑著自己過去的經驗，就開始動工做事的！這也是許多產品 bug 產生的根源之一。
與其這樣，倒不如快速跟別人面對面溝通完，讓自己的腦袋記住該記住的細節，然後趕快做完，也立刻驗證完，接著繼續進行下一個輪迴！
意想不到的美好副作用
好了，談到這裡，我們可以知道，只要團隊夠小，團隊成員的心態夠健康，透過長期的朝夕相處和大量的面對面溝通之後，團隊成員之間的工作默契就會愈來愈好，團隊的凝聚力就會愈來愈強，團隊的效能當然也就會愈來愈高了！
有哪個想表現的熱情工作者，會不喜歡待在這樣的團隊之內呢？又有哪個有智慧的老闆，會不喜歡擁有這樣的高效能團隊呢？
真理永遠就是那些簡單的道理
回顧完了小團隊的這麼多好處，我們再回頭來看一下，大專案到底該怎麼導入敏捷式方法。
道理很簡單，其實就是想辦法把大專案拆分為「各自獨立性很高」的幾個小專案，然後再把每個小專案指派給一個敏捷團隊（Scrum team）去負責。各個小團隊定期產出的小成果，會被定期做個大整合，這樣也就可以看到大專案有定期的整合後產出成果，這也就是所謂的「Scrum of Scrums」的精神所在。
萬一這些小專案還是太大，那就再把這些小專案拆分出「各自獨立性很高」的幾個大功能，再把每個大功能各自交給一個敏捷團隊去負責就得了！
當然，依據不同的產業屬性，以及不同的專案型態，這拆解專案來分工，再定期整合各自成果的過程，一定會有許多的細節要注意，也會有許多的障礙會出現，本文無法能詳談得完，就留待日後再另文探討囉！
本站所有文章未經事先書面授權，請勿任意利用、引用、轉載。
