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

　　簡短回顧

　　全功能團隊

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

　　來自軟件開發(fā)業(yè)界的質(zhì)疑

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

• 從效率上看，除非團隊小得可憐，分工是必然的：團隊成員頻繁地轉(zhuǎn)換工作職能，就意味著要不時地做點不是特別熟練的事，這是否降低了效率呢？比如，重復(fù)性高的測試工作雖然入門簡單，但一個傳統(tǒng)開發(fā)人員也需要一些時間的經(jīng)驗積累，才能替代專職QA，做到快速且高效地測試；又是不是應(yīng)該找專人來做部署呢？
• 從能力上看，分工似乎是必需的：讓業(yè)務(wù)分析人員明白代碼實現(xiàn)是不是有必要，會不會強人所難？開發(fā)人員有較強的代碼和業(yè)務(wù)閱讀能力，但是否同樣具有同樣水平的測試用例設(shè)計能力？即便是多面手團隊具備的技能深度也是有限的。

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

　　我們怎么做到的

　　針對效率問題

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

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

　　我們這樣做：

• 我們不為前端開發(fā)、后端開發(fā)和運維工作劃分崗位，要求所有開發(fā)人員接觸到所有層次的代碼和環(huán)境。有了全面的了解之后，再沒有人“因為沒做過所以不敢碰“，所以接下來就是提升各自能力來把事情做得更好了。
• 我們每兩周輪換做測試工作的成員。做測試人員期間，他會測試開發(fā)完成的功能以及回歸測試各個組件，這有助于他了解系統(tǒng)的整體行為；同時他帶去了自己的開發(fā)經(jīng)驗，不僅能在外部功能層次測試，還能深入代碼挖掘，比專職的測試人員更能找到潛在的缺陷。
• 我們的業(yè)務(wù)分析人員要計劃每次部署和安排部署前的回歸測試，對待部署的功能須十分清晰；他們要為每個待開發(fā)功能準備全面的驗收條件，甚至寫出驗收測試描述(Given/When/Then)²，這樣的用戶故事可讀性非常好，因為驗收測試可直接拿來與客戶或開發(fā)人員交流。
• 我們沒有固定的人與客戶做接口溝通，所有的輪值測試人員都需要向客戶展示完成的功能以確認驗收，所有的人都有義務(wù)向客戶詢問疑難的需求，所有的人輪流做迭代報告或主持回顧會議。
• 所有項目上的信息都在團隊內(nèi)共享，結(jié)對編程也2、3天一輪換，這減少了團隊成員的上下文盲點，便于各人迅速定位并正確處理問題。

　　針對能力問題

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

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

　　我們這樣做：

• 將職責(zé)和個人去耦合之后，提煉出若干職責(zé)，如業(yè)務(wù)分析、測試、前端開發(fā)、數(shù)據(jù)庫維護、部署等。
• 我們?yōu)槊宽椔氊?zé)找出領(lǐng)導(dǎo)者，稱為教練。教練是某一職責(zé)上的專家，如測試教練，他是測試工作上能力最強又所知最多的人，由他來輔導(dǎo)測試技能尚需鍛練的人，通過結(jié)對的方式面授機宜，幫助他適應(yīng)“新角色”的工作。
• “新人”成長后，教練會跟蹤其工作的進展，并只在復(fù)雜情況下才伸手幫忙，如某些緊急應(yīng)對。教練也擔負者第一時間響應(yīng)客戶疑問的責(zé)任，他們是客戶與開發(fā)團隊關(guān)于某方面工作的接口，客戶知道想要跟蹤某項工作的進展情況，只要聯(lián)系他即可。
• 某職責(zé)上的教練也常是其他職責(zé)上的“新人”，他也需要被幫助，需要同樣努力勝任新職責(zé)。
• 從項目的可持續(xù)進展上看，全功能團隊能夠輕易地克服人員短板，并保持很高的團隊凝聚力。因為團隊里都是多面手成員，且大家保持了非常頻繁交流和信息共享，各個人即便相互替換位置來做事情也很容易。

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

• 沒有專職的測試人員和部署人員，所有人都有能力做開發(fā)、測試和向產(chǎn)品環(huán)境部署，即便是才加入團隊半年的大學(xué)畢業(yè)生，也能獨挑這副擔子了。項目的缺陷和交付進度依舊保持平均數(shù)目，并未出現(xiàn)由于沒有“專職”人員而導(dǎo)致的不“專業(yè)”。
• 從不因為某人的突然請假而阻礙某件工作。這得益于多面手成員們每天充分的信息共享和結(jié)對工作，任何一個人請假了立即有人能頂替他做好職責(zé)。
• 從項目中移出成員比較容易，不會因關(guān)鍵人物的離開導(dǎo)致項目遇險。四個月前，當時做業(yè)務(wù)分析兼項目經(jīng)理的女同事突然得知懷孕需要休假，我們也只做了簡單的交接，就完成了這次人員變更，并保持了平穩(wěn)的項目交付能力；如今這項職責(zé)早已向另一成員成功交接。

