看板驅動開發(KDD)

.

何謂看板?

就是將團隊的工作步驟畫在板子上,讓大家都看得到進度,然後在工作進來時嚴格的規範一次只作一件事,然後就按步就班的把工作由左往右拖拉過去,一直到完成。並運用限制半成品數的方式來調整各個欄位的可同時進行的工作數目,依此限制來調整工作流程的速度。

.

何謂「看板驅動開發」呢?

就是在實行 DevOps 時運用看板方法,將無論是測試、度量等額外的工作都能融入工作流程中,目標是向上將三步工作法視覺化的方法。向下將工程師真正的工作內容透明化。

.

0005_1

KDD 是協助企業將商業需求 + 開發 + 運維接合起來的精實開發方法

.

實行看板驅動開發可以解決工程師太忙的問題?

.

視覺化你手頭的工作

讓工作被看得見應該是讓工作變得開始井然有序的基本要求。如果你問工程師最近工作得如何? 幾乎所有的回答都是好忙喔!但其實你可以工作的很有秩序的。這一點運用把工作寫在memo上就能解決了,但時間稍稍拉長一些,一旦開始有插件的時候,就很容易故態從鳴,工作秩序又被打亂了。然而運行看板實質上就是要解決這種零亂失序的方法,看板的基本原則是嚴格遵守拉動系統(pull system),也就是單工作業。

.

拉動系統是一種單工作業的概念。

.

KDD 與度量.png

.

  • 度量必須與流程結合,成為流程改善的指標才不至於變成浪費。
  • 讓「定義完成」存在於每一個價值流的節點,成為一種回饋的機制。
  • 在 Safe to fail 機制下,在看得見的實驗中安全的失敗學得知識。

.

在運行DevOps時,倡導用看板來驅動開發作業,是因為看見有人在大力推廣DevOps 度量之下所衍生出來的問題,擔心度量會成為一種浪費,所以推廣將度量融入於看板運行中的方式,讓度量能結合於流程中,化浪費為進行學習改善的助力。

.

看板驅動開發(KDD)的目的是在運用看板來透明化工程師進行程式開發的過程,讓工程師看見自己是怎麼進行開發工作的,並依據記錄來分析自己的開發工作是否有足夠的效率,作為增進效能、持續改善的依據。

.

0030

常常被問到 “實行DevOps要從哪裡開始?

.

normal.png

運行工程師實際工作的看板

.

這麼作的原因是:

一、我們經常可以看到工程師在團隊站立會議之後,回到自己的座位上便開始進行一天的工作規劃,他們會用便利貼安排好一天該作的事,然後貼在自己個人的小看板上,開始他們在上班期間的工作。

》這個現象說明了工程師在上班期間不是只有作他在團隊看板上所認領的工作!其實還有許多事情都會佔據他的上班時間,而這些事在大看板上是看不見的,而這類的非開發工作,敏捷開發的因應之道是要求工程師盡量把這些工作之外的事務維持在工時的15%以內,盡量不去影響開發工作便可以了,但實際上;這是一種模糊不清的做法,對看板方法而言是一種不良的假設。

(我常常被工程師問道,這便是個人看板嗎?註1.)

這也是目前在一般團隊在運行看板時最不明確的地方,因為我們常常假設工程師每天都能擁有足夠的時間去進行開發作業,忽略了許多會消耗掉他工作時間的額外工作,例如:開會、協助解決問題、與他人進行溝通、處理緊急事件等等事情,都會大量的消耗掉工程師的上班時間。敏捷的一種解法是在估算的時候,以一個理想的工作日來作範圍的調整(例如在VSTS上頭,把一天設定成5小時)這麼作雖然給我們很大的彈性,但也隱藏了許多真實的工作事項,讓我們看不見事情的真貌不知道要進行改善,這一點很不符合精實Lean的精神。

二、工程師可以運用 KDD來分析自己一天的時間都用到那裡去了,藉此作為改善效能的依據。有一種現象是工程師不管再怎麼忙碌,但總能夠在第二天準時完成他的工作,他們常常會在不到二個真正工作的小時裡卻能完成超過四個小時的工作(Tasks),也就是二倍工作量的開發任務。當然原因可能是因爲他加班了,或是把工作帶回家去作了,但不論如何我們都需要弄清楚真正的原因,因為只有如此才能作為任務評估的真實依據,否則將始終看不到事情的真實樣貌。(主管如果把這種狀態視為是一種合理的現象,這種誤解往往會造成員工不能理解或不願配合公司策略的因素之一,因為它是不正常的,不該忽視它也不能鼓勵,大可私下稱讚一下他的負責盡職精神就好,實在應該找出原因避免重複發生)

 .

 

