l

2014年1月20日 星期一

推理就好

Jan. 19 18:40~19:20

image

 

一位朋友告訴Teddy…

朋友:我們公司的顧問告訴我們,Scrum做得好很難,他們曾經連續開了五天的sprint planning meeting。因此顧問建議我們,還是採用Kanban比較簡單。

上面這句話,鄉民們覺得有沒有道理?

今天又要在「公堂之上假設一下」,先推理一下為什麼sprint planning meeting開了五天的可能原因:

  1. 對方以為他們在實施Scrum,其實只是用以前waterfall的方式換個名稱而已。把以前的需求分析/系統分析會議改個名字叫做sprint planning meeting,一連開五天也是很平常的現象。
  2. 對方真的在實施Scrum,但是他們的sprint長度太長。假設為期兩周的sprint需要花一天來開sprint planning meeting,連開五天代表對方的sprint可能長達10周(2.5個月)。
  3. 對方真的在實施Scrum,sprint長度也在2~4周之內,但是尚未掌握sprint planning meeting的要領,因此導致會議時間太長。簡單的說,還是沒有脫離waterfall或是plan-driven(計畫驅動)的舊習,想在sprint開始之前就把所有的設計細節弄清楚。
  4. 對方想在sprint planning meeting就把全部product backlog的內容全部討論完畢。同樣地,還是中了waterfall或是plan-driven的遺毒。

無論是哪個原因,都是對於團隊對於Scrum與敏捷開發不夠理解或是程度不夠的徵兆。

***

接著來推論第二點,sprint planning meeting連開五天這個問題,無論上述1~4點的哪一個原因,是不是只要換成Kanban就解決了?

鄉民甲:當然是解決了啊,Kanban根本沒有sprint(iteration),更沒有要求要舉辦sprint planning meeting,本來無一物,何處惹塵埃。連sprint planning meeting都不需要開了,當然就不可能連開五天啊。

沒錯,Kanban沒有sprint也沒有要求要開sprint planning meeting,那請問原本團隊在sprint planning meeting所做的「事情(討論需求、切割工作)」跑到那去了?總不可能憑空消失吧?

因為Kanban沒有sprint,團隊以一種「事件驅動」或是「非同步」的方式來消耗(實作)需求。能量不滅,原本需要五天來討論的需求,並不會因為改用Kanban之後而變成一天。運氣好的話團隊還是花了五天的「總時間」來做原本「錯誤版」sprint planning meeting所做的事情,只是這五天被分配到不同的需求項目上面。運氣不好,因為沒有sprint以及sprint review,團隊一下子沒了「time-boxing」的壓力或是節奏感,可能花費更長的時間在up-front design之上,最後的結果就是很長的平均lead time(交期)。

***

不管是採用Scrum,最後導致sprint planning meeting花了五天,或是改用Kanban,乍看之下避免了sprint planning meeting花五天的問題(因為根本沒這個會議),但卻形成很長的平均lead time,這些都是一種「病徵」,並不是Scrum或是Kanban的問題。改善的契機就來自於有一套機制將這些病徵凸顯出來,然後團隊去正視它,謀求解決方案。而不是閉上眼睛就以為看不見,人云亦云的認為Kanban比Scrum好,或是Scrum比Kanban好。

Scrum和Kanban這些方法,有它們的長處,也有各自的限制。知道這些長處與限制,人才可以駕馭方法,而不是被方法給駕馭。

有人說,軟體開發最難的事情就是讓大家「動腦筋」,年紀越長越覺得這句話很有道理。

***

友藏內心獨白:有空多看點柯南或偵探小說。

1 則留言:

  1. 這就跟要有中暑才刮的出痧一樣 (咦...不確定是不是真的一樣...),不是刮痧棒的錯,而是你真的中暑了。

    回覆刪除