看得見 : 看板讓你看得見

  • Q&A : 實行看板方法與 PMP 或是 CMMI 有衝突呢?
  • 回答 :  當然不會衝突。

看板方法是精實開發的一員,屬於「視原則重於開發方法的一種漸進改革方式」。他的目的在讓工作流程被視覺化,讓我們的決策更接近事實、更容易作為改善的依據、更容易管理及更有效率。

.

眼見為憑  “To see is to believe"

形容不要輕信傳聞,看到的才是事實。聽來的傳聞是靠不住的,親眼看到才算是真實的。所謂;親眼看見的比聽說的要真實可靠。「看板方法」也就是這麼一回事,它要求我們要畫出價值流程圖來,也就是把開發過程呈現出來讓我們看見浪費所在,並依據他來加以改善(而不是用臆測或聯想的)。而 DevOps 也正是要依靠這麼一回事!讓你依據看見了的現象進行調整與持續改善。

.

投影片2
旅遊是一種透過看得見,來增長見聞的方法

.

看見流程、進度、問題及瓶頸

我們都愛旅遊,因為旅遊可以拓展人的視野,而視野寬廣的人容易讓人喜愛。自己也可以因為行萬里路而增長了知識,對人對事也似乎能夠看得更深更遠一些,好處多多。但這裡我們不談旅遊,我們想談的是「看得見」。

很多事情都需要你看見了,才會意識到也才會知道事情的原委,才曉得接下該怎麼來處理它。這樣的看得見正是看板所能帶來的好處。看板方法的第一條原則,「視覺化」。正是要求透過視覺化你目前的工作流程(產出價值流程圖,Value stream mapping)。讓你看得見工作流程的狀態、看得見進度、看得到問題所在、看到事情的瓶頸。然後才能正確地來進行改善的工作。

.

0 看得見
看得見: 流程、進度、問題及瓶頸

.

可視化的價值 –透明化

看板上流動的工作類別,決定了我們想看到的工作流種類。以開發作業為例,我們用"使用者故事"來描述需求,團隊並針對要如何達成這個需求而將它拆解細分成可以實作的Tasks,並針對各個Task作需要開發時間的估算,接著在卡片上壓上工時以便利追蹤,並在拉入"In Progress"時寫下開始時間,讓他明確地在看板上以貼紙的方式呈現出來,讓大家都能看得見進度及狀態。這個動作讓專案的進度完全落實在看板上頭,就專案而言就稱之為「透明化」。它是實行敏捷開發的基礎,也是主管對敏捷開發最愛的地方,就是能清楚的看得見專案開發的進度。

.

00 user story

.

卡片需要追蹤、更新及follow所衍生出來的問題

工程師容易患見樹不見林的問題。因為工程師通常是把焦點放在工作上,而忽略了使用者故事所要達成的目標。這是Scrum 團隊最常患的迷失,也就是把Task當成目標,這便是「非技術債」最常誕生的原因之一。它往往不是使用者故事寫得不好所造成的,而是工程師經常用 Task 來取代開發作業的目的所造成的結果。此時,Scrum Master是最可以改善這類迷失的當然人選。我們可以在站立會議時適時的提醒工程師在更新工作時,再次正視這些工作的目標,簡單的討論一下距離達成目標的距離,聽聽團隊的意見,不但可以避免忽略了真正的標的,而且可以讓團隊更專注於達成目標的使命感,是一舉數得的動作。

卡片上充足的訊息能讓觀看的人獲得更多的資訊,但適度凸顯重要的訊息(運用顏色、特殊標籤等方式)會遠大於一大堆相同分量的訊息要有價值的多了。也可以便利團隊就事論事的進行問題討論。

.

0 看得見卡片
原本十分抽象而簡單的卡片,在看板上是需要被賦予了各種屬性及訊息。

.

可視化價值流動

在工作步驟與步驟之間,代表的是一個工作的輸出(成果),以及它流動到另一個工作時轉變成輸入的過程,這個轉變的過程正是預告將要製造出的價值所在。工程師則是負責製造達成這個目標的人。團隊依據卡片上對工時的估算,小的Task我們可以很快的看到成果,較大的工作則可以持續在卡片上更新它的進度,讓大家都清楚目前距離達成目標的距離,然後以一個團隊的形式來共通承擔這個任務的成果。

.

可視化問題及阻礙因素

