開發管理武功心法總匯,你適合用看板(Kanban)、Scrum,還是兩者合一呢
一個專案管理法不夠,那你有用兩個嗎?
還記得我們在前兩篇的文章裡,
一、看板心法概述:
1.工作流程實際化視覺化
A.把團隊的工作流程,
B.把工作內容切割成更小的區分,變成我們卡片上,
2.限制WIP,減少卡片在看板裡流動的時間(Lead Time)
A. 將每一個工作階段可以停留的卡片,去作出明確的界線,
B. 記錄每一張卡片在看板起訖點流動的時間(Lead Time),成為下一次優化流程的依據
3.看板核心規則
流程視覺化,WIP限制化,工作順暢化
二、Scrum心法概述:
1.切割切割,再切割
A.以軟體開發為案例,是著將限有的、組織較龐大的部門,
B.記得在SCRUM團隊裡面,具備PO、
C.工作透過UserStory來具現化,
D.每一個切割完成的最小化任務(卡片),
E.把工作時間切成1-4週為主的Sprint,固定循環,
F.定期交付客戶,定期修正目標,以變為不變的忠旨及核心
2.Scrum核心規則
需求視覺化、最小切割、有效排序'、定期交付,
三、你適合用看板,還是Scrum呢
在上面小編快速更新完看板與Scrum的核心理念後,
名稱 |
Scrum |
看板 |
檢討週期 | 必須依照Sprint作定期的交付、檢討 | 沒有特定的產出及檢討時間, |
看板週期 | 每次Sprint後重啟看板週期 | 流程變動前、可一直延續使用 |
產出承諾 | 每一次的交付都必須有承諾, |
沒有產出的承諾,僅可透過看板來了解目前每一個需求被執行的階段 |
改善依據 | 每次Sprint檢討BrunDwonChart的燃盡狀況來檢 |
使用每一次需求(卡片)的停留時間來作為流程改善的依據 |
任務優先排序 | 在product backlog及卡片上,都必須要有優先(交付)順序的訂定 | 除了快速通道的急件外,沒有任務優先的排序 |
卡片大小 | 卡片可透過StoryPoint來檢視卡片的大小和執行的預估時 |
卡片無法確認實際的大小 |
追蹤 | 可以用Brundown Chart 追蹤 | LeadTime追蹤需求開發狀況 |
需求加入限制 | Sprint開始後無法加入新的需求, |
WIP容許,可以增加新的需求 |
建議團隊特性 | 最好是跨功能的單一團隊 | 沒有指定團隊,但適合使用跨部門的團隊 |
適用團隊屬性 | 由單一團隊執行 Sprint / Product Backlog | 可以多團隊、多成員檢視看板 |
特定角色 | 必須要有ProductOwner、 |
無特定角色 |
現有團隊現制 | 必須打破現有的團隊現制,並且編制出Scrum的團隊 | 無團隊現制 |
共通性 |
||
1 |
不論是流程、階段還是需求,工作必須要可視覺化 | |
2 |
定期追蹤、並且依據每一次的執行狀況作定期改善 | |
3 |
都必須對現有的流程中提出限制,作為團隊的保護傘, |
四、Scrum與看板的衍生型,你也可以來試試看
相信大家從比較表裡面可以查到一點端倪,
然而當公司本身也依照不同的開發屬性,
這時候可以為各位介紹「Scrum of Scrum」,
相信讀完今天這一篇文章之後,對於你的開發管理的功力,
最後,如果你喜歡我們的文章,別忘了到我們的FB粉絲團按讚喔!!