傻的願意相信(2)

Sept. 23 22:14~Sept. 24 00:28

幫鄉民們複習一下，這裡是《傻的願意相信》第一集。「傻的願意相信」這句話是Teddy的指導教授在上課時所經常掛在嘴邊的一句話，藉此勉勵學生要「傻的願意相信」課本上所教授的軟體開法與設計方法。唯有自己先「願意相信」這些方法是可行的作法，儘可能嘗試照著去做，而不要在真正學會之前就先急著去否定這些方法，日後才有深刻的體驗與堅實的立場去評論這些方法。聽起來好像很簡單，但是台灣人都太聰明也缺少耐心，要台灣人不甘寂寞地慢慢練功，傻傻地一步一步按照規矩辦事，說真的還真是不太容易。

上次在 C. C. Agile聚會中，有一位鄉民甲和Teddy聊到Scrum和Kanban的問題。

鄉民甲：我看書上說，Lean Startup應該要採用Kanban會比Scrum還要有彈性。

Teddy：怎麼說？

鄉民甲：例如，假設PO（訂定需求的人）有一個緊急的需求想要讓團隊優先去做，如果是採用Scrum，因為Scrum規定在sprint中不可以更改原先已經選定的story，所以平均來說，這個新的需求最快需要1/2 sprint的時間才可以被團隊給排入下一個開發週期。假設團隊採用兩週的sprint，那就代表這個緊急的需求平均需要等待一週才可以被團隊給實作。

Teddy：然後勒？

鄉民甲：可是如果是採用Kanban的話，就不會有這個限制啊。

Teddy：為什麼？

鄉民甲：因為Kanban沒有規範sprint（iteration），所以新的需求馬上就可以被開發團隊給實作。

Teddy：真的是馬上嗎？

鄉民甲：嗯，應該說，在Kanban中，高優先權的需求，平均等待時間是「一個需求從第一個開發階段被移到下一個階段的時間的一半」。

Teddy：可以舉例說明一下嗎？

鄉民甲：假設有一個四個人（甲、乙、丙、丁）的團隊，它們的Kanban board如下所示。甲跟乙正在做Story A，丙和丁在作Story B。這時候突然有一個很緊急的需求Story E冒出來，由於Not Checked Out的WIP為2，所以先把Story D給移走以便插入Story E。

Kanban board 變成這樣：

此時必須要等Story A 或是 Story B被做完之後，移到Review階段，才有可能把Story E拿出來施工。假設現在Story A做完了，甲跟乙把Story E拿出來做，Kanban board如下所示。

現在團隊發現流程卡在Review階段，所以派丁去處理Story A。

這樣子等甲跟乙把Story E做完之後，丁可能也把Story A給做完了，這樣子Story E就可以流到Review階段。

Teddy：如你所說的，由於Kanban沒有固定時間的sprint的規範，所以以上面這個例子來看，只要Kanban board上面Not Checked Out之後的階段「有空（WIP未達規範的上限）」，緊急的工作就可以馬上被施工。

Teddy：你實際上應用Kanban的經驗，有沒有發現什麼問題？

鄉民甲：其實我沒有真正用過Kanban耶，我只是看書上這樣寫而已。我目前還是採用Scrum，實際上遇到比較多的問題，反而是派工的問題。

Teddy：派工的問題問題是指？

鄉民甲：以上面這個例子來看，雖然在甲跟乙完成Story A之後，這個很緊急的Story E就可以被拿出來做，但是很有可能會發生甲跟乙其實對完成Story E所需的技能不熟，真正熟的人是丙。但是Story B又非得需要丙不可，所以暫時也不能把丙調來實作Story E。

Teddy：這個問題在Scrum中也經常會發生，但是由於Scrum建議組成cross-functional team，而且如果團隊有採用XP的pair programming與shared code這兩個實務做法的話，這種派工（認領工作）的難題慢慢地會比較少發生。