看得見風險是看板的一大功能。由現象的解讀我們便容易推論出專案接下來可能發生的現象,美其名或許可以稱之為預測,但實際上只是一種後果的猜測而已。團隊可以依據看板上的徵兆,共同討論、共同決定對策(這是團隊表現出自我管理能力的地方),這一點可以提升團隊對任務負責的心態,也能夠具體的提升團隊自我管理的能力,相對於處理的問題或瓶頸而言,是更有價值的一環。

可視化排隊queue 及瓶頸

看到問題便可以針對問題進行改善,這是看板最能發揮精實精神的地方,也就是運用「看見浪費」,來實踐精實第一大原則,也就如何「消除浪費」的具體方法。我一直以為看板之所以稱為方法(Kanban Method)的地方便在這裡,它是一種消除浪費的方法。

產生Queue的地方,便是出現盈餘時間的地方,也是多出WIP(Work In Progress)限額的地方,就是我們可以加以改善的地方。在運行看板的時候,在這裡的半成品(WIP)已經從原本的一種猜測,轉變成是一種現象了。依據這個現象,我們便能夠對看見到這樣的現象,針對它來進行改善的工作。

.

看板方法是一種消除浪費的方法。

.

看見之後,要如何來改善呢?  看板方法的第二條原則:設定WIP限額就是要完成這件事。我們下回再來談吧!

精實原則: 消除浪費 Eliminate waste

程式開發人員最大的浪費,便是在開發作業時,製造一大堆bug然後再費盡心力把它解決掉。(這是極大的浪費,有趣的是programmer 在解決完這些bug之後還能獲得相當的成就感,Bug的貢獻之一。)  — 歸類於撰寫程式時期的浪費

另一大浪費便是程式設計師,老是在做一堆沒有人會去使用的功能。(※例如: Word 文書處理器,大概只有百分之20的功能我們常常會用到,百分之19的功能有時會用到,卻有超過百分之45的功能我們一輩子也不會用到,真是一大浪費) — 歸類於需求分析時期的浪費

定義浪費: 若是對客戶或產品沒有提升任何價值的行為,基本上就是一種浪費!

以精實軟體開發對浪費的嚴苛看法,現在的應用程式生命周期(Application Life Cycle Managemnet)應該只有需求分析與撰寫程式屬於不浪費的過程。但那些個不能且無法省略的步驟,難道他們就不重要嗎(例如: 測試.)? 這些看起來是浪費的動作,實質上卻是為了完成增加產品價值所必需的工作。這部分可能是基於製造業的豐田管理系統與軟體工作也就是基於知識工作對浪費在定義上最大的差異。這樣講好像有些抽象,還不如舉例來說明: 例如敏捷開發團隊最喜歡的每日站立會議,大家一定都覺得他是增值活動,但是若以客戶的觀點來看,可能就不覺得他對產品有甚麼實質的增值,客戶可能會覺得這個開會的時間還不如拿來寫程式,可以實質的增加產能。但很明顯的這是一種成本,一種人與人互動協調合作的成本,少了溝通可能開發上就會出問題,而這種溝通協調的成本會隨著開發團隊的人數增加而變得十分可觀(這正是Scrum建議開發團隊最好不要超過 10個人的原因)。從這個例子來看,能夠識別甚麼是浪費是減少浪費的第一要素。

如何識別浪費?

豐田生產系統的策劃人之一的 新鄉重夫 Shigeo Shingo 他首創製造業的7種浪費類型,而 Mary & Tom Poppendieck 則將它轉換成軟體的七種浪費類型,對照如下:

-》 乍看之下,你可能覺得這些原則感覺上像口號一樣,真的有用嗎? 讓我告訴你,當你在繪製看板時(也就是將你的工作流程放到看板上面成為一個或多個垂直欄位時),你所依據的便是對這幾條原則的了解程度。 (如果你覺得很陌生的話,下次改變看板外觀時,一邊看著這些條列一邊思索是否需要改善哪裡?改的原因是甚麼? 想達成哪一條原則,多練習幾次就熟了。記得一次只改善一個地方就好,這樣比較容易看出是哪個異動所造成的結果,這一點跟改BUG一樣的做法,一次同時修改好幾個地方,就搞不清楚誰才是元兇了)

這七種浪費分別是:

製造業七種浪費

 軟體業七種浪費

1 庫存  半成品、部分完成的工作,Partially Done Work
2 額外過程  額外過程,Extra Processes
3 生產過剩  多餘功能,Extra Features
4 運輸  任務調換,Task Switching
5 等待  等待,Waiting
6 移動  移動,Motion
7 缺陷  缺陷,Defects

