over 2 years ago

雖然看過 Ruddy 老師的《精實開發與看板方法》,也整理了不少重點,但總覺得少了點什麼?碰巧趨勢科技的柯大哥在資策會有開課,加上又有公司全額補助,就決定跑去上課了,兩天的課程收穫很多,除了從看板遊戲體會到不少東西外,一些觀念也更加清楚,也發現到自己有西東西並沒有很清楚,只是上完課到實際回到團隊中使用,還是有很多小東西要注意。

什麼是看板方法?

首先看板方法不是軟體開發方法,也不是框架,原先是豐田為了達到零庫存,用來優化生產線使其能用最少的資源,在顧客下訂單後開始生產,以最快的速度交付給客戶,一種優化生產線的方法 (用抽象的角度來看,像是從生產線的末端,向前拉動生產線的生產,以減少庫存,不是從前端不斷地生產來推動下游,因此是一種拉動系統),後來衍生到軟體開發上,但本質還是一樣,看板方法是優化流程的方法,把看板方法與其他開發方法搞混了,就會常常撞牆鑽不出來。

精實精神

看板方法受到蠻多精實軟體開發的精神影響,所以在了解看板前先知道精神軟體開發的核心精神(或稱原則):

  • 消除浪費,軟體開發常見的浪費:
    • 半成品 (work in progress)
    • 額外過程,像是寫非必要的文件
    • 多餘功能,當時間緊迫時,能被捨棄或切割掉的通常就是多餘的 (假設產品負責人不是亂捨棄與切割)
    • 任務轉換,基本上就是避免 context switch 過多
    • 等待,這應該沒什麼好說的
    • 缺陷,如果沒 bug 就不用修,多好...現實中不可能啊~
  • 增強學習,軟體開發本身就是一種學習的過程
  • 盡量延遲決策,到資訊充足或是不做決策的成本要比做決策的成本高時才做決策
  • 盡快交付,我想應該沒有客戶喜歡等待...
  • 授權團隊,這點很有趣,幾乎所有的書都說,能自我管理的團隊會是最有效率的團隊,但在台灣通常還是有無形的手在後面...
  • 著眼整體,局部最佳化不等於整體最佳化,甚至會傷害整體最佳化

原則與實務

看板方法本身還是有些核心原則:

  • 從既有的流程開始,因為看板本身不是開發方法,也不是框架,所以要從團隊本身既有的流程開始優化
  • 同意持續增量漸進的變化,越是大幅度的變化,越容易引起團隊反彈,而且最好從痛點改起
  • 尊重當前的流程、角色、職責和頭銜,基本上優化不是搞革命,就這麼單純
  • 鼓勵各層級的領導行為,如果要層層上報才能做決定,那優化根本不會成功

上述是原則,但實際上執行可透過六個實務來優化流程:

  • 視覺化,將流程視覺化,協助找出問題在哪裡
  • 限制半成品 (WIP) 數量,凸顯瓶頸,並促使團隊成員解決瓶頸
  • 管理流程,基本上就是優化流程
  • 制定明確方針,越是簡單的方針,團隊成員越容易遵守
  • 落實回饋,鼓勵團隊提出建議,並讓建議成真
  • 協同改進,實驗性演進,分析問題時善用數據

前三項完成就有看板的雛型,後三項是強化優化的效果。

精實與 Agile 的差別

精實開發的精神與 Agile 在蠻多地方其實有點接近,事實上也不相違背,但個人覺得最主要的不同是,Agile 重在快速因應變化的能力,所以像 Scrum,以 sprint 衝刺的方式,讓 PO 與客戶在每個 sprint 結束後下個 sprint 開始前都有調整產品方向 (透過調整 story 的優先度),避免過度設計,透過每個 sprint 少量的時間進行 refinement,讓設計因變化所受到的衝擊減到最小。而精實重在持續快速交付價值,所以看板方法強調在優化流程,排除浪費,消除瓶頸,都是為了能快速交付。但並不是說 Agile 就不是快速交付,而是在因應改變與快速交付中取得平衡,所以 Scrum 也是有自省會議,讓團隊能更加進步。

設計看板

要使用看板方法,要先進行看板的設計,雖然說看板方法四個原則的第一則:從既有的流程開始,但既有的流程卻有很多解釋的空間,例如,可能已經有 Scrum 經驗的團隊,很直覺地就以 scrum board 的 planned、in progress、done 作為既有流程,若以 task 為工作項目的單位來看,這當然沒問題,但一個 task 進到 done 時,能為產品帶來什麼價值?當然有價值,但若整體的 story 沒有完成,就無法出貨,就是一種浪費。因此,設計看板時,要以系統性的角度 (著重整體) 去想:(1) 範圍、(2) 工作項目的顆粒度、(3) 狀態。但重點是,要與團隊取得共識

