全功能團隊 - 數據篇

　　在《建設全功能團隊》和《建設全功能團隊——實踐篇》兩篇文章中，我的同事胡凱曾介紹過建設全功能團隊的必要性和良好實踐，此后在圍繞這一話題的討論中，很多人都分享了自己的理解，或看好，或看淡。在 ThoughtWorks有許多團隊一直在建設全功能團隊方面實踐著，在這篇文章中我希望與大家分享我從這些團隊收集到的過去一年來的數據，以及更切身的理解。

　　簡短回顧

　　全功能團隊

　　它不僅是由一專多能的多面手成員組成的軟件開發團隊，而且是所有成員共同分擔職責的團隊。團隊中的各項職責不再與具體的人員耦合，每一個人都有可能做并且有能力做超過一種傳統角色所做的事：例如在某個時刻，開發人員在做測試，測試人員在做業務分析，業務分析人員在做部署;前端開發、后端開發、數據庫維護被開發人員一視同仁;所有的人都能與客戶溝通，也承擔著只有傳統的項目經理才鬧心的項目風險。

　　來自軟件開發業界的質疑

　　在關于全功能團隊的討論中，最激烈的質疑集中在能力和效率兩個方面：

　　從效率上看，除非團隊小得可憐，分工是必然的：團隊成員頻繁地轉換工作職能，就意味著要不時地做點不是特別熟練的事，這是否降低了效率呢?比如，重復性高的測試工作雖然入門簡單，但一個傳統開發人員也需要一些時間的經驗積累，才能替代專職QA，做到快速且高效地測試;又是不是應該找專人來做部署呢?

　　從能力上看，分工似乎是必需的：讓業務分析人員明白代碼實現是不是有必要，會不會強人所難?開發人員有較強的代碼和業務閱讀能力，但是否同樣具有同樣水平的測試用例設計能力?即便是多面手團隊具備的技能深度也是有限的。

　　帶著這樣的問題，我們在過去一年里用實踐里證明了全功能團隊的可行性，并在團隊成員培養和項目可持續進展上都受益不少。

　　我們怎么做到的

　　針對效率問題

　　對效率的通?？紤]方式源于工業化生產，認為分工后的重復性工作能提高勞動熟練度，從而提高生產效率。但是，知識工作不是流水線上擰螺絲，它的核心問題是效果 (Effectiveness) 而不是效率 (Efficient) 1。通俗地說，打字最快的不一定是好程序員，100行代碼也不一定比一行代碼更有價值。所以，對有價值的軟件開發者而言，真正重要的是知道要做什么、為什么、怎么正確地做到。

　　全功能團隊中，我們讓成員做不同角色的職責，就是要打破知識壁壘，讓大家都站在不同的角度看我們的軟件，傳遞知識、擴展認知;等再回過頭看自己原來做的“本職”工作時，從其他角色的角度得到的知識會幫助我們用更正確方式地做對的事。同時，培養多面手團隊成員的益處也在于，可以按需調整做某件事的人數或安排人員的替補，這對團隊的人員利用率提升是很有幫助的。

　　我們這樣做：

　　我們不為前端開發、后端開發和運維工作劃分崗位，要求所有開發人員接觸到所有層次的代碼和環境。有了全面的了解之后，再沒有人“因為沒做過所以不敢碰“，所以接下來就是提升各自能力來把事情做得更好了。

　　我們每兩周輪換做測試工作的成員。做測試人員期間，他會測試開發完成的功能以及回歸測試各個組件，這有助于他了解系統的整體行為;同時他帶去了自己的開發經驗，不僅能在外部功能層次測試，還能深入代碼挖掘，比專職的測試人員更能找到潛在的缺陷。

　　我們的業務分析人員要計劃每次部署和安排部署前的回歸測試，對待部署的功能須十分清晰;他們要為每個待開發功能準備全面的驗收條件，甚至寫出驗收測試描述(Given/When/Then)2，這樣的用戶故事可讀性非常好，因為驗收測試可直接拿來與客戶或開發人員交流。

　　我們沒有固定的人與客戶做接口溝通，所有的輪值測試人員都需要向客戶展示完成的功能以確認驗收，所有的人都有義務向客戶詢問疑難的需求，所有的人輪流做迭代報告或主持回顧會議。

　　所有項目上的信息都在團隊內共享，結對編程也2、3天一輪換，這減少了團隊成員的上下文盲點，便于各人迅速定位并正確處理問題。

　　針對能力問題

　　對能力的擔心是可以理解的：對不熟練的事甚至頭一次做的事，誰都不能很有把握獨立做到;每個人的技術能力是有限的，職責的切換意味著挑戰來臨。然而這是一個團隊，沒有人孤軍奮戰，也不會安排成員做登天的事。

　　全功能團隊在能力問題上重視的是團隊成員的成長和項目的可持續進展。培養成員逐漸勝任某項新職責是對他能力的拉伸，只要方法得當，團隊就會平穩地在幾個月后收獲一批一專多能的多面手成員。而這種成長也不是以暫時犧牲項目進展為代價的，項目和人員成長不站在對立面。

　　我們這樣做：

　　將職責和個人去耦合之后，提煉出若干職責，如業務分析、測試、前端開發、數據庫維護、部署等。

　　我們為每項職責找出領導者，稱為教練。教練是某一職責上的專家，如測試教練，他是測試工作上能力最強又所知最多的人，由他來輔導測試技能尚需鍛練的人，通過結對的方式面授機宜，幫助他適應“新角色”的工作。

　　“新人”成長后，教練會跟蹤其工作的進展，并只在復雜情況下才伸手幫忙，如某些緊急應對。教練也擔負者第一時間響應客戶疑問的責任，他們是客戶與開發團隊關于某方面工作的接口，客戶知道想要跟蹤某項工作的進展情況，只要聯系他即可。

　　某職責上的教練也常是其他職責上的“新人”，他也需要被幫助，需要同樣努力勝任新職責。

　　從項目的可持續進展上看，全功能團隊能夠輕易地克服人員短板，并保持很高的團隊凝聚力。因為團隊里都是多面手成員，且大家保持了非常頻繁交流和信息共享，各個人即便相互替換位置來做事情也很容易。

　　我所在的團隊里，有很多事都是其他非全功能團隊無法想象的：

　　沒有專職的測試人員和部署人員，所有人都有能力做開發、測試和向產品環境部署，即便是才加入團隊半年的大學畢業生，也能獨挑這副擔子了。項目的缺陷和交付進度依舊保持平均數目，并未出現由于沒有“專職”人員而導致的不“專業”。

　　從不因為某人的突然請假而阻礙某件工作。這得益于多面手成員們每天充分的信息共享和結對工作，任何一個人請假了立即有人能頂替他做好職責。

原文轉自：http://kb.cnblogs.com/page/174631/