回顧Day 3的假想成員組織 :
有別於之前開發狀態可以預先規劃,一般上線後都是「遇到一個問題,解掉一個問題」。
在商業策略的考量下,
上線中服務出現問題的優先處理順序必定高於開發中問題的處理順序。
在運營的階段,Scrum 角色可能如下列表格 :
PO | 總經理 |
---|---|
SM | 總經理、業務部經理 |
Dev | 後端工程師x3、前端工程師、運維工程師x6、業務專員x10 |
Scrum 導師(SM)
的角色,在這個階段更像是一個監督者。主要的工作內容就是問題單
有被解決,沒有被延宕。
另外,也會適當的反饋操作上是否 user friendly,否的話則提出修改需求。
因此,在這個階段中,業務專員
是所有「Task 卡片」的提供者。
為了因應運營狀況,我們將 Scrum 看板再次調整如下 :
其實就是多了一個問題已解決
的貯體。業務專員
發現問題後,在代辦事項
貯體中製作「Task 卡片」。當工程師與程式設計師們認領並完成修正後,再將卡片設定已完成。Scrum 導師(SM)
再把完成的卡片拉至問題已解決
貯體中。
Scrum 中的看板與傳統的 Kanban 最大的差異就是: Scrum 看板可視實際的任務需求不段地疊代調整,而 Kanban 就只是單一的視覺化流程。
對於兩者差異想進一步了解的,可參考Kanban vs. scrum: which agile are you?
明天在來分享下此階段「Task 卡片」要注意的細節。