從項目中移出成員比較容易,不會因關鍵人物的離開導致項目遇險。四個月前,當時做業務分析兼項目經理的女同事突然得知懷孕需要休假,我們也只做了簡單的交接,就完成了這次人員變更,并保持了平穩的項目交付能力;如今這項職責早已向另一成員成功交接。
用數據說話
問題1: 沒有了專職測試人員之后,系統新增功能的缺陷數目是否顯著增加呢?
答案:沒有。圖1顯示的是我所在的項目過去一年半內的缺陷數曲線。豎線標示的是自2012年7月1日起,團隊取消了專職測試人員,以兩周一輪換的頻率讓所有開發人員輪流做測試。由圖可見,這個實踐開始之后的缺陷并未較之前顯著增加,7月初和10月初兩次重大發布仍然是影響缺陷曲線的最重要因素。
問題2:全功能團隊中的成員角色切換甚至人員變更較頻繁,有沒有對項目的交付進度產生嚴重影響?
答案:沒有。圖2是我所在的項目近一年來的團隊人員變更情況與交付速率曲線的對比,這里的交付速率數值僅包含具有業務價值的用戶故事卡的點數,而其他的如技術卡和缺陷卡的工作量是單另進行統計的。在2012年7月到8月這段時間內,團隊的成員調整的較頻繁,同時伴隨成員調整,各人的角色也在調整,參照交付速率曲線來看,在這段變更時期以及之后的適應期里,團隊仍然保持了如以往的交付節奏和速度;交付速率曲線上在1-4月、4-7月、7-10月體現出的沖高而后漸落的變化模式,也與項目在4月、7月、10月的三次重大新功能發布相契合。前文圖1也參證了在7月到 8月這段時間里,項目的缺陷數目并未顯著爆發。所以我們觀察到的是項目交付進度未受影響。
問題3:全功能團隊強調一人多用,那它真的比普通團隊的人才利用率高嗎?
答案:是的。圖3-1, 3-2是在ThoughtWorks西安辦公室做的一次關于各人所擔任過的團隊職責的調查結果。來自包括我所在的團隊在內的幾個團隊共38人參與調查,他們自認為的本職角色大多為開發人員(78.9%),具體的本職角色統計如圖3-1所示,角色比例與業界數據3 相去甚遠。但他們在團隊中做過的職責都不止一個,如圖3-2所示,以人數所占比例最高的開發人員為例,他們中77%的人做過測試工作,23%的人做過項目管理,30%的人做過業務分析,40%的人做過運維。從數據可見,全功能團隊中不易出現因為某角色人員的缺席導致的交付阻塞,因為其他角色的人可以轉換職責來代替缺席者。建設這樣的團隊對多個團隊之間共享人才、提高公司整體人員利用率會有幫助。
結論
從我觀察到的ThoughtWorks全功能團隊的實踐以及收集到的數據來看,建設全功能團隊在中小型項目里能順利進行。我們按照良好實踐所做的嘗試和努力,讓項目、個人以及公司都受益了。那些來自軟件開發業界的憂慮,從本文談及的實踐以及數據來看也應該釋然了。
注解與參考
Peter Druker,
Uncle Bob’s post, Nov 2008
通過招聘網站估算出的數字,如果需求是基本平衡的,市場所提供的職位數量比例與相關從業者的比例應當基本一致。對某主流招聘網站IT板塊進行搜索得到:35000開發職位,14000測試職位,12000分析職位。
原文轉自:http://kb.cnblogs.com/page/174631/