判別是否浪費十分重要,是你開始不浪費的基礎。雖然看起來冗長,請務必讀完。每一項目最後括號內的說明是相對於看板方法的運用手法。譬如你不知道該如何來新增看板的垂直欄位或調整WIP值的話,請依據以下的幾條原則做參考依據,這裡只做最簡單的說明)

部分完成的工作

英文用Work-In_process 來描述,我喜歡用半成品這個字眼,雖然在製品看起來比較貼切一些,但我偏好採用半成品。部分完成的工作:它是一種賭博,一個隨時可能會失效的功能,因為它有可能還沒上場就被換掉了(原因是因為你先做了)。另外是太早做可靠度就較差些,雖然你可能用單元測試來保證它的輸出入值,但在還沒有經過整合之前,沒有人可以保證它是好的。所以以投資報酬率而言,它是最不理想的半成品。在團隊開發的流程中,嘗試把半成品控制在最小的範圍內是最理想的狀態。也是減少浪費的好方法。(對看板方法而言,可以用來限制WIP值,產生盈餘時間或看到瓶頸所在。這一點可以透過累積流程圖來進行觀察)

額外過程

文書工作就是一種最有爭議的額外過程,它會消耗資源、降低反應速度、還會隱藏風險。但相對的它可以讓客戶簽字表態,或是取得變更許可或是便於追蹤。而且幾乎所有的軟體交接都需要文件,但是基本上它是不會產生增值的,所以也是一種浪費。但若是基於需求上的工作則可以把它視為是一種增值了。請注意: 好文件應該保持簡潔、具有概念性、便於做交接。(盈餘時間是最適合用來進行文件的撰寫作業的)

「多餘特性」

有一句古老的名言:當你新增功能時你也同時新增了BUG。意思是請盡量減少不必要的功能。額外入的功能,一般的程式設計師總以為這是一個不錯的想法,為了未雨綢繆我就自作主張把他加進來了。老實告訴你這是最不好的作法,記得;只有在有必要的時候才新增功能。任何一段不需要的程式碼都是一種浪費。千萬要懂得抵抗自以為能夠有先知卓見這種未雨綢繆能力的誘惑。(額外的程式碼將會佔據半成品WIP的數量限制,透過累積流程圖可很清楚的界定它的影響)

「任務調換」

多工是一種浪費(Multitasking is evil)。給員工同時間分配多種工作是專案產生浪費的一個根源。軟體開發人員每次在轉換工作時都會浪費大量的調換時間,因為它必須調整思路,以便投入新的任務流程。當然;若是你同時參與多個開發團隊的話,自然會造成更多的停頓。從而引起更多的任務調換而浪費更多的時間。(限制WIP值就是為了減少這種浪費)

「等待」

在團隊進行協同開發時最浪費的可能就是等待了。有時候等待上級或協力廠商的回音,一種必然會存在、無法改變的過程,就是一種浪費(例如: 等待 email 的回函或通知)。這種必然的等待可以在看板上增加一個垂直欄位 Cloumnsˋ別來處理它,如此可以讓我們更明確的知道現在的狀態在哪裡?

移動

當開發人員遭遇無法立刻處理的問題,需要他人協助時,他需要移動多少距離才能找到問題的答案。是否立即就能得到解答,還是需要繼續移動到其他房間詢問其他人的協助呢?這就是一種浪費。當然人不是唯一會移動的,各類文件也會移動,尤其是測試文件的流動程序,也可能造成龐大的浪費。(這種事物型的開銷,在看板上面能夠表現的越明顯就越容易被考慮進去解決方案)

缺陷

 缺陷所造成的影響,取決於它被發現的時間和它的大小。越早找到缺陷越好,能夠盡早處理掉的問題絕對比在客戶端才被發現好上許多。諸如測試開發法 TDD 則是希望能盡早找到缺陷並即刻修復的手段,類似的方法大部分也都有它的價值。所以頻繁的整合及發布是一種容易受客戶肯定的行為。也是避免重大浪費的必要小浪費。

看到浪費

浪費是一種只要看見了就容易被改善的東西。透過識別那些行為是浪費? 它們是如何造成浪費?可以讓我們更容易看到真正的問題所在,也就是「看到浪費」。看板能讓問題成為大家都知道、都看得見的事,如此便可以透過改善的(行為)方式來避免不必要的浪費。這是精實軟體開發法的第一個原則。不浪費! 本來就很合理,但在運用上,由於軟體開發有別於製造業,因此受爭議之處特別多,宜視環境時時進行調整。