如何利用Kanban幫助團隊度過黑暗期？
2016年6～8月，這兩個多月對我們團隊來說是生死一戰，當時接手一份Legacy code，目標是在八月底前換掉無人可以maintain的server。這段期間團隊陸續進來幾位新人，透過獵人頭公司hire的（自己公司hire的好慢，隔了幾個月才招滿），駐點在我們部門，能被留下來的能力都很不錯，感覺就像軟體界的傭兵，沒受過scrum training，所以像點數的估計、user story的撰寫、允收條件這些都不會，好在這階段主要的任務都是很明確的開發task，同時需要解bug，由於進度也算順利，所以PO也覺得無所謂，倒是反問我Scrum一些有的沒的要求，會不會成為團隊前進的阻力？所以我去上了David的Kanban課程，試圖為團隊找尋一個更好的運作方式。
先說總結，Kanban在這段期間解決了我們團隊什麼問題？
- 讓團隊清楚目標，同時確定所有的火力都用在對目標有幫助的事情上。
- 有WIP的限制，事情有沒有做完，有沒有卡住，一眼就看得出來。
- 讓不熟Scrum的團隊可以先習慣定期release的步調。
- Stakeholder(老闆）走到白板就可以看出團隊在忙啥。
- 急件通道可以讓團隊清楚什麼是最優先需要處理的。
一開始我先把在紙上畫了好幾個版本的Kanban board，然後找了塊板子先試貼看看，馬上就發現我需要一個超大白板，所以立刻訂了一個型錄上最大的、有輪子的雙面白板（如果你也想用Kanban，一個大的白板超重要）。
 |
| 紙上模擬 |
 |
| 剛開始的Kanban |
一週之後，開始多了些備註，所以多了些小張的便利貼。
 |
| 有點感覺 |
再過一週，白板來了之後，我們主要的關卡也訂出來了，原本只有APP team試run，後來Server覺得不錯，也加入一起用。
 |
| 白板來了 |
這是最後的版本，其實我在另外一面牆還把大家的bug burn down chart貼出來，離目標倒數10天前，開始每天把大家身上的issue數update出來，利用這個方式提醒大家update redmine，而不是靠自己每天碎碎唸。
 |
| 最後的版本 |
有些強迫症的小夥伴就會自己去清，大家就會不吝嗇的給予讚美。
 |
| 有人很拼 |
最近讀完「目標」這本書，發現書中找尋瓶頸的過程，跟定義Kanban上的流程與WIP，根本就是同一件事，而主角跟同事討論的過程，就是retrospective的一種，讓我對Kanban跟限制理論又多了更多領悟。
但是2016年10月之後，我們團隊面對了不一樣的問題，所以後來就沒有繼續用Kanban了。
