很多人都知道 Scrum 或是 LeSS 希望團隊成員可以略懂略懂, 這樣在互相協作上會比較方便, 並且因為略懂略懂, 也讓大家的日子比較有趣. 可是, 這要怎麼做才能讓大家有機會略懂略懂呢? 這邊我講整理一下 Bas 和 Craig 他們數十年來的一些經驗, 期待能夠對大家有用.

(1) 先挑部分不懂的來做

很多人以為擴大學習, 就是要挑自己完全不會的去做, 這樣是可以學習新的東西, 但是因為都不會, 很多人會惶恐, 擔心會做不出來, 導致時程無法趕上. 另外, 老闆也會有同樣的擔心, 覺得還是時程優先, 擴大學習這個還是往後放一放.

沒錯, 這樣的考量是很正常的. 我們不太可能為了擴大學習, 然後一起就不管了. 畢竟, 經營公司還是為了賺錢, 不可能為了學習技術, 而不可量公司業務. 因此作法上還是需要兼顧.

我們來看看下面這個例子, 開發用戶故事 1 需要會 (A, B, C) 等技能, 而開發用戶故事 2 需要會(A, D, E) 等技能. 而黃色團隊剛好會 (A, B, C) 等技能, 因此他可以拿用戶故事 1 去做. 綠色團隊會 (C, D, E) 而 藍色團隊會 (A, B, E, F) 等技能, 這和用戶故事 2 所需要的技能不匹配, 但是並沒有差到很多, 只有一部分的技能不同. 這時候在故事的指派上面, 綠色團隊或是藍色團隊可以嘗試接下這個用戶故事, 落差不大時間上可以有機會學習, 有機會可以兼顧到專案時程.

(2) 透過搭檔編程來學習

在 LeSS 中他很強調工作的執行上要用搭檔編程 (Pair Programming), 可以工程師 A 和 B 一起合作用戶故事 1, 而工程師 A 和 C 一起合作用戶故事 2. 或者是不同迭代可以找不同的人一起開發, 或者 工程師 A 開發用戶故事 3, 工程師 B 去做用戶故事 3 的測試. 這些都是落實搭檔編成的一些變形做法, 目的就是讓團隊成員有機會去協作.

在這個過程中, 因為兩個人一起工作, 一方面可以相互學習, 另一方面可以多元視角來看問題, 也可以即時的檢視, 所以產生出來的代碼品質較好, 並且也容易做到共享程式碼擁有權. 另一方面, 很多人會錯覺說, 因為兩個人這樣生產力減半, 事實上因為這樣討論協作, 所以出來的品質是比較高的. 並且如果討論完了, 不見得整天都要一起協作, 一天如果有 2-3 小時高品質的協作, 其他時間還是可以做自己的事情.

(3) 彈性任務分配

很多時後在分配工作時, 我們總是拿自己熟悉的, 或者是固定的分配模式. 這裡我們可以嘗試這些方式:

a. 找自己不熟的工作

以 80/20 法則, 我們可以 20% 的工作, 是找自己不太熟的事情, 藉由搭檔編程的方式, 學習要如何去做. 當然一次就能會, 這不太可能, 多練習幾次, 可能基礎的東西可以學習, 但是這樣就可以幫忙做一些東西. 難的部分可能還是要專業的來.

b. 和擅長的人一起合作

某些部分你可能只是知道或是略懂, 這時候可以和擅長的人一起做事, 他的經驗可以讓你少走一些冤枉路.

c. 常常輪換搭檔夥伴

或許大家對某些東西都懂一些, 這時候可以輪流搭檔, 大家的不同視野和背景, 可以刺激你有不同想法, 這對創意型的工作很有幫助.

(4) 利用需求領域來漸進學習

LeSS Huge 框架和 LeSS 框架最大不同的地方就是需求領域(Requirement Areas). 當你有很複雜和龐大的需求要處理, 你可以拆解成多需求領域, 每個 LeSS 框架只處理一個需求領域, 以降低複雜度.

同理, 在單一的 LeSS 框架中, 我們也可以這個需求領域, 在拆解成多個子需求領域, 這時候可以跟團隊成員說, 讓他們挑選某一個子需求領域開始熟悉. 這樣對他們來說, 壓力比較不會那麼大. 另一方面這樣也比較可以設定目標, 比如說半年後, 要針對子需求領域 A去熟悉, 然後在半年再去熟悉子需求領域 B 和 C, 這樣漸進地讓團隊成員熟悉整個需求領域.

(5) 對不熟的用戶故事轉寫驗收條件

有時候要團隊成員針對一個新的領域, 或是不熟悉的領域, 去進行開發的工作, 我想很多工程師會覺得這真的有難度. 老闆除了擔心做不完外, 也會覺得開發出來的品質堪慮. 因此, 我們可以從另一個角度來進行.

我們可以讓工程師先針對不熟的用戶故事去開立驗收條件. 一方面這不是真的去開發, 所以工程師會比較有把握. 另一方面, 你在開發之前, 本來就要先了解這個東西的需求是什麼, 所已從撰寫驗收條件來了解需求, 算是不錯的投資. 再加上因為你不懂, 所以提出來的問題就比較不會有先入為主的狀況. 有時候笨問題, 往往是好的問題.

下圖這是一種進行的狀況, 開發用戶故事 1 需要會 (A, B, C) 等技能, 而開發用戶故事 2 需要會(A, D, E) 等技能. 而 David 剛好會 (A, B, C) 等技能, 因此他可以拿用戶故事 1 去梳理驗收條件. Jessie會 (A, D, F) 等技能, 這和用戶故事 2 所需要的技能不匹配, 但是並沒有差到很多, 只有一部分的技能不同. 因此, Jessie 可以拿用戶故事 2 去梳理驗收條件.

(6) 展示不熟的用戶故事

和上面那個類似, 直接要工程師開發不熟或不會的, 確實有難度. 這裡我們換成請他展示自己不熟但已經完成的新功能, 這個殺傷力就比較小一點. 在懂那個東西如何開發之前, 總是要先會知道如何使用, 以及如何把它安裝起來, 環境部分有哪些地方要如何設定調整, 這些都是你要真的開發之前要會的. 所以做了這一步會讓你離可以開發他又近了一些.

下圖這是一種進行的狀況, 開發用戶故事 1 需要會 (A, B, C) 等技能, 而開發用戶故事 2 需要會(A, D, E) 等技能. 而 David 剛好會 (A, B, C) 等技能, 因此他可以拿用戶故事 1 去開發. Nick 他會(A, B, D) 等技能, 跟用戶故事 1 所需要的技能沒有差到太多, 因此可以請 Nick 在 David 完成後幫忙 demo, 讓 Nick 學習一下用戶故事 1 和 C 技能相關設定等等. 這邊我們也是沒有讓一個完全都不會的人來 demo, 也採取沒有差到太多的來試試, 這樣可以兼顧時程, 也讓 Nick 不會那麼害怕.