敏捷團隊中，專家能勝過通才麼？

    在敏捷社群中有一個普遍的共識，那就是要組成包括通才和專家的跨職能團隊。Dave Gray在他的blog中發表了一張有趣的圖表，試圖顯示通才和專家之間的關係。Dave認為，通才對多個領域的規則都有基本的理解，他們不一定具備解決問題所需的特殊技能，不過能很好地詮釋問題。從另一個方面來說，專家對特定的領域有深入的瞭解。他們在解決問題和執行計劃方面的能力是一流的。Dave認為專案的成功執行需要這兩種角色的參與。

Jurgen Appelo強烈反對這種通才加專家的理論。在blog上，他不僅對專家的作用大加讚揚，而且不鼓勵組織中的任何成員向通才轉變。根據Jurgen的說法：

跨職能團隊（一些敏捷專家推薦的方式）完全忽視了社會得出的經驗，1776年哲學和經濟學家亞當·斯密在他的重要著作《國富論》中曾指出：專家能夠帶來更高的生產率和繁榮。
JurgenAppelo還說：

當軟體開發人員要去設計網站的時候，我都要哭了。一些人幾乎分辨不出畫素和釐米之間的差異。我見過軟體工程師所做的網站功能設計，如果照其執行的話，網站訪問者的身體會收到嚴重傷害。
為了增加說服力，Jurgen引用了David J. Anderson書中的內容：

David J. Anderson在《軟體工程的敏捷管理》一書中提到了Capers Jones的研究，說明專家小組的表現通常能優於由通才組成的小組（第272頁）。
他認為，使用專家所導致的效率降低不會比使用通才更嚴重，而通才處理工作的速度明顯要落後於專家。

另一方面，敏捷社群中的一些成員堅信：團隊應該不惜一切代價避免專家的存在。David Christiansen認為：使用通才而不是專家，這才是王道。在談到如何組建好的團隊時，他這樣建議：

應該儘量避免使用專家。他們都是隻會一種技能、而且脾氣暴躁的傢伙，他們對於形成良好的核心團隊沒有興趣。此外，他們只做固定的工作，避開其他的任務。為了等待下一個“適合”他們的任務，專家們會耗費上許多時間。所以他們要麼造成了專案資金的浪費，要麼根本就處在半工作狀態。所有這些情況增加了失敗的風險，並造成棘手的計劃依賴。從另一個方面來說，通才在專案的整個生命週期中一直在增加價值，他們在所有的階段都能提供幫助，這意味著日程安排不是什麼大問題。實際上，如果整個隊伍都是由通才組成，能在很大程度上消除專案主要路徑對人員安排的依賴。
Scott Ambler採取了中間立場，他認為團隊應該由通才型的專家組成。

不妨建立通才和專家都包括的團隊，通才在團隊內部起到粘合劑的作用，著眼於更巨集觀的問題；而專家則關注專案中較複雜的細節。這種方式的效果不錯，因為通才的長處剛好能平衡專才的短處，反之亦然。通才和專才的結合因為達成了某種平衡，通常很有效。更好的方案是建立通才佔多數的團隊，並配備一到兩個專家——通才型的專家。
Scott認為，通才型的專家能夠很好地把握事物之間如何配合，並能夠因此更加了解團隊工作的內容。

Jeff Atwood的觀點與Scott類似，他也喜歡通才型的專才。他認為，太多軟體開發人員在一種專業領域內浸淫得越來越深。程式設計是一個狹窄的領域，工程技術的世界如此廣闊，他們應該把自己培養成全面的軟體開發者。

總的說來，並不是所有的敏捷社群成員都贊成專家機制。應該根據團隊的人員和專案具體情況，來安排通才和專家的比例，或者努力增加通才型專家的數量，他們可以攜手並進，推動專案取得成功。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/1384/viewspace-364453/，如需轉載，請註明出處，否則將追究法律責任。