範圍

範圍決定看板的輸入與輸出。就軟體開發來說,最簡單的是需求作為輸入,實際可動的產品做為輸出。說是這麼簡單沒錯,但通常在考慮範圍時,會多考慮一件事:團隊是否能掌控。舉例來說,最近很紅的 DevOps,從開發、測試到部署以及營運,一條龍式 (最近這個詞好像變成貶意了) 整合在一起,那是不是能在設計看板時,就把部署放進去呢?那要看團隊是否在測試完成後,有權利決定立即部署,若可以,就適合放進去,若部屬需要層層的管理,或是有其他的流程決定,那就建議將部署另外獨立一個看板,不然,一堆工作項目放在 ready to deploy 的狀態也沒什麼意義。

同樣的,在考慮輸入時,也要考慮到是否能控制,或說得更清楚點,是需求的明確性有多高,一個客戶的 idea 在沒有進行任何討論或分析就放進來,那看板上在開發之前可能就要放一個分析的狀態,讓團隊有機會去討論與分析,但討論完若太大,可能又要切成若干個工作項目,此時,原始 idea 這個工作項目的角色就有點尷尬,要從看板上移除呢?還是保留呢?因此,一般建議是不適合放概念層級的工作項目到真正開發的看板中,也許可以有另一個看板用來進行分析與討論。

狀態

工作項目的顆粒度與狀態會彼此相依,例如剛剛所提的,若一個 story 依前端、後端與測試分拆成不同的 task,那 planned、in progress 和 done也許就可以當作狀態,但不見得能看出瓶頸所在,這也是為什麼上課時,柯大哥問大家一句話:你想從流程中看出什麼問題?

問題因團隊而異,有可能是前端與後端的資源不匹配,也可能是開發與測試資源的不匹配,也可能是分析與開發的資源不匹配,之所以都用資源不匹配稱為問題,是因為大多數團隊成員還是有各自的專長,即便是 T 型人才,也還是有特別精的部分與較不熟的部分,因此一個工作項目不太會是一個人從頭做到完 (假設是工作項目不是依職能切割),就會有交接的現象發生,當資源不匹配時,就不太可能很順地,一個人做完,馬上下一個人就接著做。

流程上的每個節點都需要消耗資源,沒有資源就只好等待,有資源完成後才會進到下個階段,因此看板方法想做的是用視覺化的方式去找出資源不匹配的地方,也就是瓶頸,然後才能解決問題,但解決問題不是靠看板方法,而是去調整流程、資源、開發方法,看板方法只是找出瓶頸,透過不斷地找出瓶頸,然後進行改變來優化流程。所以,在每個可能需要等待的狀態欄通常會建議再切成兩個子欄:進行中與完成 (作為緩衝)。好處是可以看到有哪些工作項目是處於『等待』的狀態,等待是我們試著要消除的浪費,若不凸顯出來,團隊就不會知道等待的狀況有多嚴重。

如果團隊的問題是開發與測試資源的不匹配,那可能較合適的狀態會是將『測試』這個狀態獨立出來,讓開發與測試在流程尚能被凸顯出來,相對地工作項目就不太合適是以前端、後端與測試的方式切割,而是一個可操作的項目,當前端與後端在開發時,工作項目進到『開發』的狀態,當開發完成後進到『測試』的狀態,因此可能的看板狀態會像下圖(但團隊可自行調整):

另外,由於累積流程圖 (CFD) 能協助觀察流程的順暢度,合適的狀態也是讓 CFD 能顯示出更有用的資訊的一種方式。

工作項目的顆粒度

看板方法沒有限定工作項目的大小形式,所以可以沿用既有的工作項目,例如 ticket、story 和 task 都是可以的,但剛有提到工作項目的顆粒度和狀態的切法有關聯,其實也會跟流程跑得順不順會有關聯,工作項目大小不一,設定 WIP 限制有時會出現產能下降或是多出盈餘時間,理論上工作項目的顆粒度相近,流程就會跑得越流暢,但不可避免,不可能永遠都可以把工作項目切得很相近,所以 WIP 限制是一個實驗值,要隨著執行成果調整。

