這是敏捷開發績效管理的第十一篇。 也是敏捷開發一千零一問的第三十四篇。（[欄目總目錄](http://blog.csdn.net/column/details/agilequestions.html)） ## 人員可用率 字面上，人員可用率指每個人的所有工作時間中，多少比例被用于真正的工作。 廣義的人員可用率，還應該包括“戰斗人員”的比例，如果各種行政、管理團隊數量龐大，那么總可用率也會因此 降低。本文重點談前者。 深層的人員可用率，還應該指扣除返工、浪費后的實際可用率。 關于人員可用率的數據很少，大致有兩個很有參考意義。 一個是一般建議新建的敏捷開發團隊，人員可用率設置大約是50%。也就是說，每個月22天，最多安排11天的工作（指完全沒有干擾每天8小時都在正常工作的天數）。 第二個是IBM對項目經理的考核中，規定人員可用率應超過70%。這個值應該算是個“及格線”，也就是說，實際的可用率應該在70%以上。 ## 提升可用率的方法 有很多方法都可以提升可用率，不過有些不那么直接，有時候想不到。 越往后的方法越徹底一些，或者可以包括和實現前面的方法。 ### 內部社區 很多時候都是很多已經知道的人陪著少數未知的人（開會、討論……），社區可以通過知識持久化來避免重復溝通。 內部社區不要被錯誤理解為有人在特意地“打造”社區，而要理解為把平時分散的、本來就要寫的文檔社區化，比如用Wiki把縮寫Word內容復制粘貼一份以便于查詢等等（Word順便上傳為附件），不需要做太多額外的工作。 Wiki還有很多好處，隨時可以更改和重新發布，可以多人同時編輯，編輯到一半就可以看到，可以回復和互動等。 ### 減少返工 有些團隊的代碼總是被“扔掉”，這些代碼的原作者，也可以算是不干活的人之一。所以寫下代碼時，一定要有信心做到日后不會被大規模扔掉。 ### 質量前移 一個典型的浪費時間的活動就是測試及之后的修正活動。這個過程包括：開發測試用例-測試-發現缺陷-記錄缺陷-程序員復現缺陷-修改-測試人員重新測試…… 如果編碼時開發人員能做一些類似代碼審查的工作，代碼缺陷會降低很多。這包括自己看自己的代碼，實際上自己看自己代碼這個環節能降低大約60%的缺陷（我在03年自己的度量數據，書上說能到70%，可能我當時已經算是“高手”了缺陷比較少吧，呵呵）。 ### 開放空間 開放空間可以有效減少會議數量。 之前我曾經在一家公司，他們的銷售、市場、支持團隊分散在公司的三個不同角落里邊；公司有9個獨立辦公室，大小頭目都分散其中。每個月各部門會分別召開一次部門會議以及各種小會，然后再一起開一次經理會。 后來把銷售和支持這兩個最需要溝通的團隊挪到一起辦公，取消了辦公室，部門經理們坐在開放空間正中間辦公，其他人圍繞周圍。結果是后來所有會議被合并為一個經理擴大會，大約歷時1小時，開始說銷售（最近的銷售機會等），中間說市場，最后說支持（關于為銷售機會做方案配置之類的）。各部門的會議則基本上都取消了。 支持部門本來想開一個短暫的每周例會，開了三周也取消了，因為發現很多事情都早就知道了，不知道的上Wiki看就可以了。 后來總經理也從辦公室里邊跑出來（因為他發現在經理會上我們就像萬事通一樣有問必答，而他什么都不知道），撿出勤的銷售或支持的空位坐著辦公，順便聽我們聊什么。 ### 減少團隊規模 多找高手，能減少團隊規模。 越小的團隊約不太會需要開會或寫文檔等活動；而高手則不但編程快，缺陷還少。這樣，可用時間就多一些。 這句話可能是史玉柱或馬云說的：**“****資金不會因為高薪而浪費，更多的是因為發給了不干活的人****”**。不干活的人有很多種，有很多是隱形的。比如之前提到的返工中的人。 ### 減少代碼量 “扔掉的規模有多大”？我在自己工作過的公司，見到的確切有數據的實際情況是19萬行代碼被改寫為1.3萬行。這是個納斯達克上市公司，在國內擁有很強的實力，這個產品似乎還有相當的市場占有率，但也仍然做到這個地步。估計**多數開發團隊，在刻意做過代碼管理之前，幾乎其代碼均可壓縮到1/10以下**。 這個數字可能聽起來有點聳人聽聞，但我分析一下原因大家可能就理解了。假設團隊有10個頂尖高手，編碼之神，所有代碼都是不可壓縮的，但是……這10個人各自為戰，從來不溝通；有了前面的假設，就必須假設他們的80%代碼在可復用庫中（每個人自己做自己的可復用庫。我們的跨3人的可復用庫占67%，看起來如果自己用80%不難做到，只能勉強算是大仙級，神級還差點）。那么就可以看到，80%的代碼由于沒有被公共復用而重復了——當然在公共的狀態下可能會有10～20的損耗，但最后可能仍然有70%的總代碼是重復的。也就是說，這10個神級程序員的代碼仍然可以壓縮到1/3。如果再不是神級程序員，結果就…… ### 松結對編程和139團隊（師徒團隊） ### 這里說的是實質（松結對編程里邊提到的那種）的而非名義的師徒團隊。 對師徒而言，交流是潛移默化的不像開會那么花費時間，因此可以降低溝通。 對松結對編程而言，代碼復用是一個基本過程（師傅不愿意讓徒弟多編碼，因為里邊缺陷太多；實際上連師徒自己都知道，自己多編碼缺陷也很多），因此代碼量會減少。 由于代碼數量少，而且多數類/函數都“身經百戰”，因此未來返工的機會就更少。 有一些容易被問起的問題摘兩個提前回答一下，借此說明實際上很多問題如果實際經歷一次，就不是問題了。 **1. 新人編程少且皮毛，學不到東西怎么辦？** 本人95年畢業，到01年前獨立完成過兩個大系統（其中一個是國慶閱兵XX指揮系統，后來演化成空軍XX指揮系統），編程水平怎樣？01年去新公司，被師傅發現不會用虛函數，不會模板（泛型），不會刪內存（沒錯，C盤弄大點，堅持到飛行任務完成就重啟吧，的虧是空軍不是海軍）！ 之后在一個師傅手下做了一年半，具體編寫了多少代碼不記得了（因為中間做了半年的安全加密），就記得最高峰的三個月編了1800行，推算一年半一共有5000有效行吧。年底師傅統計全年整個部門（開始5人，后來20+）編寫了5萬行代碼而已。就憑借這段時間積累的水平，包括這家公司，我一共為三家公司寫過C++編碼規范，包括后來那家納斯達克上市公司。03年遇到獵頭，拿到過20000/月的Offer純編程，因為不帶團隊且不在北京沒去。 總之，前6年和后2年判若兩人。 **2. 遇不到好師傅怎么辦** 我師傅不止我一個徒弟，我自己也不止有一個徒弟，最后學成與否，幾乎僅與徒弟有關。 所以不能輕易問這個問題。 除了跟師傅學習之外，那段時間還看過設計模式、Effective C++這些書。它們可能01年之前很久就出版了，但是之前卻從來沒去買過看過。在微型公司遇不到高手情有可原，但是總不能埋怨這些書當年沒從天上掉下來吧。