鄉民甲：Kanban對於團隊組成的方式其實沒有任何規範，不過經過這番討論，如果要達到具備有彈性的認領緊急的工作，團隊還是要借用其他敏捷實務做法，否則實際運作上還是會一直卡卡的。

***

鄉民甲問Teddy：那到底要用Kanban，還是Scrum會比較好？

Teddy在《開發軟體用什麼流程比較好？》有提到，「不管是哪種流程，只要能夠有一個良好的機制，可以把專案與團隊所遭遇的問題給凸顯出來，並且提供一個可以持續改善的機制，這樣這個流程就已經是很不錯的流程了。」講是這樣講，但是實際上團隊如果對於開發流程的掌握還不是很好的時候，Teddy認為還是從學習一個制式的流程開始會比較好。從這個角度來看，Teddy會建議從Scrum開始學習。因為Scrum的「框架」規範相較於Kanban來講要比較清楚（Scrum的限制比較多）。對於一個剛開始接觸敏捷方法的團隊而言，採用稍微限制多一點的流程框架，會比較容易遵循。等熟悉Scrum框架之後（至少需要6-12個月的時間吧），再來討論流程上較大幅度的調整，這樣會比較好。

舉個例子，Teddy剛開始採用Scrum的時候，會把product backlog裡面的story都先估算它們的story point，再藉此畫出release burndown chart。但是經過幾次軟體的release之後，Teddy發現軟體release的時間，經常會因為某些突發狀況而提早或延後，因此過早去規劃release plan的作用不是那麼大。後來Teddy就只關注於接下來1-2個sprint所要準備施工的story，而不再費心去定期重新檢視所有的product backlog item。前一陣子Teddy讀了Henrik Kniberg所寫的《Lean from the Trenches》才發現Teddy後來管理需求的精神，跟書中所提到的在Kanban board上面標示「Next Ten Features」很相似。

但是，Teddy在上Scrum課程時，還是會建議學員們先乖乖地依據Scrum的建議，每個sprint撥點時間讓團隊舉辦product backlog refinement workshop，而不要一下子就跳到比較自由的形式，這樣走火入魔的機率應該會比較低一點 。

***

話說回來，那Teddy怎麼在Scrum中應付「突發的重要需求」？這個問題要分幾點來討論：

• 這真的是一個「客戶急需的需求嗎？」：很多時候，業務、行銷、主管、老闆、黨國元老、甚至是鄉民，都會以「客戶急需」以及「量很大」這兩點，來要求開發團隊「立即對他所提出的要求有所反應」。而這這種突發的要求，很不幸地經常是未經思考與驗證的「隨口說說」，且經常在政治力之下，打亂團隊的開發步調。在Scrum框架下，當團隊有一定的開發步驟時（例如每兩週產出成品），在平均一週的等待時間內，可以讓提出需求者與PO或是團隊成員稍微冷靜與確認這個突發需求的真正內涵。
• 原先的需求搞錯了：如果在sprint進行中發現原本某個story的需求搞錯了，那怎麼辦？你可以把這個story丟掉，排入下個sprint繼續開發，也可以直接「就地都更」。
• 真的很緊急的需求：如果這是一個經過確認真的很緊急的需求，而在這個sprint剩下來的時間中可以完成這個需求，那就把它直接排入這個sprint中。

***

Teddy之前曾說過，導入Scrum到後來所遇到的問題，其實最大的問題是「如何讓團隊分工且合作」，或是「如何流暢的派工（認領工作）」。記得當年Teddy在讀Toyota Production System的書籍時，裡面就有提到一個重點，那就是Toyota Production System的工作流程要能夠成立（即時生產、有彈性的組裝各種不同形式的車輛），除了「自働化」以外，另一點就是「培養多才藝的員工（生產線的工人要能夠具備組裝車輛任何部份的能力）」。如果後者不成立，不管是採用Scrum還是Kanban都會遇到很大的阻礙。

報告完畢。

***

友藏內心獨白：理論上，理論與實務是一樣的。但實際上，這兩者卻不相同。