上完課後,我個人比較喜歡的工作項目形式是 story,在流程每個狀態之間移動的單位也是 story,但實際執行時還是會切成更細的 task,但 task 怎麼辦?就變成 story 卡片上的 check list,check list 也分狀態,例如設計狀態的 task、開發狀態的 task、及測試狀態的 task,每個狀態下的 task 都滿足了該狀態定義 DoD (等等會提到)才能稱作完成,等到該階段的所有 task 都完成了,才會將 story 移到下個狀態,所以一張 story 卡片看起來可能像這樣:

Definition of Done

其實還真的蠻多人搞混 definition of done (DoD) 和 acceptance criteria 的,至少上課時就有不少人搞混 (不含我),簡單說,DoD 適用在所有工作項目上,可以根據狀態有不同的項目,也就是滿足了規定的 DoD 才能移到下個狀態,而 acceptance criteria 是針對特定工作項目所制定的,更簡單的說法是這個工作項目的規格,通過 acceptance criteria 才能跟客戶收錢。

會提到 DoD,是因為若看板空間夠的話,是可以將 DoD 直接條列在每個狀態的下方,例如,在分析與設計的狀態下可能的 DoD:

  • UI 流程圖已經完成並和 PO 或客戶代表確認過
  • 開發與測試的 tasks 已經切割完成

開發狀態下方可能的 DoD:

  • 都有單元測試,model 的 class/method coverage 到 100%
  • 程式碼至少由一個同儕 code review 過
  • 程式碼已 commit 到版控系統

而測試狀態的下方可能的 DoD:

  • 自動化測試腳本至少包含正常流程
  • 無法自動化測試的部分都有手動執行一次以上

當然,隨著團隊成熟,DoD 是可以一直增加的。最後,加上 DoD 的看板會像這樣:

急件

能插入急件,應該是許多團隊或管理層喜歡採用看板方法的一個原因,但要先說一下,雖然原則上 scrum 建議盡量不要在 sprint 進行中插件或調整 user story,但若因為市場因素 (例如,目前進行中的 story 已經不再需要) 或其他緊急因素 (營運中的服務發生問題),還是能將既有的 sprint baclog 做調整,注意,是做調整,不是僅僅把急件插入就好,sprint 週期就是固定這麼長,插件會排擠原有 story 的資源,所以就是用 story 換插件,插進急件就要把 story 移除 sprint backlog,不過有時候比較討厭的是,有些 story 已經進行到一半,要移除去就很討厭了,這即使是 scrum 加上 kanban 一起使用也是一樣的。

不論既有流程不是像 scrum 這種有固定時間周期的,在看板方法中讓將急件有獨立的渠道,而渠道上每個狀態的 WIP 限制都為 1,通常會避免設定很大,避免將所有的工作項目都設為急件,而濫用急件渠道。一但有急件,團隊就必須將該工作項目就當成急件,就像課堂中玩的看板遊戲中,講師偷偷提醒急件的定義,但有些組分配給該工作項目的資源甚至比普通件還少,有一組還因為有急件無法在指定時間內完成被扣 (遊戲中虛擬的) 錢,那就失去急件的意義了。

通常團隊要同時負責開發與營運的話,急件是需要的,因此,看板方法透過視覺化的方式,凸顯急件在每個階段是否都能順暢地被處理。加上急件後的看板會像這樣:

WIP 限制的設定

看板方法規定的東西很少,六個實務中,只有頭兩個是真正明確的要求,第三項則是根據問題去管理流程,沒有特定的方法,第一個視覺化流程,通常不太會遭遇到團隊的抗拒,但第二個設定 WIP 限制就不見得了,特別是『限制』這兩個字會讓人聯想到會不會影響到我平常的工作模式?但看板方法很明確地說,不能不設定 WIP 限制,設定 WIP 限制有幾個目的:

凸顯瓶頸

前面提到,切割 task 常會以職能切割,這無可厚非,即使是一個工作項目用多個 check list 項目也是同樣的概念,只是當以 task 做為狀態搬移的單位時,常會出現一種可能:局部優化,什麼意思呢?假設測試資源比開發資源要少,那開發人員在開發完某個 story 中與他職能相符的 task 後,很直覺地就會將下個 story 送進開發中的狀態,然後繼續開發與本人職能相符的 task,這樣確實不會讓工程師閒置,開發的 task 也消化的很快,達成了局部最佳化,但 story 完成了嗎?若測試資源還是稀少,那通常都要等到很後面才會看到 story 完成,這和盡快交付的精神違背。

