Project的管理在進入Implementation phase(SW process)之後，不管是做Unit Test、Integration Test或System Test，大部份的時間都圍繞著bug打轉。
RD會注意的是自己身上掛的bug，重心自然在思考如何解決bug，然而PL要注意的是所有RD的bug，除了特殊的、嚴重的issue需要PL下decision而深入個案之外，PL應該多花時間關注整體bug在質與量的變化。
有幾個bug的趨勢比較明顯的，例如：
1、Bug發現的數量應該是收斂的
理論上project是要往穩定的方向前進，每個階段或每個版本都應該比之前的完整和穩定，自然RD和VT發現bug的數量是會愈來愈少。
反過來如果沒有收斂的趨勢，或反而發散，那很可能出現類似分批健康檢查這樣的操作上的問題，或是沒有照SW process的步驟而引發不可控制的連鎖反應。PL如果放著不管，不即時改正錯誤的做法，那project將陷入無窮的測試迴圈。
2、發現的bug困難度和複雜度愈來愈高，RD解bug的速度愈來愈慢
簡單的、明顯的bug當然是很快就被發現，數量最多，也最容易解，像一些UI上的問題，RD一天解10個bug以上都是有的。但是愈後期，bug的難度也從偏功能性的問題變成偏系統性的問題，從一個RD可以解決的bug變成要多位RD參與才能解決，甚至3~4個RD花了一個星期才解一個bug也是常見的。
PL如果不了解這樣的趨勢，很可能只看到bug數愈來愈少而鬆懈，以為RD解bug的速度還是會跟以前一樣，那就誤會大了。
面對這樣的趨勢，PL的應對可以在早期時致力排除可能造成測試blocking的問題，愈早完成測試的完整度，就能愈早挖掘出bug，為後期爭取到愈多解bug的時間。而且再後期也應該多配置系統RD加快解bug的速度。
3、注意bug依function team的分布情況
如果某個function的bug數已經多到不合理的情況，PL有必要深入了解，是RD的問題？人力的問題？僅限於該function的問題還是跟其他function整合的問題？是否隱藏系統性的問題？
知道分布的情況，PL也較能掌握各function team的鬆緊狀況，早些針對可能形成project瓶頸的function做好方便人力的調配和支援，甚至在救不了該function的情況下，要先做好project delay的準備或是評估捨棄該function的可能性和影響。
4、平台project和客戶project的差別
過去我曾做過平台project和客戶project在bug數量的比較。
客戶project bug數：平台project bug數 ~= 1:5
客戶project量產時的bug總數約是平台project達穩定能拿去開客戶project的20%左右。
客戶project的bug數比較少是可以理解的，因為是在平台的基礎上做客製化的開發，只是20%是統計出來的數字，在不同的case也許不一樣，但如果是相同平台的客戶project，對PL就是有意義的數字，因為如果平台是1000個bug，PL就可以預期他的project的bug數約是在200個左右，對project的schedule和scope也會有個底。
當1:5變成1:1時又該如何？我帶過客戶project的bug數和平台project比近乎是1:1的不合理的情況，裡面隱藏了很多問題，不過不是現在要探討的。
平台project的PL，能不能把未來的客戶project的bug數控制在20%也視為一個目標？會需要再提高project穩定性的標準。
客戶project的PL，在有個底的情況下，也會對資源的分配和schedule的掌握有較準確的處理。
4、與之前的project經驗比較
幾個index是可以跟之前的project做比較，例如：
A、RD一天解bug的數量
B、各Function的bug數
C、Project bug數Top 5的function
D、依人(RD/VT)、Function、總量/個別量、時間、等等因素，可兜出對你有意義的index
以＜A、RD一天解bug的數量＞來說，也曾經有個故事，某位PL發現project的進度異常緩慢，就心血來潮去統計了這個index，發現和之前的project比起來竟然只有1/5，同樣的一群RD，相同的project phase，產能卻只剩1/5。經過一些訪談，原因很可能是RD連續幾個project下來，長期壓力下已經很累又士氣低落所造成。
其實數據只是結果的統計，雖然不一定能藉由數據找到原因，但至少可以量化結果所造成的傷害和嚴重性。PL如果早一點發覺數據背後的意義，就能早一點做好準備和應對。
沒有留言:
張貼留言