　　用數(shù)據(jù)說話

　　問題1： 沒有了專職測試人員之后，系統(tǒng)新增功能的缺陷數(shù)目是否顯著增加呢？

　　答案：沒有。圖1顯示的是我所在的項目過去一年半內(nèi)的缺陷數(shù)曲線。豎線標示的是自2012年7月1日起，團隊取消了專職測試人員，以兩周一輪換的頻率讓所有開發(fā)人員輪流做測試。由圖可見，這個實踐開始之后的缺陷并未較之前顯著增加，7月初和10月初兩次重大發(fā)布仍然是影響缺陷曲線的最重要因素。

圖1 取消專職測試人員前后的缺陷數(shù)曲線

　　問題2：全功能團隊中的成員角色切換甚至人員變更較頻繁，有沒有對項目的交付進度產(chǎn)生嚴重影響？

　　答案：沒有。圖2是我所在的項目近一年來的團隊人員變更情況與交付速率曲線的對比，這里的交付速率數(shù)值僅包含具有業(yè)務(wù)價值的用戶故事卡的點數(shù)，而其他的如技術(shù)卡和缺陷卡的工作量是單另進行統(tǒng)計的。在2012年7月到8月這段時間內(nèi)，團隊的成員調(diào)整的較頻繁，同時伴隨成員調(diào)整，各人的角色也在調(diào)整，參照交付速率曲線來看，在這段變更時期以及之后的適應(yīng)期里，團隊仍然保持了如以往的交付節(jié)奏和速度；交付速率曲線上在1-4月、4-7月、7-10月體現(xiàn)出的沖高而后漸落的變化模式，也與項目在4月、7月、10月的三次重大新功能發(fā)布相契合。前文圖1也參證了在7月到8月這段時間里，項目的缺陷數(shù)目并未顯著爆發(fā)。所以我們觀察到的是項目交付進度未受影響。

圖2 團隊人員變更與交付速率按月對比

　　問題3：全功能團隊強調(diào)一人多用，那它真的比普通團隊的人才利用率高嗎？

　　答案：是的。圖3-1, 3-2是在ThoughtWorks西安辦公室做的一次關(guān)于各人所擔任過的團隊職責(zé)的調(diào)查結(jié)果。來自包括我所在的團隊在內(nèi)的幾個團隊共38人參與調(diào)查，他們自認為的本職角色大多為開發(fā)人員（78.9%），具體的本職角色統(tǒng)計如圖3-1所示，角色比例與業(yè)界數(shù)據(jù)3 相去甚遠。但他們在團隊中做過的職責(zé)都不止一個，如圖3-2所示，以人數(shù)所占比例最高的開發(fā)人員為例，他們中77%的人做過測試工作，23%的人做過項目管理，30％的人做過業(yè)務(wù)分析，40%的人做過運維。從數(shù)據(jù)可見，全功能團隊中不易出現(xiàn)因為某角色人員的缺席導(dǎo)致的交付阻塞，因為其他角色的人可以轉(zhuǎn)換職責(zé)來代替缺席者。建設(shè)這樣的團隊對多個團隊之間共享人才、提高公司整體人員利用率會有幫助。

圖3-1 所有參與調(diào)查者職位的分布比例

圖3-2 參與調(diào)查者所擔任職責(zé)的調(diào)查結(jié)果

　　結(jié)論

　　從我觀察到的ThoughtWorks全功能團隊的實踐以及收集到的數(shù)據(jù)來看，建設(shè)全功能團隊在中小型項目里能順利進行。我們按照良好實踐所做的嘗試和努力，讓項目、個人以及公司都受益了。那些來自軟件開發(fā)業(yè)界的憂慮，從本文談及的實踐以及數(shù)據(jù)來看也應(yīng)該釋然了。

　　注解與參考

1. Peter Druker,

2. Uncle Bob’s post, Nov 2008

3. 通過招聘網(wǎng)站估算出的數(shù)字，如果需求是基本平衡的，市場所提供的職位數(shù)量比例與相關(guān)從業(yè)者的比例應(yīng)當基本一致。對某主流招聘網(wǎng)站IT板塊進行搜索得到：35000開發(fā)職位，14000測試職位，12000分析職位。

it知識庫：全功能團隊 - 數(shù)據(jù)篇，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。