Ruddy Lee 分享空間

Emergent Design 演化設計

為看板方法制定簡單的規範 Simple rules to Interpret Kanban

leave a comment »

David J. ANDERSON 在創始看板方法之初只寫下了三條實務(Core Practices):

  1. 視覺化
  2. 限制WIP數量
  3. 管理工作流程

沒有特定的角色? 沒有特定會議(下回就來討論看板方法的會議)的規劃? 只有如何運用看板的方法。但是有趣的是;幾乎所有實施看板方法的團隊都有站立會議。這一點難免造成了大家對會議的疑惑: 這個站立會議要怎麼開呢? 怎麼開才能像scrum 的每日站立會議一樣: 大家都知道要做甚麼呢?

(Scrum 站立會議固定要由每一個成員描述三件事: 1.我昨天做了甚麼? 2.今天準備做甚麼? 3.有沒有遇到障礙? 但對實施看板方法的團隊而言這三件事都已經寫在看板上了,當然就不用由成員再做描述了。那麼看板方法的站立會議有必要招開嗎? 要開甚麼呢?)

» 我習慣的作法是訂定簡單的規則讓團隊有所遵循,也就是團隊運用"簡單規則法“來制定一般性、簡單的、容易遵循的規範。讓團隊成員依循規範在站立會議上能夠像scrum 的每日站立會議一樣,大家都知道要說些甚麼? 依據怎樣的程序進行。

實施看板方法最怕的就是團隊的成員,對正面臨到的阻塞問題一知半解,一臉茫然的樣子

— 團隊成員沒有跟上流程進度是看板效能不彰的最大原因

.

由於;看板團隊並沒有像Scrum Master這樣的特定角色,來負責保證實施看板方法的過程都能夠符合看板精實的精神。因此一般的看板團隊在督導這件事上;就很自然的由專案經理或產品經理來負起這個責任。但這是不符合Lean的精神的,團隊應該要學習如何做到自我管理。一個能夠自我管理的團隊在處理工作事項時,它的動作是高效能的、由下向上的,成員們能自動做到拖拉工作事項的行為,這才是看板方法精實的精神所在。該如何來解決這個問題呢?

.

解法;我們不但不能讓成員對看板上的狀態一知半解,更要要求每一個成員都能主動解讀看板上所發生的狀態,怎麼做呢? 透過訂定簡單的規則來實現。所謂的簡單規則;我稱它為「看板解讀四部曲」: RIQA: 它們分別是;更新 Renew、解讀 Interpret、提問 Question 以及調整 Adjust。

Kanban 解讀四部曲

.

【作法】

四部曲是一個循環,強迫規定在每次站立會議的時候由團隊成員以輪流的方式來帶領執行這四個步驟。目的是讓今天擔任執行解讀的成員,在會議開始之前就能先弄清楚看板的狀態,並能夠帶領團隊學習解決流程上發生的問題。從此以後大家便都能夠清清楚楚知道看板上所展現的狀態。這種透過每個人輪流帶隊作解讀的工作就不會有人一知半解了。

» 二人一組的解讀方式也是可行的,如果是 Scrum 的團隊,就讓Scrum Master陪伴一個成員進行四部曲,非Scrum 的團隊則以一次二個人解讀,但每次更新其中一人的方式來進行。讓團隊在合作的狀態下來進行解讀作業效果會好很多。我有過太多次的經驗,就是團隊成員始終表現的一知半解的;或是你也弄不清楚他是否知道自己要做甚麼。怎麼辦呢?只有一個方法可以弄清楚,那就讓他來講囉! 這也是我發明「看板解讀四部曲」的由來。

.

【看板解讀四部曲】

  • 更新 Renew: 更新工作事項、依據拉動原理更新看板。

  • 解讀 Interpret: 依據工作事項的類型、服務類別、到期日或是工作事項在queue內停留的時間來進行分析、了解。

  • 提問 Question : 對工作事項、對優先順序、對瓶頸 …都可以提問,但重點是要問對人。

  • 調整 Adjust: 針對執行上面三個步驟所得到的結果進行分析討論並決定如何解決(是對工作事項進行合併、分解呢? 還是調整 WIP值),運用調整的方式漸進的讓流程得到更順暢的改善。

四部曲是一個持續的循環,它的功能是讓團隊每個人都確實參與解讀的工作並能夠做到不斷的追蹤(tracking) 看板的狀態變化,隨後在用漸進的方式來解決問題。

.

SCRUM的每日站立會議

來談一下站立會議,對實施 SCRUM的團隊而言,站立會議對團隊或個人都是相當明確的事,大家都知道時間到了要做甚麼。工程師在自己的座位上從站起來,到走來開會的地點(Task Board 前面),一路上的思緒就不斷的圍繞在那三件事上頭,所有的人都是如此,因此開會的效率也就變得極佳。

會議是由 Scrum Master住持,但話說得最少的可能就是他了。每個人在說出自己昨天做了甚麼的時候,是個人自我審視、自我反省的最佳時刻了,他代表著你對團隊的貢獻度。而由你自己說出來,來贏得別人的尊重及喝采。因此大家自然都會十分重視這一刻的到來。得到喝采的人會繼續追求,失落的人會痛定思痛避免再次犯錯。以此做為一天的開始真是有百益而無害。

太多單位喜歡開站立會議了,即使在團隊沒在Run Sprint的時候,也會偶爾實行一下站立會議。沒開站立會議,好像一天就沒了開始。提不起勁來!

※ 讓看板團隊在沒有 Scrum Master 的督導下,也能自動自發的依循"簡單的規則"來順利的進行高效的站立會議。能夠自我管理的團隊,經常是透過制訂大家共同遵循的「簡單規則」來取得協同一致的成果的。而簡單規則怎麼來制訂呢? 歡迎參考我的《看板解讀四部曲》。 老實說;我總覺得四部曲好像多了些,如果可以訂得像起跑時的口令: 「各就各位 – 預備 – Go 」那就太棒了!

(看板方法是流程控制系統,它不是一個完整的軟體開發方法(至少現在還不是),從軟體工程的角度來看它,真的是相當不完備,缺少了不少的東西。所以當我們學習開始運用它的時候,請基於目前所採用的開發方法為考量,然後盡量去參考精實(Lean)的軟體開發原則來作決策,千萬不要把它拿來當做是一個完整的開發方法,也就是說;凡是它沒說到的我們就不做,真的這樣就錯得離譜了)

Written by ruddyllee

2014 年 10 月 14 日 於 00:48:29

發表迴響

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

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 位部落客按了讚: