Ruddy Lee 分享空間

Emergent Design 演化設計

看板方法: 會議 Using Meeting to get Feedback and Collaboration

leave a comment »

「會議」是看板方法最讓人迷惑的地方之一,要依循現有的會議機制嗎? 還是follow Scrum的會議模式。總之;朝向敏捷去做就對了。我會建議你依據Lean 的精神來做判斷是最好不過的。下面是一些可以參考的意見:

  • 開會多不是問題,重點是要短。
  • 即時性的會議有時勝過固定式的會議。
  • 讓會議單純化,單一目的或目標的會議。
  • 會前先進行非正式的協商,會議只是用來做結論的,這樣能產生更好的信任跟默契。
  • 有趣的會後會,也是更精實、更深入技術性的討論方式。

( 這幾種方式,散亂的截取自 Toyota 的企業精神文獻)

 

※ 讓我們開始來談看板方法如何運用會議來得到回饋和達成協同合作:

這個話題牽扯到看板實務 (Core Practices) 第五及第六條:

  • 第五條 : 落實回饋循環  Implement Feedback Loops
  • 第六條 : 透過協作改善,經由實驗演進 Improve Collaboratively, Evolve Experimentally

說的白話一些,就是:

  • 「回饋是獲得改善的先決條件,能夠得到客戶或團隊成員的回饋意見,才能持續改善 。」
  • 「團隊透過協同合作來找到需要改善的地方,經由持續實驗來不斷的演化改進作業流程。」

這兩條實務的目的都在漸進的改善方式,正是敏捷開發的基本精神。

.

會議的一般定義:

會議是人類社會的一種社交、公關、政治、意見交流、訊息傳播及溝通的活動。它是一種社會科學,也是一種人文藝術,成功與失敗,在於與會者及各方的誠意及能力。

看板方法是流程控制;因此同步是一件非常重要的事,會議便成為了看板方法最好的同步機制。會議本來是針對特定主題而召開,但看板是即時訊息的系統,因此會議反而成了它的同步機制之一。

.

我們來談一下幾種重要的會議:

※ 每日站立會議  Daily Standup Meetings

David J. Anderson 認為6個人是召開站立會議最佳的人數,但最多達12人也可以。只是人越多效能可能就越差,還記得上回說過的那句話嗎? 當團隊成員對看板狀態一臉茫然的時候,此時看板方法實行起來的效果最差套用電影裡的常用語: Are you with me(你有跟上嗎)?真是再洽當不過了!當有團隊成員沒有跟上團隊在描述流程的進度時,就好像工作在不知其所以然的情境之下,效能一定不會好的。這是主持每日站立會議時需要克服的一個課題。

基本上,站立會議決定了漸進式調整的效能。看板方法第二條實務跟我們說要限制 WIP的數目,就是要讓工作符合流程的效能最佳狀態,這要遠比只是用功的做一大堆事要來得有用得多。因此看板團隊在這裡務必以簡單的規則來規範團隊的行為,讓大家有所依循(參考看板方法四部曲)團隊也就不會在不知其所以然的情境之下工作了。

.

以解讀流程、協調作業為主的站立會議

因為看板上已經明確的寫著Scrum站立會議所謂的三件事的相關資訊了,所以就不用在描述了,因此看板方法的站立會議的重點變成了以解讀流程、協調作業為主的站立會議。這個步驟習慣上是由看板的右邊向左邊進行,也就是拖拉卡片的方向,其中解說的動作才是重點,首先是"更新"工作項目,然後是"解讀"流程在更新前後的差異及出現的狀態,目的是讓流程能夠順暢進行。

接著是問"問題"的時候了,有沒有工作項目被Blocked住呢? 有沒有卡片在哪裡待太久了呢?問問題要問找對人來回答才是重點。在這裡往往可以看出團隊成員哪些人會勇於承擔問題。哪些人會習慣性地規避問題。看板的負責人(通常就是Scrum Master或專案經理)必須適當的引導成員透過分析問題,然後能夠果斷的做出正確的抉擇。這是團隊的一種習性,他可以提升團隊的效能,值得花時間來養成的。最後則是漸進式的"調整"。應該先考慮是對工作事項進行合併或是必須再分解成更細的工作事項呢? 然後才是調整 WIP值。

» 每日站立會議應該從哪裡開始? 從判斷現在對團隊最重要的事是甚麼;就從這裡開始。

.

※ 排隊補充會議  Queue Replenishment Meetings

對採用SCRUM的開發團隊而言排隊補充會議就是Sprint 計畫會議。但對看板方法而言,開會的目的是進行工作事項的優先級排序。因為牽扯到工作事項先後順序的決策,是一種越晚決策越好(盡量延遲決策 Decide as Late as Possible)的精實原則。所以參加的人士應該要有對產品開發的決策權的人士(scrum 稱之產品負責人 product owner)或業務代表。此類會議的目的是為了一個單一的流程、系統或針對填充看板系統的輸入排隊而召開。會議召開的頻率則視流程的大小而定,建議是固定一周一次。但對實施看板方法演進成功的團隊,最佳補充工作項目的方式則是根據需求來驅動排序,那就是JIT的方式沒有固定的時間,掌控會比較不容易。

看板方法往往較重視一個完整的功能(chunk),而不像Scrum 團隊經常將工作分得很細,這是你直接將Scrum 的product backlog 轉到 Kanban Board 上時會產生混亂的緣故。試著合併或分解較大的工作事項就可以了。

 

※ 會後討論 The After Meeting

它不是會後的跟催 Following Up After the Meeting,而是看板系統很容出現的一種臨時性的會議。當看板系統較大時就容易在會後,團隊成員三三兩兩的聚集在一起,通常也是採用站立的方式,簡潔的溝通一下剛剛開會之後有關執行的細節部分的討論。這是一種高效率的會議,我個人是非常喜歡這種會議,它展現的是成員們之間的默契培養。

很多主管會在意,是不是剛剛所開的會議效果不彰,才會產生這種會後會的事。但對看板系統而言這是正常的現象,這是因為當你站在看板前做討論時,總是會以較全面性(基於流程面)的方式在做討論,許多執行面的細節都不會被討論到(其實也不該討論到)。因此會後會就很自然地產生了。這類型的會議唯一要注意的是不要再產生其他目的,一次一個目標就可以了。

 

※ 發布計畫會議 Release Planning Meetings

這是專門為規劃下游交付活動而召開的會議。一般會選擇規則性的發布頻率,它會讓人有一種穩定感很有意義。成本是一個考量,所以二周一次可能是大家通常都可以接受的。專案經理是當然的負責人,一切協調交付最後都會以一份清單或檢查表的形式彙整給大家。考慮的事情有時候相當繁多,有時候甚至可以專門設計一個看板來跑它。

 

固定會議是回饋的最佳時機

Lean Coffee 來了! 喝個精實的咖啡吧。當組織開始推行 Agile 敏捷開發的時候,經常會遇到各種阻力,這些阻力大部分來自不了解,或是成員實在不知道怎麼做才對時,便容易產生不同的聲音,這些聲音累積多一點就變成了阻力, 尤其是多個層面同時做敏捷化時,這時候的溝通方式就很重要了,因此每每特別安排一個時段來聽取大家的意見,或是專門的大量的接受大家的詢問。這個時間就稱它為 Lean Coffee。

Lean Coffee 就是專門來聽取,大家的意見,回答大家的詢問的。(它也可以運用在遠端的溝通方式,差別在聞不到咖啡香了)

 

Written by ruddyllee

2014 年 10 月 17 日 於 22:49:01

發表迴響

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

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