開工第一天，阿里工程師如何解鎖晨會新姿勢？

阿里妹導讀：Hi，好久不見！過年期間有木有一不小心想起可愛善良的阿里妹？

想起假期的美（lai）好（chuang），可能很多小夥伴和阿里妹一樣，還有些許不捨和眷戀。可是想想，我們從最有歸屬感的老家，來到了最有奔頭的天地，為了所愛的人、為更好的自己而奮鬥，是否也是一種守護？

既然選擇了遠方，便只顧風雨兼程。

言歸正傳。俗話說，一年之計在於春、一日之計在於晨。年後開工的第一天，我們來解鎖晨會的新姿勢：“站會”。站會到底有沒有必要開？如何才能高效地開好站會？下面我們結合阿里部分技術團隊的實踐經驗，一起來看看。

作者介紹：舍衛（花名），現就職於阿里巴巴研發效能事業部阿拉丁團隊。

站會的目標

說到站會，人們最熟悉的是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:

1.   需求和任務的狀態在站會前已更新；

2.  提醒帶電腦同學合上電腦，只有投屏和做記錄的同學使用電腦；

3.  從右往左檢視各列，按照6+1類關注點進行；

4.  開發中的需求數量是否已超過卡片數量的限制；

5.  開發中任務是否向需求對齊；

6.  需求是否按照既定的流轉規則進行流轉；

7.  單獨快速過一下缺陷的總體狀況，保持缺陷庫存低水位；

8.  記錄要跟蹤的問題和依賴項；

9.  會後小範圍討論遺留要解決的問題；

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

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

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

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

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

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

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

Q：站會時間到了，但還有個別同學沒有到，是等他還是不等？

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

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

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

最後，關於站會，你有哪些想法？歡迎在留言區分享，我們期待與更多同學一起交流、討論。

你可能還喜歡

點選下方圖片即可閱讀

史上首張中國面孔！阿里90後李響成為 CNCF 全球 9 位 TOC 之一

終於等到你！阿里正式向 Apache Flink 貢獻 Blink 原始碼

畢玄：我在阿里的十年技術感悟

關注「阿里技術」

把握前沿技術脈搏