Ruddy Lee 分享空間

Emergent Design 演化設計

看板方法: 視覺化 Visualize

leave a comment »

視覺化 Visualize

(實施看板方法的第一步驟;這是經常被簡單幾句話就輕描淡寫帶過的步驟,其實它非常重要也很有些難度,所以我多囉說二句,有疑問的地方趕緊去查清楚! 一知半解會誤大事的)

視覺化;是指把工作的流程畫出來。也就是把產品開發作業所進行的工作步驟用簡單的圖形描述出來讓大家都看得見。換句話說;就是我們自問是怎麼工作的? 然後具體一點把它畫出來

範例一: BUG的修復作業流程圖示

first board

取材自Henrik Kniberg所著的"Kanban 與 Scrum 相得益彰"

上面這一張圖是缺陷BUG的修復作業流程圖示。從 Bug found 的電話紀錄報告,一直到修改後正式 Relaese的時間。我們將增值的部分與全部花去的時間進行比較,得到下面的結果:

有附加價值的時間總和 (黃色部分) = 2 MINS+ 5 MINS+ 5 MINS+ 1 DAY+ 2DAYS= 3,6 Days

Total Time (全部時間總和)=  33 Days

       Valuse added time (3,6Days)Total Time (33Days)=  11%  產出率

 ※ 透過視覺化現有的價值流程圖,我們可以將整個流程忠實的顯示出來。

範例二: 遊戲公司開發、上市作業流程圖示

game corp. evelope timeline 1

.

這種圖形我們稱它為價值流程圖 VSM: Value Stream Mapping 。上半部;是開發作業的各個環節,下半部;是針對它們所花去的時間統計。在工業製造上;它是指產品從原材料至最終成品所需要的活動。在軟體開發上;專注的目標就由產品移到工作者對工作項目的行為上頭。那應該從哪裡開始呢?

.

先選定範圍:

(由需要包含進來的工作項目開始,先設定起始點及終點。)

首先要確定的是這個需要包含進來的工作項目,它是我們可以控制的嗎? 若是無法控制的起點,最好是以一個註解的方式或把它視為外部(合作夥伴)的輸入點。主要考慮的是它的輸入特性(例如:瞬間大量的輸入特性或是連續穩定輸入的方式),而沒有必要在看板上把它歸納進來。所以「選定範圍」是一開始最重要的步驟。將起點與終點選定下來的工作,它可能會影響到實施看板方法的整體效能,經常會不容易做決策,但有一個簡單的原則可以參考: 那就是試問;它是我們可以控制的項目嗎?

.

※ 看板牆的型式由工作類型來決定

典型的工作類型有: 需求Requirement、功能特性 Feature、使用者故事 Userstory、使用者案例 Use case、變更請求 Change Request、產品缺陷 Production defect、維護工作 Maintenance、重構Refactoring、錯誤 Bug、改進建設 Improvement suggestion、受阻問題 Blocking issue …等等。一般是根據工作項目的來源、工作流程或規模來定義不同的工作類型(市場上的電子化看板都附有許多現成的模板可以善加運用)。看板好用,在許多方面你都會經常運用到它,所以請注意命名。

看板命名1

上面圖示是我常用的幾種看板類型,明顯的看板的命名應該與它的工作類型相吻合,然後再加入客製化,這會讓它變得有意義且容易記憶得多了。

.

※ 繪製看板牆 Card  Wall

卡片牆是用來呈現針對工作項目所進行的活動,而不是用來描述特定的職能或職務的活動。要注意的是對工作項目建模而非工作的人員。先畫草圖是一個簡單的開始,但老實說;我已經很久沒有畫草圖了。因為數位看板太方便了,我現在都是藉助數位式的看板,直接在上面修改圖形,方便極了。畫完了就可以立刻跟團隊的成員討論、找遺漏的地方、找錯誤的地方,有效率極了。(下圖取自 Leankit.com)

LeanKit 所支援的 Templates

LeanKit 所支援的 Templates

.

Davaid J. Anderson 曾經說過,優秀的團隊堅持使用實體的看板。這一點我完全同意,但是我通常會要求二者都使用。數位看板便利於個人使用,讓我無時無刻都能思考或檢查看板的狀態,也便於遠端使用或討論。(真正有問題的反而是,團隊成員經常使用不同的數位看板,意見很多。解決方法是辦一個使用說明會,讓他們各自展現所能,這是最好的教學了,效益很大,讓團隊一起做決定,能發揮自我組織的功能)。而實體的看板便於站立會議式的討論,效益也最大,是作為即時決策的最佳方式,不能缺少。

.

根據請求的多寡分配產能

產能分配 1

基本上是依據請求的多寡來分配產能。上圖是我的個人看板,我運用顏色來區分不同類型的工作。黃色是我的正常工作(教學、演講)佔 50%,藍色是我正在撰寫的程式佔 20%。綠色是對我的健康有幫助的工作事項佔 20%。紅色是家庭事務佔10%。我是依據它對我的重要性做百分比的分配的。一般對資源的分配可以視"請求的多寡“來分配,但工作類型才是真正的依據。例如: Bug 就是一個特別的類型,當程式有嚴重、緊急的錯誤發生時,可能需要較多的資源或立即的處理。但也有不是那麼緊急的問題,可以放置一段時間在處理。因此也不能忽略工作事項的大小、重要性…等等,也是調配產能的一種依據。

.

處理並行的活動

繪製看板牆的時候經常會發生可以並行的活動。例如開發和測試。把它們分開處理跟合併處理的差異在哪裡呢? 在WIP的限制數減少了! 當合併時會減少工作項目的數目,因此WIP的限制數就減少了,但那是假象。當我們放任大的功能項目(或是較大的使用者故事)進入看板流程時,就會很容易在解讀看板狀態時感覺到這是一個大顆粒的工作項目,怎麼辦呢? 基本作法是: 先進行分解再修正WIP值

當遇到更多並行的活動時該如何是好? 有時候他們是有順序性的,但有時後又完全沒有,如何建模呢? 此時可以採用排隊(queue)的方式,也就是增加一個垂直欄位來處理,又扯到排隊理論了,有機會再來談。

.

結論一下:

視覺化;完成看板牆的外框設計是第一步。接著是將一個一個的工作項目製作成工作卡片,然後對這些卡片進行優先順序的排列,接著把它們放到第一個Ready的垂直欄位內,我們就可以準備進入下一步: 限制WIP數量的步驟。但在此之前,應該要先制定運行看板方法的簡單規範,也就是讓團隊在站在看板牆的前面時,知道自己要做甚麼(這一點很像在進行SCRUM的站立會議,就是必須說三件事一樣),這可以藉由簡單規則來實行團隊自我管理的動作。也可以做為保證團隊協同合作的基礎,這一塊一直是Kanban Method 所沒有觸及到的區域,我們下一回就來談論這個話題 — 如何為執行看板方法的團隊制定簡單的規範

.

(寫起來好像挺簡單的,三言兩語就說完了,但實際上要畫好VSM,得要團隊一起來,很辛苦的。上回我花了四天才弄出個像樣的流程圖,前前後後可能問了1000次為什麼。但它實在很重要,再辛苦都是值得的!)

Written by ruddyllee

2014 年 10 月 13 日 於 12:36:09

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 變更 )

Twitter picture

You are commenting using your Twitter account. Log Out / 變更 )

Facebook照片

You are commenting using your Facebook account. Log Out / 變更 )

Google+ photo

You are commenting using your Google+ account. Log Out / 變更 )

連結到 %s

%d 位部落客按了讚: