今天我們講講如何利用站會，更好地實現促進團隊有效協作和聚焦，促進價值順暢流動和交付，同時及時的暴露問題和風險。

注：精益看板方法視訊教程請前往：https://yq.aliyun.com/live/717

站會的目標

說到站會，人們最熟悉的Scrum站會，典型的形式是團隊圍成一圈，依次回答三個問題：昨天做了什麼？今天準備什麼？有什麼阻礙或問題？通過站會，Scrum團隊成員瞭解其他成員的工作，從而更好地協作，達成迭代目標。

看板方法應用得當，視覺化價值流實踐執行到位，以上三個問題完全可以清晰地展示在看板上，所以沒有必要再回答這些問題了。那站會的目標是什麼呢？

回到精益看板方法本身的目標：順暢和高質量地持續交付有用的價值。相應的，看板站會要聚焦於價值的流動，而非個人工作。

站會的目標是：促進團隊有效協作和聚焦，促進價值順暢流動和交付，同時通過站會同步需求進展和暴露問題及風險，把視覺化價值流實踐落地到位。

站會的前提

在建立了如下圖的精益看板系統的視覺化價值流（以雲效看板為例），明確流轉規則和限制在製品數量的三個實踐之後，還需要管理價值流動和建立效能反饋閉環並持續改進。管理價值的流動具體包含管理價值流動過程，價值的輸入和價值的輸出，關於管理價值流動過程的一個很重要的實踐就是每日看板站會。
關於如何建立精益看板系統，後續雲效會有專門的文章來詳細講解。

站會組織形式

1、頻次：每天（每個工作日），時長不超過15分鐘，一般在早上，具體時間團隊可根據實際情況調整，建議9:45或10點開始；
2、三個相同：同一個團隊在同一時間、同一地點在看板前進行日站會，形成固定的節奏後，會變成團隊的習慣；
3、協調人：團隊成員站在圍在看板前，由一位協調人來帶領團隊從右往左（⬅️）逐列走讀看板；協調人可以固定，也可以輪流進行；
4、電腦：為了讓站會更加聚焦和高效，負責投屏和記錄的同學可以帶電腦，其他人不需要帶電腦；

站會前：需求和任務的狀態已更新

1、團隊已按照統一優先順序的規範更新需求的優先順序，輔助優先順序，狀態、期望日期等

2、開發同學按照實際情況更新需求和任務的狀態（任務向需求對齊）。

需求負責人負責協調把開發中的需求拆分成任務（如下圖），並協調需求從開發完成，測試，直到釋出完成為止；
已拆分好的任務需指派到個人，任務的顆粒度在1-2天的工作量，確保每天都有看得見的進展 ，及時暴露風險和問題；
任務責任人已更新好任務的狀態和截止日期；
如有外包-介面人合作：外包同學也需要在站會前更新狀態，介面人按照流轉規則進行狀態流轉。

站會重點關注的資訊

站會上不需要檢視每一張卡片，本著“促進價值順暢流動和交付” 的目的，我們要重點關注影響價值流動的問題和阻礙項，如下圖所示，絕大部分問題會標記橙色或紅色，可以很清晰地體現在雲效看板上。

瓶頸和佇列：某個環節不順暢時，需求積壓形成佇列，這就是瓶頸所在，瓶頸是站會第一重點關注點，因為系統的流量往往是由瓶頸決定，只有解決了瓶頸問題，價值才能順暢地流動。看板上的表現就是某一列的需求卡片數量特別多。

關鍵的缺陷：缺陷會阻礙需求的流動，而且缺陷多容易出現需求積壓，從而阻礙其他需求的流動。阻塞需求流動的缺陷需要及時解決，期待做到缺陷日清（缺陷發現後24小時內解決，甚至當天就解決），在Fixed狀態（指缺陷已修復，待提出缺陷者驗證）的缺陷需要及時驗證和關閉。保持缺陷及時發現即時解決和關閉，保持存量缺陷保持低水位。站會時需要抽1-2分鐘過一下整體缺陷的狀況。

重點關注的需求：指涉及重點商業利益或風險的重點需求，看板上會用紅色的標籤來凸顯。

阻礙和問題：指因外部（如依賴）或內部（如設計缺陷）原因無法正常流動的需求。團隊需關注被阻礙的需求，跟蹤和推動問題解決，及時恢復它們的流動。看板上會紅色的阻礙項來標記。

到期或即將到期的需求：部分需求有明確的完成時間要求，例如存在對外承諾的需求。如果它們即將到期或已經到期，就需要特別關注，以確保承諾的達成。看板上快到期的需求會用橙色凸顯時間，已到期的需求會用紅色凸顯時間。

中斷：指某個步驟供給不足，價值流出現中斷，如上圖中，就緒（待開發）這列沒有需求，此時上游佇列需要儘快供給到該列。

未反應在看板上的問題：走讀完看板，還需要新增一個問題：“是否有為反映在看板上的問題需求溝通”。團隊當然需要關注沒有反映到看板上的問題，同時，團隊和站會的協調人需要有意識地思考，這類問題是否可以和應該反映在看板上，以提高視覺化和執行的效果。