要如何盡快交付?最簡單的就是 stop starting, start finishing。已經進行到一半的工作項目,就是盡快讓它完成,而不是在開啟新的工作項目,但這跟設定 WIP 限制有什麼關係?假設,測試的 WIP 上限是 1 (這是以一個工作項目有多個測試的 check list item 為例,若是以 task 為單位可以設為實際測試人員的數量作為上限),當有個工作項目停在測試階段,測試人員拼命側還是來不急測完,此時開發狀態的某工作項目已經完成,要送進下個狀態時就會因為違反 WIP 上限而無法送入,假設開發狀態的 WIP 上限還沒到,那開發人員可以再拉一個工作項目進到開發狀態,但如果也已經達到上限,就會發生卡住的情況。

這種卡住的情況是一種顯性瓶頸,和比較 task burn down 與 story burn down 曲線還更為明顯,由於已經卡住,所以團隊成員就必須想辦法解決問題,當然調高開發狀態的 WIP 上限是一種方法,但是一種笨方法,只是把問題往後延而已,事實上,看板方法就是強迫團隊去解決瓶頸,而不是視而不見,例如,開發人員可能不擅長寫自動化驗收測試腳本,但總可以幫忙手動驗收測試吧,或是就算寫得慢,還是可以停下新工作項目的開發工作,先幫測試人員寫自動化驗收測試腳本,戰鬥力雖弱也是一種資源啊!講義中有一個很有趣的比喻,工作項目是接力棒,團隊最重要的責任是讓接力棒不間斷地傳下去,直到終點,人有沒有閒置不是最重要的。

避免多工

課程中用翻銅板遊戲讓成員體驗多工不見得比較快,但我個人覺得翻銅板遊戲和平常軟體開發的多工其實不太一樣,於是能與現實工作產生的聯想就不明顯。自已的觀察,成員會常常多工,很大的原因是 task 切割得太細 (原因很多,就不在這細談),但彼此又有強烈的關聯,導致這些 task 一起做反而效率比較好。

當 task 切得異常細時,例如:我曾看過一個 story 切成數十個 task,story 紙卡上的便利貼貼到滿出來,以避免多工的角度出發,WIP 限制會是以 task 為單位去設定,例如:開發狀態的 WIP 限制為:開發團隊人數乘上 1.5,假設開發團隊為 4 人,則開發狀態的 WIP 限制為 6 個 tasks,這時候要小心,由於測試人員一開始可能沒事可做,所以開發人員把開發的 task 領到滿,然後持續這個情況,等到有某些 task 完成時,開發人員要領 task 時,卻無法領,因為已到 WIP 上限。又或者,因為 task 彼此關聯,想一起做時也會因為 WIP 上限出現排擠別的團隊成員能領的 task 數量。這些都是明顯卡住的警示,要團隊自己注意到該如何團隊合作以達到整體最佳化而不是局部最佳化。

另外一個導致多工的原因是,目前正在進行的 task 遇到阻礙,例如:要等其他部門的答覆,因為不想空等,所以領了新的 task 來做,此時這個人身上就會有多個 task ,當原有的 task 又可以進行時,成員又要進行 context switch 回到先前的工作狀態,如前所述,這也是一種浪費要避免。這時候會建議用個特殊的東西,像是磁鐵或是紅色的小便利貼貼在受阻礙的 task 以明顯標示該 task 目前是阻礙的狀態,若因為受阻礙的 task 多到一定的程度,團隊成員會很快達到 WIP 上限,於是團隊就必須思考如何加快排除阻礙,而不是等著它自行排解。

如果以剛剛我提到的喜好,以 story 當作工作項目的形式,每個 story 盡可能小,也許只是一個操作流程中的一個畫面,或是一個步驟。然後,將測試的 WIP 設為一個 story,若有 story 進到測試狀態,會希望團隊盡快將它完成;分析與設計狀態的 WIP 設為二個 stories,可以完成二個 stories 放在完成的子狀態,作為緩衝,開發狀態的 WIP 也是二個 story,保留一些執行上的彈性,但不希望有人同時執行超過二個 tasks。

不過這些設計都要與團隊取得共識,調整亦是如此。

落實

還在學校念書的時候,第一次接觸到《Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development》書中的 GRASP 方法時,總覺得怎麼這麼麻煩?我的直覺很快就可以畫出 design diagram 了,這方法真的有用嗎?那時課程的助教 Teddy 學長說了一句話:『傻的願意相信』,先相信這套方法是有用的,等到弄清楚整個方法後,變成自己的東西時,那時你就不覺得是礙手礙腳的,反而會變得自然而然地,也不會刻意在用什麼方法,但在這之前要先相信它,願意使用它,不然這東西永遠不會是你自己的東西,就這樣,後來像是 CI、Scrum、SLM (ALM) 等概念都是這樣建立起來的,kanban 也是如此,先別去懷疑,先照著方法試試看。

