昨天在東莞客戶封閉開發的現場，觀察了乙個產品開發組四個小組實施站立會議的情況，分析了他們執行的優缺點，對如何執行站立會議，如何獲得站立會議的成功進行了再次歸納總結，要點如下：
1 任務的分配與領用
i)任務的責任人要明確；
ii)任務的顆粒度小於2天；
iii)如果有的任務顆粒度實在無法拆分到2天以內，則需要設定中間的檢查點；
iv)任務的完成時間要明確；
v)任務的完成標準要明確；
vi)任務識別的要盡可能完備，不要在過程中增加很多遺漏的任務。在識別任務時，團隊中的各個角色都要參與，要充分討論。
vii)增加、修改的任務要增加小貼紙明確地在看板中標識出來，這些任務可以採用不同顏色的貼紙標識出來。
viii)高層經理不要越級直接給團隊成員下達任務。
2 任務的完工檢查
i)不能只靠責任人匯報說完成了就認為任務已經完成了，應該有檢查，如果是編碼，則要通過了規範符合性的檢查、工具的靜態檢查、人工的**走查或單元測試，並通過客戶代表的確認，如果是編寫文件，則應該通過了評審，如果是預研，則應該展示了預研的結果。
ii)要區分任務的完成與需求的完成。需求的完成需要多個任務完成的支援，不但要跟蹤任務的進展，也要跟蹤需求的進展。如果不是採用迭代的模型，而是採用瀑布的模型，可以定義乙個任務進展的內部準則，比如對於乙個use case，如果需求定義完成，則任務這個需求完成了10%，如果詳細設計完成，認為這個需求完成了30%，如果**完成，則認為任務完成了50%，如果單元測試通過，則認為這個需求完成了70%，如果系統測試完成則認為完成了100%。
3 進展的跟蹤
i)採用燃燒圖標識每個小組的進展，每天站立會議完成後更新燃燒圖。
ii)採用燃燒圖標識整個產品開發團隊的進展，可以每天或2天等更新燃燒圖。
iii)每個小組、整個產品的進展都要及時跟蹤進展。不能關注了區域性，忽略了整體。
4 站立會議
i）每天定時、定地開站立會議，不需要事先通知；
ii) 在站立會議上每個人當且僅當回答3個問題：
昨天完成了什麼？
有什麼難題需要別人幫助解決的？
今天做什麼？
iii)在匯報每個人的進展時，不需要匯報是如何做的，將要如何做。
iv）需要別人幫助的問題在會後單獨討論
5 小組長
i) 主持會議，確保每位組員發言時不能跑題；
ii) 可以點評、提醒每個人的工作，但是一定要簡短點評；
iii) 如果對總體情況進行總結，一定要簡短。
6 會議紀律：
i) 不能遲到，如果遲到就懲罰之；
ii)只有乙個聲音在發言，不能乙個人在發言，其他人在開小會；
iii)非本小組的成員，可以旁觀，不需要發言；
iv)不能中途有人退席，有的人匯報完自己的進展後，就退席是不允許的。
7 物理設施：
i) 站立會議時一般要有白板，在白板上貼上的是本專案組的任務狀態：未開始的任務，進行中的任務，中斷的任務，完成的任務。其實也有一些敏捷的工具，可以電子化sprint backlog，但是還是不如物理的白板更有視覺的衝擊力。
ii) 白板的面積要大，如果所有的任務不能在白板上貼下，則可以只貼本次迭代的或最近一段時間的，比如2周的。
iii) 如果白板面積不夠，可以不用貼紙，手寫任務。
iv) 貼紙容易掉，可以用小磁條粘在白板上或不幹膠
v）限於辦公環境，每個小組的站立會議可以錯開時間開。
8 其他注意事項
i) 一定要當面開會，不能郵件替代站立會議；
ii) 一定要每天開會，每天跟蹤專案的進展；
iii) 不需要整理會議紀要，除非有其他目的；
軟體開發中，站立會議的必要性
筆者經歷過大到600人 小到20人的專案團隊，很多團隊中會引入敏捷尤其是scrum實踐，其中乙個重要的實踐是站立會議，遇到過團隊成員抱怨站立會議浪費時間，甚至在有些團隊中leader也持這種觀點，最後堅持不了幾次就不了了之了。那麼，站立會議 甚至說敏捷 是否有必要呢？我很能理解團隊成員抱怨站立會議浪...
試行每日早上站立會議的一些感受
在敏捷開發中非常推崇進行standing meeting，強調面對面的交流勝於文件。在最近的工作中發現，有些成員對自己工作不明確，而我又是不定時的詢問，往往導致問題出現到有解決方案的時間不能控制，自己也覺得安排很亂。因此，我就把這個敏捷實踐加入到我們的日常工作中來了，僅僅試行了半個月，效果感覺非常明...
專案中站立會議和故事牆的那些事兒 敏捷開發
專案組一直在推敏捷開發，但發現乙個關於每日例會的問題。場景 有時大家比較忙時，主持人會乙個個去詢問團隊成員工作狀況。問題 不應該有個主持人，這會導致主持人過於繁忙，而其他人投入度降低 只關注自己的問題 建議每人個人主動去講解自己的工作和計畫，主動，自發和自組織，這才是關鍵 最糟糕的是，主持人挨個詢問...