Ruddy Lee 分享空間

Emergent Design 演化設計

Posts Tagged ‘團隊如何解讀看板

團隊如何解讀看板 – 1分鐘統計報告

leave a comment »

.

許多敏捷團隊都已經運用看板進行站立會議,但卻仍然採用傳統Scrum站立會議的三件事來進行會議:

  • 昨天做了什麼?

  • 今天準備做什麼?

  • 有沒有遇到障礙?

 

對看板而言;其實這三件事都已經記錄在看板上了。雖然這種做法基本上沒有什麼問題(我也一直是這麼做的,但總是會覺得好像有些不足的地方,好像可以作得更好才是,因為這是團隊共同的事,所以應該是團隊一起運作才是,一問一答的輪詢方式似乎太個人化了?!)。這麼做會忽略了看板上已有的資訊,而無形間浪費了看板上的基本資訊,也就是團隊在「視覺化」上的認知機會。團隊也會因此把焦點放在了個別成員的身上,而忽略了看板所具有的團體性。那要怎麼做才能充分運用這些特性呢? 一種看板式的站立會議,它是以團體為主的方式,它專注於回饋(一分鐘統計報告):

.

解讀看板

適合團隊共同運作的看板式站立會議

.

一分鐘統計報告

首先;運用值星生的方式,讓團隊成員輪流擔任這個職務,輪到的人,就要負責看板的維護工作,然後必須在站立會議時做先期解讀的工作,先幫大家做一次統計式的解讀,目的是協助團隊迅速進入狀態。然後才是由SM負責一對一的輪詢,問的內容當然就不止於那三件事了。進行的步驟如下:

  • 設定「值星生」的制度,以一個星期為一輪,讓他負責日常看板的整理工作還有看板的維護。並於站立會議時首先發言,用一分鐘來向大家解譯目前的看板狀態,讓團隊能迅速進入狀態,而無須重新做個別解讀。提供團隊一起能夠同步看板的視覺認知。這是一種單向的報告方式,團隊無須立即回饋。「值星生」必須以統計分析的方式進行報告看板現狀。

  • 然後由SM 接手以 提問 的方式輪詢團隊成員個別的工作狀態,並要求成員對值星生的報告進行必要的解釋或回饋

  • 最後,SM針對個別事件進行 重點討論,詢問團隊是否變更流程以解決障礙、等待Waiting狀態說明及討論是否需要進行變更(WIP值)來改善流程速度,作總結或重申重要事項。

.

統計式解讀.png

參考自一日看板遊

.

統計式的看板解讀

解讀上圖: ( 由右往左)

》團隊還沒有成功的發佈任何東西,因此發佈欄位是空的。

》有一個嚴重障礙,就是測試區Task-A 無法被正常布署,沒能夠通過測試,測試人員正在努力中,但因為測試欄位的 WIP值設成1(因此只要有任何一項測試失敗看板就會被卡住)。

》這時候當初做Task-A的成員正在做 Task-C(是否請他們協助偵錯? 畢竟解鈴還須繫鈴人),而另外一組成員已經做完Task-B了,但受限於看板測試欄位的上限WIP值因此無法移進來做測試,因此沒有進度。

》預備欄位目前只有一個 Task-D 可以再移入一項工作。

》此時產品負責人PO仍在審視所有的工作項目。

看板解讀由右往左的目的是希望能盡快看到障礙,尤其是上圖中將測試欄位的WIP上限設定成1,表示這個團隊非常重視品質,只要有任何一個測試失敗的工作項目,團隊就要停下來解決,一直到解決之後才能繼續開發的流程。當然我們可以考慮把WIP上限調高,但這樣做了就會延遲解決問題的速度,但仍然能夠持續有產能輸出,好處就是生產線不會完全停下來。

 .

善用值日生

看板需要整理,又必須與工具(ALM: Application Life Cycle Management)同步,SM常常為此抱怨連連。採用值星生的方式能夠適當的降低SM的負荷,又能多一個人出來管理、解讀看板。是團隊落實自我管理的一種實踐。

因為以星期為範圍所以稱為值星生好像比較準確。看板值星這件事,勢必會造成「值星生」不得不在站立會議之前先行整理過看板,然後再運用統計的方式先行解讀過看板,然後才能在站立會議時運用足夠簡潔的語句描述給團隊聆聽,而團隊也會因為有人代為解讀了看板,便可以省下各自解讀的時間花費,一起聆聽看板解讀也能造成大家對看板上的動態有更一致的認知。同時這也是一種回饋的方式(只要團隊成員聽完後覺得跟自己的解讀有所差異時,此時成員之間任何的交談與討論都是極具價值的)。

.

小結

團隊共同解讀看板的方式:  (站立會議開始)由「值星生」先為大家以統計的方式做1分鐘看板解讀,然後才是由 SM 接著進行輪詢團隊成員,成員一一更新看板上的工作項目,同時就剛剛值星生的解讀進行解釋或更正。完成一輪後SM 做成重大事項的總結或重申重要任務。站立會議於 15 分鐘內結束。

.

廣告

Written by ruddyllee

2017 年 04 月 25 日 at 17:27:26