站會中：促進價值順暢流動

站會上，團隊按照"站會重點關注資訊6+1"從右向左檢視各列，促進價值順暢流動，同時要避免在一個問題上花費過長時間，耗時長的討論要放在會後小範圍進行。

15人以內的團隊，站會要能在15分鐘內完成，在現實中，效果不好的站會，往往耗時會比較長。

站會中討論帶來的變化，需即時更新到看板上，如有問題，也需求及時記錄。

下圖給出了站會中應該做到和應避免的問題：

還需要明確的是，站會只是團隊溝通的一個場景，更多的溝通要在平時和更小範圍內發生，而不是過度依賴於站會。

站會後：資訊透明，風險和問題跟進

站會需要達成的成果：

看板已處於最新的狀態，反映站會討論的結果
識別阻礙需求流動的問題，並現場解決或則安排會後跟蹤的Action
團隊成員瞭解專案的整體進展和狀態
團隊成員清楚工作的優先順序

會後小範圍討論需求較長時間才能解決的問題。

總結：

站會的目標是：促進團隊有效協作和聚焦，促進價值順暢流動和交付

站會要以價值交付為線索，從右向左檢視需求的狀態，聚焦於發現和處理價值流動中的問題

不應該依賴站會檢查每個人的工作，價值交付的狀態和問題應該已清晰的體現在看板上，良好設計和應用的看板是高效站會的基礎

更多的協作應該即時發生，不應該完全依賴站會來進行團隊協作

一個好的站會，幫助團隊瞭解整體的價值流動狀況，促進有效的協作，並即使處理價值流動的問題，保障價值順暢流動。

附1：站會Checklist:

需求和任務的狀態在站會前已更新；
提醒帶電腦同學合上電腦，只有投屏的同學使用電腦；
從右往左檢視各列，按照6+1類關注點進行；
開發中的需求數量是否已超過卡片數量的限制；
開發中任務是否向需求對齊；
需求是否按照既定的流轉規則進行流轉；
單獨快速過一下缺陷的總體狀況，保持缺陷庫存低水位；
記錄要跟蹤的問題和依賴項；
會後小範圍討論遺留要解決的問題；

附2：站會中會碰到的問題：

Q：在Scrum站會中，典型的形式是團隊圍成一圈，依次回答三個問題：昨天做了什麼？今天準備什麼？有什麼阻礙或問題？為啥看板上不需要回答這三個問題了呢？

A：看板方法應用得當，視覺化價值流實踐執行到位，以上三個問題完全可以清晰地展示在看板上，所以沒有必要再回答這些問題了，同時我們需要按照需求來組織站會，關注價值流動，而不是按人來組織站會。

Q：開發同學站會上講了很多，可產品經理同學卻聽不懂，同時對需求的進展也不太清晰

A：按照Scrum的方式，回答三個問題，開發同學往往說的是技術實現和細節，產品經理自然會聽不懂。需求作為價值是產品經理的輸入，看板關注的是價值流動，不是任務的完成情況，需求的狀態和問題可以很清晰地在看板上體現出來，同時在開發中的需求也會拆分成各端或各模組的任務，拉通技術各角色之間的協同。這樣既可以看到價值的流動，也可以看到任務的進展和對齊，產品和開發同學都可以一目瞭然知道目前的進展與問題。

Q：為啥看板要從右到左檢視各列，而不是從左到右檢視呢？

A：從右往左，一方面體現價值拉動的方向，另一方面是為了更好地貫徹“暫緩開始，聚焦完成”的原則，讓接近完成的需求儘快的完成，而不是開始更多的需求開發。譬如測試中發現的Bug，從右到左更方便優先解決Bug。

Q：站會時間到了，但還有個別同學沒有到，是等他還是不等？
A：團隊需要共識此類事情發生的機制，避免這樣的事情發生。當確實有個別成員遲到了，一般建議站會還要在固定的時間和地點進行，當然團隊對於遲到可以有團隊處理的辦法，譬如邀請遲到的同學給大家買水果吃等等。

Q：團隊處於兩地，甚至多地，站會如何開？

A：雲效電子看板的好處就是便於異地開發，各地成員都開啟看板頁面，同時用電話會議的方式接入，進行異地站會。目前雲效看板已可以做到需求卡片移動後瞬間同步。

Q：兩個需求都進行了近一半卻都不能提測？如下圖

A：圖中用紅框圈起來的兩個需求，一個是前端任務已完成，後端任務在處理中，另一個是前端任務在處理中，後端任務已完成，這總情況需要避免，團隊需要聚焦其中一個需求，讓其快速完成，而不是啟動兩個，讓兩個都只是完成一半或90%。

附3：團隊開站會的照片：

雲效協作域團隊

資訊平臺訴訟團隊

阿里雲飛天一部工業大腦

CEM客戶運營平臺的物理看板的站會

站會上很多人都帶電腦，效率就會相對低，不建議出現這種情況。

原文連結
本文為雲棲社群原創內容，未經允許不得轉載。