Slow-start：導入Scrum首部曲

Sept. 12 16:06~18:00

 

前幾天有一位參加過八月份「Scrum敏捷方法實作班」的學員（簡稱學員W），在Facebook上面專為學員設立的「ezScrum課程社團」中問了一個問題（Scrum不是上完課就結束了，Scrum的導入是在上完課程之後才開始，所以上過Scrum課程的學員可以透過Facebook社團獲得售後服務）。

以下是問題的內容：

***

請問如果我們有做Code Review，這部分是要另外寫個Story嗎? (Technical Story?) 還是切成Task？

可能是因為剛開始做Code Review，所以很常發生Task A有人已經做完，移動到Review上，結果負責Code Review的人在過了一天之後發現不少需要修改的問題，所以把Task A又移動回Checked Out，這樣來來回回N次，花費的時間也的確不少

p.s ，我們會在Code Review會議後更改原先的Task A的時間，但好像應該都是要在Daily Scrum上更改才對喔@@?可是在Daily Scrum上討論Code Review會耗掉很多時間....

***

因為Teddy這幾天脖子不舒服的老毛病又犯了，想要少打一點字，於是就請學員W打電話給Teddy，直接在電話中答覆他。經過詢問之後，原來這個問題是這樣滴。學員W在上完Teddy的Scrum課程之後回去開始導入Scrum，在此同時，學員W又希望也推行code review，也就是所有的task在做完準備移到Done這個狀態之前，都要先被review過。所以，學員W就把如下圖所示的一般最簡單的taskbaord，加入一個新的狀態，

最簡單的taskboard，只有not checked out、checked out、done這三個狀態。

 

就變成了類似下圖的taskboard，多了一個Review狀態。

 

路人甲：然後呢？

然後就發生了學員W所說的鬼打牆現象：「可能是因為剛開始做Code Review，所以很常發生Task A有人已經做完，移動到Review上，結果負責Code Review的人在過了一天之後發現不少需要修改的問題，所以把Task A又移動回Checked Out，這樣來來回回N次，花費的時間也的確不少」。

請問鄉民，有何良策？

***

當年Teddy在修電腦網路這門課的時候，有學到一個TCP控制流量的方法，叫做slow-start（車子剛起步的時候要開慢一點XD）。假設你有1MB的資料要傳，最快速的方式，當然是一次把這1MB的資料往傳輸線上面丟啊。但是，當你一口氣往外丟的資料量越大，就會把整個網路頻寬用掉，如果別人也同樣一口氣把要傳輸的資料往外丟，大家的資料就會塞車，最後可能導致於很多封包都time-out，結果要重傳。也就是說「做白工」的機率也會越高（因為大家都卡住了，結果封包過期需要重傳，等於做白工）。所以有人想出了slow-start這個招數，在剛剛開始傳輸資料的時候，先慢慢傳，如果一切順利，再逐次加大傳輸量。

看到這邊鄉民們一定會想說Teddy又在鬼扯什麼，這和剛剛學員W的問題有何關係？

因為學員W才剛剛開始要導入Scrum，但是在此同時又希望程式碼的品質也能立刻提升，所以增加了code review這個階段。但是，Teddy建議學員W，因為要讓團隊熟習Scrum框架本身就是一件需要花時間的工作，所以一開始先利用幾個sprint（也許2-4個月）讓團隊成員（PO、SM、Team）慢慢習慣在Scrum框架下的合作模式。例如，剛開始時PO寫出的story可能不夠完整（沒時間寫how to demo），或是團隊在sprint planning meeting時溝通不夠，導致真正施工的時候問題很多。也可能developer發生問題時都不主動尋求支援，等最後sprint review meeting時才發現很多宣稱做好的功能都有問題。

在團隊成員剛剛開始導入Scrum的磨合期，如果一次劈哩啪啦的丟出太多東西，Scrum也要學、unite test也要做、還要架持續整合系統、做code review、看測試涵蓋率報表等等。團隊成員保證翻臉，你的Scrum當然也run不下去了。

既然一開始跑太快容易發生太多塞車，所以還是採用slow-start策略，等「平台穩固」（團隊慢慢熟悉Scrum）之後，再來決定要導入那些工程實務做法也不遲。

***

結論就是，Teddy建議學員W把Review這個階段拿掉，先不要想太多，用最簡單的方式開始第一個Scrum專案，這樣比較容易讓團隊接受。古人不是也說：「吃緊弄破碗（吃太快可能會不小心打破碗）」嗎！

***

友藏內心獨白：簡單，並不簡單。