l

2012年9月24日 星期一

傻的願意相信(2)

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

image

幫鄉民們複習一下,這裡是《傻的願意相信》第一集。「傻的願意相信」這句話是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。

螢幕快照 2012-09-23 下午10.46.33

Kanban board 變成這樣:

螢幕快照 2012-09-23 下午10.56.46

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

螢幕快照 2012-09-23 下午10.58.51

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

螢幕快照 2012-09-23 下午11.07.56

這樣子等甲跟乙把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都會遇到很大的阻礙。

報告完畢。

***

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

沒有留言:

張貼留言