KDD是自我改善的依據,換句話說就是給自己看的

要先看見問題才能改善。過往寫程式的過程,就是坐下來coding就是了(當然你可能運用 TDD來加強邏輯思維的審密性或是配合團隊採用 BDD的coding模式來兼顧程式的品質),但總覺得好像少了些什麼,效能不夠沒看見全貌。這就好像跑步一般,一個簡單的計時器,能讓你知道自己的速度在那個區間裡,一段柔軟操能讓你一路不抽筋直到終點,小小的紀錄都能對跑步的成績有著巨大的幫助。而KDD就是這麼來的,試著想想看你要從那裡開始改善自己coding 的效能吧!但基本上還是先從客觀的看得見全貌開始,先看見自己一天工作的全貌,認知到自己在那裡,接著再來探討那些是需要改善的。

.

開發工作應該以達成任務為目標而不是依靠估算來作為完成工作的統計依據,所以必需以度量為基礎。

.

 

如何開始運行KDD?

先從看見自己的工作流程開始,然後把它紀錄下來,用 Trello 或 Bitrix24都行,重點是要有數據才能進行分析,要有看板才好調整WIP來進行改善作業。

 

.

simple kanban

在座位旁的牆壁,用便利貼試著開始運行KDD

.

找一個在座位旁的牆壁,或是買一塊小板子也可以(最終還是要數位化的,小板子可以維持紀錄著一、二天的進度),給出透明度讓大家都知道自己在做些什麼,數位的紀錄則很像跑步計時的馬錶一樣,是給自己參考的,只是拿來做改善用的(累積流程圖的展示價值會出乎你想像的好用的)。

你都有些什麼工作?!用不同顏色大小的貼紙來表示工作種類及耗時。甚至用特殊符號來展示你在進行工作時的心情、進度如何都OK。就照著實際來的工作忠實的記錄它,一開始先用「待辦 – 進行 – 完成」的最簡易看板作開始, 隨後在視需要進行調整。重點只有一個,就是忠實記錄,原則也只有一個就是維持單工作業,遵守作重要的事而不是作緊急的事(參考: 一個人如何施行敏捷)。用最簡單的方式來養成習慣,因為只有養成習慣才可能持之以恆。所以先設計好流程養成習慣,之後就容易持續下去了。

.

依比例分配.png

.

 

調整工作的比例

試著用比率的方式來看待你的工作項目,因為時間是固定的因此你唯一可以做的就是按比例來分配,然後給他們設定一個目標值,一個讓你覺得適合的比率,並在一段時間後來作回顧,這種作法可以幫助你掌握自己,同時又能增加自己的適應性。

 

.

process

工作項目的心情歷程圖

.

我很喜歡上面這個圖示,它讓人一目了然自己的厭惡及喜好,人應該要盡量忠於自己的感受。心情歷程圖讓我們知道要多做一點上面(高興區間)的工作,少作一點下面(困擾區間)的工作,上班時就會覺得幸福些。(這一點可以作為給公司的回饋)

 .

企業存在的意義有兩個:一是為社會創造幸福,二是為員工創造幸福。

– 智庫百科

.

學習是追求幸福的捷徑

寫程式本來就是一種學習的過程,而學習可以讓人心無旁騖專心沉浸在解題的過程中,事後又能產生高度的成就感(怪不得工程師常常會說,與其去參加無趣的活動,我寧可留下來寫程式),而敏捷所推行的學習型組織,正是一種最穩定又高效的組織型態。但學習確實是需要借助外在的因素的,KDD 可以幫你看見自己工作的歷程,而不是盲目的任憑感覺來模糊的作改善,依據看板真實的記錄來讓你作為行為改善的依據,自然能更為有效。

.

 

註1. 這便是個人看板嗎?

嚴格的說;不是的,因KDD只包括上班時的工作時間,而個人看板理論上應該是24小時的,也就是還包含其它事項,例如: 家庭生活、個人生活、還有興趣 . . 等。

 

發表迴響

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

WordPress.com 標誌

您的留言將使用 WordPress.com 帳號。 登出 /  變更 )

Google photo

您的留言將使用 Google 帳號。 登出 /  變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 /  變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 /  變更 )

連結到 %s