觀察

看板方法大概都會提到 CFD,但實際上以人工畫 CFD,超累的,一般還是要資訊系統輔助會比較方便,理想的 CFD 是平滑的,什麼!第一次在書上看到這個形容詞時,我完全不知道那是什麼意思,但在玩過一輪看板遊戲後,再回頭看組員紀錄的 CFD,和其他組記錄的 CFD,就比較有感覺,越平滑的 CFD 就是流程跑得越流暢,也更容易預測工作項目所需要的時間。理想的 CFD 會像這樣:

但實際的 CFD 都不太可能是上圖,實際 CFD 會比較像下圖的,若以垂直切割的角度看 CFD,可以看到每個狀態下的 WIP,由於每個狀態都會有 WIP 的限制,所以最多不會超過 WIP 限制,但可以看出哪個狀態的 WIP 低於限制,哪些滿載,如此就可以發現流程哪裡不太順。

若以水平切割的角度看 CFD,可以看到下面兩個數據:

  • lead time = work item completed time - work item created time,簡單說就是工作項目整體花的時間
  • cycle time = work item completed tiem - work item started time,是工作項目真正處理的時間

從 CFD 看到的不是各別工作項目的 lead/cycle time,是團隊的平均值,所以當 CFD 越平滑,就越能預測 lead/cycle time,當有一個新工作項目排入時,大概可以猜出幾天後能完成,當然,這兩個數值會動態浮動,預測就只是預測,對我來說,若狀態切割的恰當,更可以看到工作項目在每個狀態的平均時間, CFD 最有用的還是用來分析瓶頸與優化流程的好用工具。

Coach

關於 coach 這個問題,是我在課堂中問柯大哥的,過去在跑 scrum 時,會有位 scrum master,當團隊的牧羊犬 (團隊成員是羊),除了保護羊不受干擾,也同時驅趕羊維持紀律,但在看板方法中,並沒有定義這樣的角色,所以需要嗎?其實還是需要的,若原本是 scrum team,看板方法只是用來優化流程,所以 scrum master 還是 scrum master,還記得『尊重當前的流程、角色、職責和頭銜』這原則嗎?但如果原本不是 scrum team,還是建議有個人扮演類似 coach 的角色,觀察上述的數字及圖表,協助團隊制訂與調整 WIP 上限。

要當好的 coach 其實並不容易,方法要不柔不剛,要讓團隊成員聽得懂,想得通,還要時時觀察是否走偏了,曾聽過一個說法:『 task 非得要估時數,是因為要給 scrum master 看』,我聽到時有點愣住,scrum master 什麼時候在意一個 task 要花多少時間了?task 的時數只是輔助團隊判斷是否能再拉更多的 story 進到 sprint backlog 中,實際上時數是多少,跟實際上差多少,擔任 scrum master 的我根本不在意,scrum master 觀察的是事情有沒有順利被消化完成,有沒有過度承諾,有沒有火力分散,有沒有過度保守,這些都是看整體的趨勢,而不是看各別 task 的時數,像這種就是一種可能走偏的信號,coach 可能要跟團隊再次溝通估時背後的精神。

自省與行動

如果是 scrum 搭配 kanban (或所謂的 scrumban),一個 sprint 一次的自省會議是很好的時間點,讓團隊針對該 sprint 出現的瓶頸或問題進行修正行動方案的討論,並在下個 sprint 中執行,若不是 scrumban 也沒關係,有固定的週期或是團隊有默契當什麼警訊發生時,就會召開會議檢討並調整流程就可以,不然實務的第三點就永遠不會發生,只是在討論時,有了視覺化的流程加上 CFD 等圖表與數據,更能清楚地針對對的問題去討論,而不是團隊成員的感覺。

最後,目前還在讓團隊嘗試摸索 kanban 中,也希望團隊能運作得更順暢。

上完課到現在也有兩個多月了吧!算是晚了很久的心得報告,不過,有些東西還是需要時間沉澱跟自己思考一下!有時看到自己敬重的幾個 coach 前輩常常參加一些 agile 的課程,時時補充自己當 coach 的材料 (火藥庫),最近碰巧自己的 title 有些更動,也在想是不是要少寫點程式?開始往 coach 的方向走呢?

← 如何讓 Scrum 團隊有更好的預估 四年了 →