看圖說故事（1）：技能等級分布

July 02 16:39~18:20

 

原本以為靠「三個圓圈」系列可以寫好幾篇文章（請參考〈三個圓圈（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會議舉辦的技巧沒有很大關聯，主要原因是團隊看不到自己可以改善的地方，成員中沒有人具備精通者等級以上的能力。

***

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