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