為看板設定目標

.

【二種做法】

  1. 設定持續改善的依循目標  – 持續改善目標表。
  2. 為使用者故事或Task 設定要達成的目標  – OKR用戶故事卡。

.

以紙本的方式

OKR用戶故事卡(左側) 與 持續改善目標表(右下方)

.

如果你已經在使用看板了,那你對看板的三條約束一定不陌生,它們是劃出價值流、設定WIP及管理你的流程。你也一定知道,它的終極目標是能夠做到持續改善(Kaizen)。但在你實施一陣子之後,一定有過這種疑惑,我們經常改動看板但是到底是改對了還是改錯了呢? 這樣改變WIP的值到底產生了多大的影響,有效嗎?

.

持續改善就是持續去設定目標,在達成目標之前能有效的持續地進行調整。

– 持續改善目標表

.

有明確的目標才能持續改善

當你在做一件有意義的事時,你會設定目標嗎? 如果你沒有設定目標這個習慣的話,又怎麼知道目標是否已經達成了呢? 又方向對了嗎,還是漸行漸遠了?舉個例子: 出外旅遊時,我們經常興高采烈的設定要去的地方,然後走著走著,在進入陌生的巷弄時難免就會心生疑慮,懷疑自己是不是走錯了,這時候;有一個可以用來確定對錯的好方法,便是使用目視法;要能始終看到目標物在哪裡,維持一直能看得到目標,這樣不管是怎麼繞來繞去只要一直能看到目標,而且有持續接近的跡象,就可以安心了。這種作法其實是由於可以確定方向是對的,心理頭自然就不會害怕是否迷路了,旅遊的心情也就自然地平穩了下來。這是持續看到目標確定方向的好處。然後篤信只要朝著這個方向去前進,就一定能到達目標。 

上面的方法可行,但那是在你已經很接近目標物的時候。如果遇到距離較遠無法目視到目標的時候,我們可能就得先行規劃到達某一個特定目標之後再向主要目標前進,採用兩段式的方式去達成目標,這便有計劃的持續改善了,我們先設定好一個目標,在確定到達後,再朝向另一個目標去前進,自然能按計劃越來越接近目標了。 

.

為看板設定目標

看板上少了一個可視化的設定,就是設定一個持續可改善的目標。雖然你可以辯解說目標一直都存在讓流程更快更順暢上頭,但其實它少了視覺化,這一點讓我們不容易聚焦,少了聚焦時便少了經常被關注到的機率,也就自然地就降低了持續改善的機會了。所以我們應該為看板設定一個現在正在改善的目標,然後讓它一直可以被看到。

.

目標就是我們想做的事,關鍵結果是讓我們知道自己達成了沒有。

.

看板上的卡片

將用戶故事設計成包含於OKR關鍵結果相連接的清單上,便利我們在選取 Task 時,確認自己機將做的工作能夠與設定的目標相吻合,以及須要完成到何種程度。當發現有用戶故事找不到與目標對齊的歸宿時,就可以顯現出(可以拿來度量)團隊實際用在開發功能上的時間都花到哪裡去了。解決方法有二一、是把它轉為功能目標,在設定好關鍵結果。(懷疑是目標訂得不好,所以就為目標加上一支腳,待事後回顧時可以做檢討用)。二、便是刪除不做。這是考驗PO如何來目標設定,及顯示出團隊戰力都消耗到哪裡去了的好現象。

.看板上的OKR清單

看板上顯示OKR能關聯到用戶故事的清單(它放置在To do list前)

.

OKR用戶故事卡: 連結目標、關鍵結果與實際描述需求的用戶故事的卡片。

.

結語

在看板上實行OKR依目的可採用二種方法,一種是針對持續改善的目標設定方式,以設定「持續改善目標表」來讓團隊知道整個看板運作正在朝向哪個方向進行改善。另一種方式為創建用戶故事與OKR的關聯清單(稱為;OKR用戶故事卡,如果你只有Task 而沒有用戶故事的話,就叫它OKR工作卡)。

 

