Sep. 01 14:00~15:16
在Scrum中，需求（代辦事項）放在product backlog裡面，稱為product backlog item（PBI）。在Kanban方法中，代辦工作稱為work item（工作項），這些work item通常會寫在一張卡片上面，然後放在kanban board上面，雖著工作被拉動，由左往右流動。
有些Scrum實施者把PBI區分為user story、quality story、technical story、bug fix，分別代表不同類型的工作。Kanban也有類似區分工作的方式，常見的分類有：
Urgent/Expedite
緊急/加急類，這一類的工作表示必須要立即處理的突發狀況。就好像高速公路的路肩或是醫院急診室，被設計來應付緊急狀況一樣，針對urgent的工作，通常會在kanban board上安排一個專用的「泳道（swim lane）」來觀察工作的流動狀態。Urgent的工作擁有特權，它可以暫時打破每個工作流程的WIP上限，而且所有的資源要優先讓出來給它使用，以利在最短的時間內完成。
看到這裡鄉民們可能會想，這是什麼爛分類，專案經理跟老闆一定愛死了，所有的工作都是urgent，那鄉民們不是忙死了？Urgent的工作雖然可以享有「快速通關」的禮遇，而且可以打破原本工作流程所設定的WIP上限，但是同時間只能有一個urgent工作。也就是說，urgent類的工作有自己的WIP，也就是1。這樣子兼顧了團隊處理緊急事故的彈性，也維持了處理日常工作的穩定性。
以醫院做為比喻，大部分的病人還是應該要看門診，急診室要留給真正緊急的病患。
***
Fixed Delivery Date
固定交付日期類，有些工作如果錯失了交付日期就失去了意義。例如，要在電腦展展出新產品、在報稅季節提供報稅軟體，或是和客戶簽約，如果延遲交付會有巨額的罰款。這種預先知道交付日期的工作，可以依據歷史lead time做為參考依據，來判斷何時應該開工。假設以往的工作平均交期是10天，有一件工作必須在9月20日交付，則最晚應該在9月20日之前的10個工作天開始時作該工作。
一般來說，fixed delivery date的工作優先權僅次於urgent的工作。當fixed delivery date的工作流經kanban board的時候，團隊需要特別留意是否有滯留或阻礙的情況。如果發現可能無法在預定的時間完成，也可以把fixed delivery date的工作「升級」成urgent的工作（前提是當下沒有其他urgent類的工作正在被施工）。
***
Regular/Standard
正規/標準類，這類工作應該是所有工作中比例最高的。Regular工作沒有固定的交付日期，但是開發團隊在處理這類工作的時候，要在保持品質的前提之下，儘量縮斷lead time。
前三項分類，都是從時間的角度來區分工作。Urgent的完成時間是ASAP（as soon as possible），fixed delivery date是固定時間，而regular則是在服務urgent與fixed delivery date的工作之餘，儘量完成。
***
Intangible
無形類，這類工作相當於technical story，例如，你完成了refactoring改善設計品質、引進持續整合解決整合的問題、升級了資料庫或是瀏覽器版本，這些「工作」，從使用者、客戶的角度來看，通常無法立即感知它們的存在、好處、價值，但是為了產品開發可以長久順利持續進行，又非得安排這些工作。
***
Defect
缺陷類，也就是俗稱的bug。這類工作相信所有鄉民都對它非常熟悉，軟體的缺陷越多，開發與維護成本就越高。將缺陷單獨區分一類，可以提高開發團隊對於品質的敏感度。
***
以上前四種分類是Anderson所建議，《Kanban in Action》這本書建議加上defect這種分類。不同類型的工作，需要不同的處理策略，將工作分類，可以壤團隊規劃資源安排與決定輕重緩急。這在日常生活中也是一個很常見的做法，例如，飛機的票種有分頭等艙、商務艙、經濟艙，不同票種有不同的價格，享受不同的服務等級。
在實施看板方法的時候，建議將不同類型的工作，寫在不同顏色的卡片上面，藉此在kanban board上可以一眼就看出來。關於工作項目卡片（work item card）的設計，將在日後介紹。
***
友藏內心獨白：亂用八百里加急，會被革職查辦，鎖拿進京。
"儘量縮斷lead time。"
回覆刪除斷 -> 短？