David Ko的學習之旅

在上次的聚會中, 有人提到在專案進行時, 會發生有人沒事做的現象, 原因並不是那位員工不認真, 而可能是以下幾種

- 不會那項工作所需要的技能
- 因為架構切割的關係, 導致大多數的人只會某些系統或是元件

我想這些是很常見的因素. 可是你的老闆並不會體諒這種狀況, 他會覺得你明明有 10 個人,(可是只有 2 個會寫 UI), 為什麼整體開發這麼慢. (因為會 UI 的人太少寫不快)

所以在敏捷的團隊中, 他提倡 feature team, 就是希望會這個專案所需要的技能的人都在(cross functional), 並且他們會的不止一項技能(multiple skills). 這樣做可以帶來以下好處:

 

1. 資源調度容易: 會的人比較多, 比較容易做工作分配
2. 團隊互助支援: 萬一有人請假或是離職, 要找到支援的人比較有可能
3. 容易對系統架構作調整: 因為大家對系統每個部分了解比較多, 所以在談論系統如何重構時, 比較能提出建言
4. 開發速度比較快: 在調度容易的狀況下, 開發時就減少一定要等誰做完的機率, 自然會比較快

當然啦, 我也知道要組成這樣的團隊不容易. 不過你還是可以嘗試改變工作方法, 讓整個團隊的運作會比較有效率. 例如:

1. 搭擋編程
試著讓兩人一起合作工作, 進行的方式可以很有彈性:
(1) 可能一天只要 1 - 2 兩個小時一起討論, 每次設定好主題, 讓事情鎖定好範圍和目標, 這樣讓結果是多人智慧的結晶, 可是又不會浪費大家太多時間. 重點是這也可能是你們目前已經在做了, 只是你給他一個很正式的名稱. 所以你不說這是 pair programming, 也不會有任何反彈
(2) 一同設計, 但是只有一個人實作. 讓有經驗的人帶著另一人一起討論, 但是讓沒有做過或是沒有經驗的人去實作它. 或許這會花比較多時間, 但是可以讓這事情的比較是比較少, 就不會影響大局太多, 但是卻讓你有機會擴充技能.

2. ABC -> ABD
當然一開始無法達到多技能, 因此可以先從你會的開始, 逐步擴充你會的東西. 例如, 你只會 ABC 三件事情, 這時候你可以嘗試處理需要用到 ABD 技能的工作, 開始學習 D 的技能. 要學新的東西, 但是又不是全部都是新的. 讓你在可控制的範圍下, 漸漸學會多點東西.

方法其實還有很多, 重點是不是有心. 如果有心的話, 你會想出更多方法, 來讓大家學會更多東西的.