對於純粹使用看板方法的團隊,例如維運團隊而言,設定「持續改善目標表」會讓改善看板運行效率成為可以被看得到的成果,團隊容易形成共識進而加強了自組織性。而OKR工作卡則促成我們在做任何事之前先設定目標,由於預設完成後的關鍵結果,這一點可以激勵工程師表現得更好。對於運行Scrum的團隊,幫助就更大了,它可以讓綁定需求(用戶故事)與目標,讓開發需求時的預期目標能夠凸顯出來,更加專注於主要功能而減少去做與目標無關的工作,換句話說就是減少了浪費。

 

聚焦持續激勵

聚焦與持續激勵是成就OKR成效的依據。所以必須一直提醒自己,一直提醒團隊是否偏離了目標的路線。站立會議是看板實作OKR開始時,最重要的檢核時機,透過隨時更新關鍵結果的信心度,可以讓團隊持續聚焦在目標上頭,而透明出來的效果更能持續增強團隊對目標的專注度,因此看板在實行OKR時,確切又正向的站立會議將是一大成功要素,不能忽略。

.

目標管理法

目標管理法概述

.

註: 幾本實行OKR的參考書籍

  1. OKR工作法谷歌领英等顶级公司的高绩效秘籍

         寫得好極了,也有一些獨到的施行方法,值得閱讀。

  1. OKR:源於英特爾和谷歌的目標管理利器

        囉說了些,但如果你想多參考一些建議的話,還是好書。

  1. OKR资料全集

       明道互联网公司的免費佳作。https://www.mingdao.com/home

 

 

廣告

精實軟體開發之步驟二、幫To do list加入狀態: 看板篇

todolist
傳統的待辦工作清單(To do list)

待辦工作清單(To do list)在多工的情形下確實幫不上什麼忙。看起來像一串的表單,即便我們紀錄了工作狀態,當想知道工作事項的狀態時就得一個一個的去查看,很是麻煩! 但;若是我們向旁邊加入第二個欄位或更多欄位,用來描述工作事項的狀態,在視覺上就完全改觀了。

kanban_0
工作事項列表加入流程狀態後就成了看板

 

.

上面的圖示裡,我們為工作清單(To do list)加入了,開始作業的「進行中」In progress欄位,以及作業完畢之後的「完成」Done二個欄位。這樣的改變,使得工作清單一下子變成了描述流程的工作看板。把「完成」圈起來的目的,是想強調在多工作業時完成的意義更重於單工作業。因為多工所帶來的作業轉換除了轉換工作時的消耗、時程壓力,其實最可怕的是缺陷的產生,錯誤是其次因為它容易被看見,但隱藏著的缺陷才是在未來必須付出龐大代價的東西。因此值得在這裡強調Done的定義。

 

將流程據實的對照到工作看板上

上圖只顯示了「待辦 – 開始 – 完成」三個很抽象的流程狀態。當我們想多知道一點目前工作的狀態時,免不了還是需要去翻閱各個工作事項的紀錄,然後再試著跟流程結合起來,才能夠看出整個工作流程的現況。如果要改善這個問題,就必須讓真正的工作流程能夠與工作看板有著一致的流程對照,如此便能夠清楚的看到每個工作項目在工作看板上的流動過程。這種繪製實際工作流程的各種活動的對照行為就稱之為繪製價值流程圖(Value Stream Mapping,它的價值巨大這是無需多說的,它是豐田精益製造Lean Manufacturing的製程控制基礎)。

realflow
將流程據實的對照到工作看板上

 

.

緩衝區的設計

進行中的欄位下方的二個次欄位的部分就是所謂的「緩衝區」的設計,也就是增加「進行中」和「完成」的次欄位,它的目的是讓主欄位的工作狀態更清楚。同時可以顯示哪裡出現了「盈餘時間」。

加入半成品(Work In Progress)限額

