日站會——你的站會姿式正確嗎？

時間 2019-12-08

標籤正確简体版

原文原文鏈接

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

站會的目標

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

看板方法應用得當，可視化價值流實踐執行到位，以上三個問題徹底能夠清晰地展現在看板上，因此沒有必要再回答這些問題了。那站會的目標是什麼呢？後端

回到精益看板方法自己的目標：順暢和高質量地持續交付有用的價值。相應的，看板站會要聚焦於價值的流動，而非我的工做。運維

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

站會的前提

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

雲效看板示例：入口阿里雲

站會組織形式

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

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

一、團隊已按照統一優先級的規範更新需求的優先級，輔助優先級，狀態、指望日期等
設計

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

需求負責人負責協調把開發中的需求拆分紅任務（以下圖），並協調需求從開發完成，測試，直到發佈完成爲止；
已拆分好的任務需指派到我的，任務的顆粒度在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：電子看板的好處就是便於異地開發，各地成員都打開看板頁面，同時用電話會議的方式接入，進行異地站會。目前Aone看板已能夠作到需求卡片移動後瞬間同步。

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

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