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