為欄位設定WIP限額是看板方法的必要步驟,如果你發現工作板上沒有為WIP設限,那基本上它就不是在實施看板方法(依據看板之父 David J. Anderson所述)。為流程設定同時可以進行的工作數,目的是為了追求最大產出而有效的限制半成品數,他是依據利特爾法則(little’s law)而來。(詳細資訊參考: https://ruddyblog.wordpress.com/2014/10/19)

add_wip
完成半成品限額的設定

 

.

上圖中在檢核(Verify)欄位中我們將WIP設成2,表示這個欄位最多只能同時有2件工作項目在進行中,而他的前一個欄位(進行中欄位)則有3個半成品的額度,這表示當進行中的項目只要遇到粒度較小(較容易完成)的工作項目時,就很容易會產生阻塞的現象。既然知道容易出現阻塞的問題,那為何還要做這樣的設計呢?理由很簡單;因為它可以盡快找到問題。如果你的產品不容許有任何差錯的話,則可以嘗試將檢核欄位的限額改成1,這表示只要有任何工作項目出問題,整個流程就會被強迫停下來,一直到它被解決了為止。

啟動拉動系統

依照重要性排序完待辦事項之後,接著就可以開始由最重要的工作事項來啟動流程了。流程由左往右、由上往下,只要前面的關卡沒有發生阻塞(依據各個欄位設定的限額大小),就可以把它拉進來開始進行工作。這個拉動的行為就稱它為實行拉動系統(Pull System),通常由團隊成員自己主動做拉動(Pull)的工作,而不是被上級所指派(Push)去做某一項工作。這是典型的自主行為,完全符合團隊自主組織的定義,是屬於效能最佳的一種工作方式。

pull system
拉動系統事主動挑選工作事項的行為表現

 

.

阻塞的現象

當欄位前面的關卡到達半成品(WIP)的設限時,流程就被迫停止下來了。我們稱它為阻塞(Blocked)的現象。這個時候,所有的團隊成員都會發覺流程不動了,此時,通常手頭工作已經做完的成員為主動過來幫忙,因為它甚麼事都不能做了,無法拉動新的工作事項進來工作,當然就只能來幫忙了(這是團隊發生共同面對問題的時間,團隊精神在這裡將會得到發酵,主管可以客觀的觀察整個協作的過程,這是得知成員個人個性的好時機)。

blocked
流程阻塞

 

.

沒有產能! 這對流程而言是一大傷害,所有的人瞬間都會勒緊褲帶、戰戰兢兢的過日子,此時盡快找出解決方案才是上策。主管要切記;千萬不要由釐清權責的怪罪或責難工作不力開始。工作流程因為跟大家都息息相關,所以非常容易勾起情緒上的反應,如果是針對個人的話;它容易反映你的工作效能及待人處事的能力。對於團隊而言,就更為有趣了,請參考以下的分析:

【剛剛做完手頭工作的成員】

  1. 會有機會再肯定手頭的工作事項是不是真的、踏實的做完了。

  2. 會思考是不是自己先前工作所造成的,或是評估是否會對自己未來的工作事項有所影響。

  3. 會主動去幫助跟自己最熟悉的夥伴。

【手頭還有工作的成員】

  1. 雖然抽不出時間來幫忙,但會詢問狀態並嘗試提供意見。

  2. 思考是不是自己先前工作所造成的,或是評估是否會對自己目前的工作事項有所影響。

【主管】

  1. 避免直接聽取問題的來源,減少干擾正在奮戰解決問題的工作人員,應該選擇信任成員能夠自行解決問題。

  2. 採取事後檢討的方式,避免直接介入問題,並應該保持樂觀的態度。

  3. 藉著每次危機處理,增強團隊協作的能力。

  4. 認識成員的人格特性,引導他們朝正面發展。

 

更完整的看板漫畫可以參考

精實軟體開發之步驟一、識別浪費

 

 

 

先學 Scrum還是 Kanban?

先學寫程式還是先學測試?

對於初學者或新人而言由測試開始是再好不過的了。

一旦寫程式的功力夠了,製造缺陷的機率自然會下降些,這個時候再來寫程式,才不會害己害人。

原因很簡單;因為缺陷是程式沒寫好所造成的,所以要學寫好程式,先學如何測試別人的程式,先看懂別人的程式,再來嘗試寫好程式,似乎會好一些!

.

先學 Scrum還是 Kanban?

大部份的時候;你可能完全沒有選擇的餘地,這可不是老天能安排的,而是看老闆的安排。

從屬性上來看:

Scrum 容易探討未知,處理複雜專案,拿來開發新東西威力無比。

Kanban 是教我們如何自我檢討,可以迅速消除浪費,而得到好的效能。

如果你是開發團隊,當然是先從Kanban 開始。先檢討好團隊的基本動作,整頓好了再來開始作新的東西,從事開發的動作,自然少浪費。這是精實Lean 的好處。

(有太多開發團隊,只曉得一意往前衝刺,忽略了自己在開發上的浪費,這會造成很難走得久遠,尤其是Startup的團隊尤其如是。)

如果你是維護團隊,當然是先從Kanban 開始。視覺化是最大的亮點,團隊可以看見工作上的維護流程是一件相當有價值的事,針對個人亦是如此,人們常常因為養成習慣了,就一直持續做同樣的事情,很少會有機會回過頭來檢討,哪裡做得浪費了應該改進。看板方法的第一步: 視覺化。正是團隊可以拿來持續改進的基礎。這一點對維護工做更顯得珍貴。

如果你是測試團隊,當然是先從Kanban 開始。看的見以後才可以減少猜測的比例。測試團隊在擬定測試計畫之前,一定要對待測的產品或程式有足夠的了解,才可能開出實用的測試案例,不至於浪費大量的測試資源。或做了過多的重複性測試。

.

(你可能覺得奇怪,為什麼都是 Kanban Method 先行呢? 其實原因很簡單,因為它"單純“,不是簡單喔! 它沒有想像上的簡單,因為它可以演進得很有深度,但是它的目的很單純,就是追求效能。不像 Scrum 的目的,是要來應付複雜的專案開作業,基本的方向就完全不一樣的)

.

將看板方法融入Scrum的開發過程才是上策

看板方法是一種流程控制,他不是一種具有完備基礎的方法學,雖然他的潛在發展相當可觀,但目前他仍只是一種提供我們產出高效能的流程控制法而已。他缺少需求描述、沒有完備的會議規畫、少了團隊職責分配,少了很多很多軟體開發上該有的措施,這一點讓他看起來十分空泛,但就是這個特性也讓他十分適合融入其它開法方法中,尤其是 Scrum。

看板方法之父 David J. Anderson 是在Microsoft 公司推行敏捷開發法 Scrum 的時候發明看板方法的。他原本的目的只是要求能夠在最少阻力之下順利在組職中推行敏捷式的開發法而已。卻由於他熟悉限制理論的運作而開創了看板方法Kanban Method。做出了對敏捷開發的精實Lean 一支的重大貢獻。也就是這樣的典故,讓看板方法Kanban Method可以十分容易的融入到Scrum的開發過程。

著名的《 Essential Scrum 》 的作者Kenneth S. Rubin(它是2013年Amazon 敏捷理論最暢銷書),書中就大量的採用 WIP(Work-In-Process)的觀念,實際的運用在工作看板上面。讓Scrum在開發流程上減少了許多的浪費現象。

 .

※ 看板方法先行

因為它可以減少組職在推行敏捷上的阻力,它能讓工程師以最好的節奏持續進行開發工作。又能將精實觀念帶入團隊運作。

※ 融入Scrum的開發過程

因為看板方法的流程控制方式是用來提升Scrum運行迭代開發時的效能。讓 Scrum 能真正用來克服複雜的軟體程式開發過程。

.

Scrum 的目的在解決複雜的軟體開發作業

許多人誤把Scrum 當成加速軟體開發的銀子彈。這是錯的! 他的目的不在加速開發(加速開發工作是開發工具的廣告詞),它的目的是在解決複雜的軟體開發作業,讓它提高成功率。在協助團隊能夠提供給客戶真正要的產品,且讓他在市場上具有實際的競爭力。這一點也正好是看板方法所缺少的。

開發團隊千萬別因為實施了看板方法而誤以為需要把 Scrum 拋棄了,這是一種錯誤的想法,讓他們相輔相成才能有更大的效益。下一回就來談"運用看板方法的十個不應該放棄 Scrum的理由"。

.

測試難還是寫程式難

讓我們回到一開始的主題,到底是測試難還是寫程式難? 其實正確的說法應該是寫出正確無缺陷的程式難! 實際上程式設計人員在寫出程式之後,也必須透過測試,才知道他是否能正確運行。因此"寫跟測"實質上是一體的二面,一樣重要。

至於Scrum 與 Kanban Method 之間,則都是通往敏捷開發的路徑。已經在使用 Scrum 作開發工作的人士,學習 Kanban Method 可以讓他們進入精實的領域,有所依據的持續追求更好的效能。先學會Kanban Method 再跨足 Scrum 的人呢? 則可以看到敏捷開發在處理複雜問題上的具體方法,真正懂得去追求效能之外的正確性與方向。

先學 Scrum還是 Kanban? 二者之間並沒有衝突存在,端看你現在最需要的是那一樣,那一樣就先來吧!

用來提升個人效能的「個人看板系統」– Personal Kanban

images9CTXEYN5
用來提升工作效能的個人看板

(我在 Techdays2014 課程的資料: http://1drv.ms/1xyToMp )

用來提升個人效能的「個人看板系統」Personal Kanban ,創始人 Jim Benson

  • 一個人需要執行敏捷開發 Scrum ?

這是一個經常被問到的問題,

請問: 工程師一個人要如何來執行敏捷開發Scrum呢? 有必要嗎?

過去我的答覆都是這樣的: 由於Scrum對角色的要求,因此一個人沒有必要執行Scrum,只要符合敏捷開發的精神就可以了。但是在經年累月的scrum課程中這個問題始終沒有間斷過,確實有很多工程師屬於長時間、一個人單打獨鬥的環境下進行開發作業,但又渴望能有提升效能的方法,那要怎麼辦呢? 現在增加一個答案可以回答了,請嘗試「個人看板系統Personal Kanban

.

「 個人看板起始於先弄清楚自己現在的狀態,然後逐漸的邁向對未來的願景。」

.

(上面的問題在我的書裡頭說得較詳細。書裏頭用「類專案」來談一個人如何敏捷的做專案。「類文件」:一個人開發需要些甚麼文件。書名:" 精實開發與看板方法)

.

用來提升個人效能的個人看板系統

個人看板是用來增進個人理解自己的工作和進一步透過分析來改善流程使得更有效工作的方法。它透過視覺化目前手頭上的工作,然後運用WIP(work in process: 半成品,對軟體工作者而言,指的是還在coding中的程式 )的管制來調整個人對工作進行的流程管理,進而能夠經由有效的管理工作流程來提升工作效能。真是很有效率,也很有趣! 特別是採用微軟系列開發工具的工程師,若能夠透過 Visual Studio 所提供的看板機制,實際管理一下自己的工作與生活瑣事,讓撰寫程式的工具與個人的生活事物相結合也是一種提升個人工作效能的好方法。(看板方法之父 David J Anderson 實際上是出身自微軟, Kanban Method 也是首先運用於微軟的專案上。)當然如果你已經採用了個人看板系統;透過自身的實行,對於整個開發團隊一起實施Kanban Method時,能夠事半功倍是可以預見的。 要深入解釋這種運作,首先要有一種概念:「多工造成效能不佳」談起。(請試著在網路上搜尋: Multitasking is evil 後面在加上 “哈佛” 就有參考文獻了,或是參考這段影片 https://www.youtube.com/watch?v=US9Sff8BFx0 )就很容易了解是怎麼回事了。

多工反而降低了工作效能 — Multitasking is evil

人們總是不自覺的同時處理多件事情。對電腦而言,它能很有效的做到多工(multitask)的動作,而且相當有效率。但人腦卻很難這麼做,我們太容易分心了,對於外界所傳達的訊息我們幾乎來者不拒,是這些干擾的訊息造成我們很容易就開啟了另一個工作而對原來的工作降低了該有的專注力,這一點;對程式設計言;這當然是 BUG的好來源,對測試而言;萬惡則莫過於邏輯思維受到中斷所埋下的缺陷(這是種比較難被測試出來的疏失)。所以針對專注力不夠的朋友,我想推薦Personal Kanban,透過運用它來管理你的工作,運用工具來有效管理手頭上的工作讓生活更好過些。

實行 Personal Kanban 三步驟

  1. 視覺化: 把你手頭的工作用流程畫出來。(Gerry Kirk 在youtube 上的幾篇個人看板運用說明,值得一看!  畫出你的第一個看板)。
  2. 限制WIP(Work In Progress進行中的工作)。(為 Dave Lowe 所製作的一段默片,他運用了Drive through窗口點餐作範例,再清楚不過的說明了WIP的功用,以及我們該注意甚麼。) 試著設定WIP值,請參考這裡WIP 0
  3. 管理工作流(透過反省、分析最佳化你的工作,這是最有價值的一段)。 依稀記得在第一次閱讀 David J. Anderson 所寫的「看板方法」時,就發現給 Comment的許多人中,一致認為看板不只是如此而已,它潛在的可運用空間很大。我想指的就是這裡。(可以參考Gerry Kirk 在youtube 上的其他說明)

(Personal Kanban 的創始人Jim Benson 在書上只列了前二個步驟,並且認為它可以適用在家庭、學校… 任何有人的地方,它能讓人們能更有效的工作(我完全讚成!)。但在這裡我還是加了第三條執行原則,也就是善加管理你的流程。所以這裡就多列了原始Kanban的第三項步驟! )

※ 先介紹 David J. Anderson 所寫的「看板方法」 一書: 如果你想採用 Kanban Method 的話,這是必讀的經典參考書籍。但請務必去看更新資料 http://www.djaa.com/ 查看他最新的定義,這是一個用功的傢伙,隨著時事的改變他也不斷在精進自己所創的理論。(Kanban Method 的開發原則,目前已經稱為6個 practices了)

※ Personal Kanban「個人看板」 Jim Benson 所著。很有參考價值。

kanban
簡體中文版,看板方法:科技企业渐进变革成功之道
personal kanban
原文版

已經沉浸在 Kanban的信息分配多時了,真是有太多麟麟角角,很多只能意會難以言傳的東西,希望找到更好的說詞。想想那些教授看板理論的老師真是難為了。以下是看板方法的六個核心實務(6 practices),前三個常常被稱為3大準則 3 Principles。

6 core practices for kanban

個人看板讓你掌握時間《做自己

個人看板不只是拿來提升個人工作效能, 它更能拿來管理自己生活與工作流程,讓你知道如何掌握時間《做自己》。如何做呢? 靠分析瓶頸來達成改進的需求。

分析三步驟:
(1) 注意自己開始和完成工作的速率。
(2) 每個工作是否按步就班在自己能夠容忍範圍之內完成。
(3) 超過 WIP 限制的情況嚴重嗎? 應該採用寬鬆的方法(加大WIP值),還是緊縮的方法,讓現象能夠改善呢?

(Queue 跟 Buffer 的運用,有一點複雜找機會再來詳細說明)

當然;日子要過得快樂才對,但為了在龐大的工作壓力下還能笑得出來,來試試 Personal Kanban吧!

kanban tools 0

一開始;我覺得越簡單越好,就直接用 OneNote 自己畫看板(如圖中最左邊的),後來因為經常坐在床上更新工作事項(當然用iPad了,也就換成 trello了),最近已經換成 KanbanFlow (非常好用!),因為它多了番茄鐘,可以提醒我專注在工作上的時間。建議大家不遑多試試看,用習慣了就是好的。

為何不直接使用 Visual Studio呢?

答案是當然可以! 不過我會建議你用角色的方式來運用 Visual Studio,因為它比較適合團隊運作的方式,你若能將在家裡的角色、在公司的角色或區分成更多角色,分開來運用,則更能跳脫那種公私不分的枷鎖(這是良心的建議)。

附上一張個人使用看板方法的參考圖示。 (想試試看嗎? 參考: 運用個人看板做時間管理)

.

personal kanban

.

結論

你想增進自己的工作效能嗎?你想讓自己活得更愉快嗎?首先;你要先弄清楚此時此刻你要的是什麼?現在什麼事對你是最重要的,你最在乎的是什麼?然後把每天所作的工作,花費多少時間去做,記錄下來。再從記錄上去分析你是否把時間都用在自己最想要的工作上了,如果不是的話,就設法增加它的比重、調高它的優先順序,然後再執行ㄧ陣子看看,持續改善它,讓自己為自己所想要的東西而活。

請參考: 一個人如何施行敏捷 (來自單核工作法的聯想)

.