Nov. 04 22:13~23:47
「Scrum或是敏捷團隊要如何打考績」這個問題Teddy被問過好幾次，之前也寫過一篇《Scrum團隊如何打考績：鬼扯篇》來談這個問題。不過老實講，對於「打考績」這個問題並非Teddy的專長，而關於敏捷團隊打考績的議題，Teddy也沒有特別花時間去研究（因為Teddy相信，開發高品質軟體，做，就對了 
- 敏捷團隊還是可以有個人的考績：根據「官方說法」，Scrum看的是「團隊的績效」，而不是個人的績效。所以要打考績的時候，應該是只有團隊的考績，而沒有個人的考績（或是說團隊中每個人的考績的一樣）。從營造自我管理、互相合作的團隊這個角度來看，Scrum的建議當然很好，但是實務上這種「只有團隊考績，沒有個人考績」的做法，好像又過於理想。畢竟在真實世界中，團隊中每位成員的表現的確還是存在不同的差異。讀了《Management 3.0》之後，讓Teddy鬆了一口氣：「原來幫敏捷團隊打個人的考績應該不算是十惡不赦的行為」
- 從技能（skill）和紀律著（discipline）手：作者認為，discipline * skill = competence（紀律 * 技能 = 能力）。一個人的能力（把事情做好的能力），取決於這個人的紀律與技能，如果需要針對個人打考績，可以從這兩點著手。紀律的例子有：每天是否準時參加Daily Scrum（每日站立會議）、每天是否更新task board（工作看板）等。相較於紀律，技能就比較不容易量化，例如設計是否容易修改、程式的品質是否較好、解決問題的能力等。有人建議可以將團隊成員的技能分成：初學、熟練、大師這三個等級。當真的需要打個人考績的時候，Teddy認為同時考慮紀律與技能這兩點是一個不錯的出發點。因為有些人的技術能力很強，但是卻不一定有紀律。例如，Daily Scrum經常無故不到、沒有遵守團隊的coding standard、送交程式到版控系統之前沒有執行local build。另一方面，有些人以為工作上只要遵守紀律就可以了，而忽略了在技能上的提升，這樣也是不行的。
- 不要用知識（knowledge）或經驗（experience）來評分：依據常理推斷，擁有豐富的知識與經驗，的確是可以把事情做得比較快、比較好。但是，既然在前面的討論中，我們已經用技能和紀律來評量一的人的能力，那麼考慮知識或經驗的意義就不大了。因為如果某人所擁有的知識或經驗真的有用，自然會反應在他的做事能力上面。相信很多鄉民都有類似的經驗：公司花大錢請了一位很有經驗的主管或是工程師，希望借用他的經驗來幫助公司成長。但是，實際上這個人進入公司之後，並沒有發揮預期的效用。也就是說，一個很有知識與經驗的人，在某個位子上，並不必然會表現出好的能力（所以政府的部會首長不要再迷信一定要找博士來擔任了…Orz）。
- 不要自己建立評分標準：身為一位主管，「理應」制定打考績的評分標準，然後在年初的時候公布給團隊成員知道，以便讓團隊成員可以有努力的目標？這樣對嗎？如果這樣做，就變成Teddy之前所反對的「目標管理」（請參考《目標管理，不要吧》）。為什麼評分標準不要讓主管自己建立？因為很多主管並沒有實際餐與團隊的開發活動，因此很可能會訂出一些不切實際的項目。例如，主管可能認為，每次提交程式碼到版控系統一定要填寫30個字以上的說明才算是一位「有紀律的員工」，因此將這個要求訂成評分項目。提交程式碼到版控系統應該要寫說明這個要求聽起來是很合理的，但是要訂定評分項目之前，應該要跟團隊成員討論，看看評分項目是否對於團隊開發有真正的幫助，而非想像中的好處。最好是能讓團隊成員自己來討論，例如可以考慮依據前一年度retrospective meeting（自省會議）所整理出來的改善項目，挑選若干內容作為評分標準。
***
最後Teddy想提醒一點，在訂定技能標準時，要避免「藏私效應」：
- 在團隊中，每個人都可以成為大師，也就是說大師絕對不會只有一位，如此團隊成員才會願意將自己所知分享給其他成員。
- 合作與幫助他人成長也是一種非常重要的技能，在訂定技能標準時，千萬不可只考慮「技術層面」的技能。換句話說，合作與幫助他人成長的重要性和個人技術能力一樣重要（甚至更重要）。
***
友藏內心獨白：怎麼又有一種準備要逆練九陰真經的感覺
沒有留言:
張貼留言