推理就好

Jan. 19 18:40~19:20

 

一位朋友告訴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這些方法，有它們的長處，也有各自的限制。知道這些長處與限制，人才可以駕馭方法，而不是被方法給駕馭。

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

***

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