l

2015年7月7日 星期二

看圖說故事(1):技能等級分布

July 02 16:39~18:20

螢幕截圖 2015-07-02 20.16.47

 

原本以為靠「三個圓圈」系列可以寫好幾篇文章(請參考〈三個圓圈(1):產品願景〉),哪知有意義的文氏圖可遇而不可求,只好改變策略,另闢戰場,新增「看圖說故事」系列。

今天要說的圖節錄自《Pragmatic Thinking and Learning》,談五種不同技能等級的分布。關於這五種技能請參考〈守破離與技能模式〉,根據書中說法這五種技能在開發人員身上並非常態分布,也不是金字塔型,而是如上圖所示。書中並沒有說明每一種技能等級所佔比例,圖中的百分比是Teddy依據圖型長度所大致推算出來的比例,當作參考就好。

***

在看這個圖的時候Teddy突然想到,如果把這個圖應用到敏捷開發的跨職能團隊中,可否幫助我們評估團隊成員的能力等級比例?以下為Teddy的大膽假設:

  • 團隊中的每一種職能類別(例如前端工程師、後端工程師、測試工程師、UI/UX設計師):
    • 最好至少有一位勝任者,可以帶動該職能類別的技術學習。勝任者佔28%,稍微用力一點應該有辦法找到這樣的人。
    • 其餘大部分「戰將」最少要具備高級新手的能力。
    • 至於團隊中的新手可以從測試工作(自動化或手動)開始了解系統,再慢慢透過pair programming或安排複雜度低的開發工作開始著手。
  • 整個團隊至少要有一位精通者,如此才可具備逐步改善的能力。精通者佔13%,人才不好找,如果找不到則需要想辦法從團隊中培養。Teddy認為敏捷顧問的重要工作之一就是協助團隊找到精通者,或是協助勝任者提升為精通者(至少是在敏捷開發或是Scrum這個領域的精通者)。這個任務完成之後團隊自身開始具備持續改善能力,敏捷顧問也可以慢慢退場,或是逐步減少顧問服務的頻率與強度。
  • 由於專家的比例很少,而且可能都被外商、大公司給搶走,又或者是自己開公司,所以(在台灣)敏捷團隊中出現專家的機會可能又更低了一些。如果有,也許這種人不應該擺在某個特定團隊之中,而是讓他觀照全局與多個團隊,用「直覺」來協助公司持續改善,或是成為ScrumMaster的教練。

***

Teddy看過成員幾乎都是高級新手的Scrum團隊,因為缺少自我改善的能力,所以retrospective會議流於形式,而團隊解決問題的能力也沒有隨著sprint的進行而變得越來越好。雖然每個sprint也都完成了一些user story,但總是覺得進步有限,恨鐵不成鋼。Teddy認為這個問題很與retrospective會議舉辦的技巧沒有很大關聯,主要原因是團隊看不到自己可以改善的地方,成員中沒有人具備精通者等級以上的能力

***

友藏內心獨白:所以要同時讀書與動腦筋啊。

沒有留言:

張貼留言