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

　　簡短回顧

　　全功能團隊

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

　　來自軟件開發業界的質疑

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

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

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

　　我們怎么做到的

　　針對效率問題

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

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

　　我們這樣做：

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

　　針對能力問題

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

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

　　我們這樣做：

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

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

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

　　用數據說話

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

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

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

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

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

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

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

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

圖3-1 所有參與調查者職位的分布比例

圖3-2 參與調查者所擔任職責的調查結果

　　結論

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

　　注解與參考

1. Peter Druker,

2. Uncle Bob’s post, Nov 2008

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