進度條

開發管理武功心法總匯,你適合用看板(Kanban)、Scrum,還是兩者合一呢

一個專案管理法不夠,那你有用兩個嗎?

作者: Vincent Ke 更新日期:

還記得我們在前兩篇的文章裡,介紹了看板與Scrum這兩種針對軟體開發上,所建立的管理心法嘛? 目前這兩種心法,在台灣軟體業的管理上已經是相當常見,然而,依據團隊的屬性不同,適合的管理方式當然也會隨之調整,所以現在也有許多看板與Scrum的複合型管理方式,也是屢見不鮮,而今天要為各位對看板和Scrum作一個快速的重點提醒及總結,讓大家可以更直覺地使用在自己的工作實務上面,而遇到一些許多跨團隊的大型專案,也可以把這兩種管理心法,伸縮自如的套用在自己的團隊中。

 

 

一、看板心法概述:

1.工作流程實際化視覺化

A.把團隊的工作流程,依照現有的流程依照階段的順序性去歸納出來,並區分為「進行中」和「已完成」二大階段

B.把工作內容切割成更小的區分,變成我們卡片上,並依照屬性去作歸類,例如:功能開發、Bug、功能優化...等等。

 

 

2.限制WIP,減少卡片在看板裡流動的時間(Lead Time)

A. 將每一個工作階段可以停留的卡片,去作出明確的界線,以及在該階段內可允許有多少的卡片可以作停留

B. 記錄每一張卡片在看板起訖點流動的時間(Lead Time),成為下一次優化流程的依據

 

3.看板核心規則

流程視覺化,WIP限制化,工作順暢化

 

 

 

二、Scrum心法概述:

 

1.切割切割,再切割

A.以軟體開發為案例,是著將限有的、組織較龐大的部門,切割成更更小的,具有自我組織的團隊,我們可以依照開發專案的類別來切割,是一個不錯的方式

B.記得在SCRUM團隊裡面,具備PO、SM以及開發團隊等三種角色

C.工作透過UserStory來具現化,並且切割成更小的功能和任務

D.每一個切割完成的最小化任務(卡片),必須依照連帶關係及優先順序來作需求排序。

E.把工作時間切成1-4週為主的Sprint,固定循環,固定交付

F.定期交付客戶,定期修正目標,以變為不變的忠旨及核心

 

2.Scrum核心規則

需求視覺化、最小切割、有效排序'、定期交付,透過定期整合窺見產品全貌

 

 

三、你適合用看板,還是Scrum呢

在上面小編快速更新完看板與Scrum的核心理念後,是不是覺得記憶猶新呢,但依照每一間公司組織、習性、甚至是專案管理的方式上,都不盡相同,而看板和Scrum的特性除了上述幾點的快速整理外,小編也特別整理了一項比較表,讓大家可以一目了然各別的差異性,而各位也可以依據最後自己團隊所執行的方式,來決定要使用什麼樣的工具,輔助團隊開發及管理的視覺化。

 

名稱

Scrum

看板

檢討週期 必須依照Sprint作定期的交付、檢討 沒有特定的產出及檢討時間,而是依照卡片的停留時間來作檢核的依據
看板週期 每次Sprint後重啟看板週期 流程變動前、可一直延續使用
產出承諾 每一次的交付都必須有承諾,例如這次的Sprint將要產出多少功能 沒有產出的承諾,僅可透過看板來了解目前每一個需求被執行的階段
改善依據 每次Sprint檢討BrunDwonChart的燃盡狀況來檢討團隊效能 使用每一次需求(卡片)的停留時間來作為流程改善的依據
任務優先排序 在product backlog及卡片上,都必須要有優先(交付)順序的訂定 除了快速通道的急件外,沒有任務優先的排序
卡片大小 卡片可透過StoryPoint來檢視卡片的大小和執行的預估時間,並且卡片必須要被最小化 卡片無法確認實際的大小
追蹤 可以用Brundown Chart 追蹤 LeadTime追蹤需求開發狀況
需求加入限制 Sprint開始後無法加入新的需求,但可在每次Sprint後增加新的需求 WIP容許,可以增加新的需求
建議團隊特性 最好是跨功能的單一團隊 沒有指定團隊,但適合使用跨部門的團隊
適用團隊屬性 由單一團隊執行 Sprint / Product Backlog 可以多團隊、多成員檢視看板
特定角色 必須要有ProductOwner、ScrumMaster及開發團隊等三種角色 無特定角色
現有團隊現制 必須打破現有的團隊現制,並且編制出Scrum的團隊 無團隊現制

共通性

1

不論是流程、階段還是需求,工作必須要可視覺化

2

定期追蹤、並且依據每一次的執行狀況作定期改善

3

都必須對現有的流程中提出限制,作為團隊的保護傘,但也必須預留更改的彈性,以"變"應萬變

 

 

四、Scrum與看板的衍生型,你也可以來試試看

相信大家從比較表裡面可以查到一點端倪,看板對於公司本身的組織性裡,比較不會有突破性的破壞,僅管無法把任務作到最小化的切割,但是在跨屬性的跨團隊合作裡,比較容易作到有效的追蹤,也可以作到跨專案的管理。而Scrum比較偏向在每一個開發專案上的管理以及追蹤,在大小的定義上的確是略有不同。如果你是PM又必須身兼各種多樣的專案管理,那在進度的追蹤上,也許看板會比較適合,在依據每一個專案/產品的產出上,在個別使用Scrum去作定期產出的追蹤,並且作為與客戶討論溝通的視覺化橋梁,讓看板作為追蹤Story的用途,在去用Scrum去作每一個開發項目的切分,這是一個不錯的方式,也是現在小編所使用的方法

 

 

然而當公司本身也依照不同的開發屬性,去給工程師作出了不同的屬性切分,例如測試工程師、分析工程師(SA、SD)、技術文件撰寫的工程師..等等時,成員已超出了原先Scrum人數,並且無法作到跨團隊、組織上的打破和重組時,我們還可以怎麼運作呢?

 

這時候可以為各位介紹「Scrum of Scrum」,也就是字面上的透過多層Scrum來運作Scrum的方式,首先可以先針對專案/產品來作出一個縱觀全局的Scrum Board,接著再依照團隊屬性(例如測試、文件撰寫、開發、美術設計..等等),去作不同的個別細層Scrum。針對每個團隊所使用的Scrum,進行每天的Daily Scrum之後,在由團隊指派一人,再一起開會討論針對產品本身的大Scrum去作Daily Scrum,討論的問題也從團隊的個人細部目標,變成「昨天你的團隊做了什麼」、「今天你的團隊預期準備做什麼」、「團隊當中是否有遇到任何的阻礙」、還有最重要的,「你的團隊正在工作的事項與排程,是否會影響到其他團隊」。因為每一項工作都會有著不可分割的密切合作與劃分,唯有使用團隊的概念作切分,並且正確的排出每一個任務的優先與連帶關係,才可以用Scrum of Scrum的概念來掌握每一個團隊的進度。

 

 

相信讀完今天這一篇文章之後,對於你的開發管理的功力,一定會更進一步,試著把這些想法,用Jira和Trello來具現化吧,只有往前踏出,才是實踐管理的第一步!

 


最後,如果你喜歡我們的文章,別忘了到我們的FB粉絲團按讚喔!!

Medium vincent

Vincent Ke

喜歡把混亂的事情變的簡單 用嘴巴做事其實很可以 但要結合靈活的腦袋思考 就一起來拆解吧