July 30 12:47~13:55
Teddy有個朋友，去年剛接觸到Kanban，覺得「如獲至寶」…
朋友：哇賽，Kanban沒有規定固定時間的開發週期（iteration），從工作流（flow）的角度來管理開發流程，真的是太棒了。
Teddy：借問一下，iteration是哪裡得罪你了？
朋友：一開始我覺得IID（iterative and incremental）的開發方式很好，尤其是短時間的iteration（兩周），讓團隊成員可以在限定時間內專注完成工作。
Teddy：那現在怎麼又覺得不好？
朋友：因為我們的需求經常在變。
Teddy：很好啊，敏捷開發本來就是要應付需求變化。
朋友：可是有時候我們在一個iteration還沒結束的時候，需求又變了。之前我想用Scrum，但是Scrum希望在一個sprint之內，不要隨便變動已經規劃好的需求。這一點讓我很痛苦。
***
幾個月之後…
Teddy：你改用Kanban之後，原本需求變動的問題有解決了嗎…
朋友：怎麼說，以前Scrum希望在sprint進行時儘量不要改需求，比較會強迫PO去思考接下來要做什麼，不會隨隨便便亂丟工作給開發人員。改用Kanban之後，沒有PO這個角色，負責訂定需求的人經常隨隨便便就加工作，等到工作被施工之後，開發人員才到處找人問這個工作到底是要做什麼。雖然拿掉iteration好像變彈性了，但是結果拉長了每件工作的完成時間，工作一直拖延，好像有點又回到以前waterfall的情況。
Teddy：Kanban不是說要藉由視覺化的工作流程，來觀察工作流卡住的地方，然後尋求改善嗎？
朋友：講是這樣講，但是大家工作各做各的，忙的人還是很忙，閒的人還是很閒，卡住的人還是卡住。
Teddy：不是說要想辦法減少lead time嗎？
朋友：Kanban不要求估算活動，後來我們也都沒有估算工作大小，所以對於什麼是「合理的lead time」，也很難判斷。每件開發工作，都是看開發人員實際上做多就，就是多久。問他們有沒有問題，大家都說沒有….
朋友：所以我們最近打算回復到過去讓PM來估算每一件工作完成的時間，以此來作為lead time的參考值，用來稽核開發人員有沒有偷懶。
***
Iteration本身代表某種「節奏」，Teddy認為有節奏這件事對於軟體開發是好事。在Scrum中，至少有三中不同的iteration：
- Sprint：2~4周，這也是Scrum最重要的iteration，許多活動，像是sprint planning meeting、sprint review、sprint retrospective，分別伴隨著Sprint的開始與結束進行。
- Daily Scrum：24小時發生一次。
- Product Backlog Refinement Workshop：有兩種方式，一種是在每個Sprint進行到約一半的時候，發生一次。另一種是有需要的時候隨時發生（事件驅動）。如果採用後者，這個活動本身不是iteration-based，就比較像是flow-based或是event-based。
Scrum的iteration，比較僵化的地方，可能在於許多活動（各種會議與開發活動）伴隨著（綁定）iteration而發生，而不是各自有各自的發生時間。如果sprint planning meeting、sprint review、sprint retrospective、daily Scrum、Product Backlog Refinement Workshop這些會議，可以和開發活動脫鉤，各自有各自發生的週期或是節奏，針對某些專案，運作起來會比較有彈性一些。
Kanban沒有iteration，但為了維持工作順暢的流動，在Kanban中有「節奏」（cadence）的概念。Cadence是定期間隔所發生一次的事件，這個「定期間隔」可以是固定的時間，例如2周，也可以是連續、事件驅動。例如，一周重新調整一次待辦需求的優先權、平均18天可以完成一個功能、1個月針對流程改善開一次檢討會議、2周把完成功能能正式對外釋出、只要功能完成隨時招開review會議等。
***
Iteration本身只是「一個固定長短的時間盒（time box）」，拿掉iteration只是讓各種軟體開發活動與單一（主要的）iteration脫鉤，不等於不需要估算、討論需求、排定需求優先權、review、retrospective。軟體開發原本該做的事，並不會因為你用Scrum或是Kanban而消失。Teddy常說的一句話：「能量不滅」，該做的基本功沒做，有一天它會在不預期的地方，跑出來咬你一口
***
友藏內心獨白：不同活動有各自的節奏，這也算是separation of concern的應用。
。
。 
。
。
。
。
。