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。"
回覆刪除斷 -> 短?