在敏捷的專案管理中，團隊發揮每個人的主觀能動性，做到團隊自組織，在這個過程中，需要不斷同步資訊，在Scrum執行過程中，透過會議讓團隊成員都參與進來，每個會議內容不同，但是都非常重要。
在專案開始的時候，有交付計劃會議，在這個會議中，定下來專案的總體基調，而接下來就是每一個迭代，透過迭代計劃會議，每日例會，迭代評審會議，迭代回顧會議，不斷實現增量，產生成果，交付給客戶。
1
交付計劃會議
交付計劃會議可以說是專案的啟動會議，在這個會議中，定下這個專案的基調。 這次會議的目的是，居於使用者的需求已經優先順序，透過交付計劃會議，確定專案里程碑，釋出的目標，團隊成員，專案團隊的規章制度，包括例會、計劃會、評審會、回顧會的時間和要求。
1）開會的時間一般是專案啟動開始的時候，時長2個小時
2）參會人員：Product Owner、Scrum Master、 開發團隊、公司高層、客戶等
3）開會議題：
第一，Product Owner 介紹專案背景，專案的目標，介紹團隊成員，每個人團隊成員自我介紹，大家互相認識；
第二，Product Owner講述Product Backlog，對應的業務價值和優先順序；
第三，Tech Lead和QA Lead做可行性及時間的評估，對於技術框架選型確認；
第四，團隊針對Release Backlog和優先順序達成一致；
第五，高層宣佈專案正式啟動，開始專案。
4）會議輸出：
第一，規劃到release的 Product Backlog 條目，優先順序。
第二，各個 Backlog 條目的初略需求。
第三，Release裡各個story的時間的評估。
第四，團隊組成、人員安排、技術框架選型。
交付計劃會議開完以後，就要開始工作，每個交付分成幾個迭代，每個迭代開始就是迭代計劃會議。
2
迭代計劃會議
每個迭代開始，就要開始迭代的機會，在這個會議上，確認迭代包含的Story，這些Story時間、優先順序，講解需求，分配任務，對於成果交付標準達成一致。
1） 開會的時間一般為迭代開始第一上午，會議持續時間大概是2個小時。
2）參會人員：Product Owner、Scrum Master、 開發團隊
第一，確定團隊成員的Capacity， 需要去掉假期、會議的時間，一般8%的會議時間，2個星期大概有一天的開會時間。
第二，Product Owner跟團隊確定這個迭代需要做的Story、優先順序，Product Owner給開發和QA講解詳細的需求。
第三，開發團隊確定技術框架、根據需求確定技術方案。
第四，開發、QA明確需求以後，開始認領任務。
第五，團隊確定DoD， 統一完成的認識。
4）會議輸出
第一，規劃到迭代的Story條目、優先順序、詳細時間估算。
第二，開發，QA明確需求，確認技術方案。
第三，開發，QA認領任務
第四，團隊Capacity
第五，團隊完成的共識DoD
開完迭代計劃會議，大家就開始進入了專案迭代階段， 在迭代的每一天，都會開每日站會。
3
每日站會
迭代計劃會議完成以後，就要開始進入開發測試階段，在這個階段，需要大家全力合作，高效率完成任務，這就需要大家知道彼此的進度，解決遇到的問題，而這個就在每日站會來解決。在這個會上，主要就是更新任務狀態，解決遇到的問題。
1） 開會的時間每天上午10點，會議持續時間大概是15分鐘，不能超過這個時間，如果超過，需要重新評估開會，包括開會的方式、內容。
2）參會人員：Scrum Master、 開發團隊
第一，昨天每個人做了什麼？完成了什麼，什麼東西可以提交測試。
第二，工作中遇到了什麼問題，會不會阻塞進度， 解決了同步下解決方案，這個可以作為技術分享，如果沒有解決，看看有沒有什麼方案，如果要討論會後討論，要跟進會後有專人跟進。
第三，今天準備做什麼。
第一，所有的團隊成員知道各自的工作進展，這個可以為各自的合作提供基礎，比如說前後端合作，開發、QA的合作，這樣就不需要等，可以協商進度。
第二，得到問題的列表，這些問題都需要跟進，需要外部資源就需要Scrum Master去協調。
第三，更新任務板，得到最新的燃盡圖，這樣就知道任務實際執行與計劃的差別，進而做出下一步行動。
每日例會需要大家準時參加，同時也必須參加，不能把自己的進度發給Scrum Master， 這樣可以同步進度，不能發現問題，解決問題， 同時同事之間的協作如果沒有溝通會降低效率。
4
迭代評審會議
當迭代執行到最後一天，需要邀請Product Owner、Scrum Master、 客戶開會，對迭代成果進行演示並接受評價，根據反饋結果，提出新的產品Backlog
1） 開會的時間一般為迭代最後一天下午，會議持續時間大概是2個小時。
2）參會人員：Product Owner、Scrum Master、 開發團隊、客戶、公司高層
第一，開發或者QA演示迭代成果，Product Owner檢驗迭代成果，檢查是否完成迭代計劃中的迭代目標，並且使用迭代成果。
第二，對於迭代的成果提出自己的意見和建議，把這些安排放入到迭代Story裡面，更新產品的Backlog
第一，迭代成果，如果需要，Product Owner和客戶同意，就可以釋出了。
第二，問題列表，根據問題列表，更新產品backlog
5
迭代回顧會議
迭代完成以後，團隊檢視最近 Sprint 中有關個體、互動、過程、工具和他們的 Definition of Done 的情況如何。對於迭代的工作進行復盤總結，對於團隊的工作進行反思，這樣才能促進團隊的能力提升，效率提升。
1） 開會的時間一般為迭代結束下午，會議持續時間大概是2個小時。
第一，圍繞如下三個問題進行討論：
a） 本次迭代有哪些做得好；
b）本次迭代我們在哪些方面做得不好；
c）我們在下次迭代準備在哪些方面改進；
第二，團隊確定問題優先順序，並根據優先順序確定團隊能夠解決的Top問題；團隊討論Top問題的措施，並選擇在下一個迭代可以完成措施，分配責任人進行跟蹤。
第三，主要針對當前迭代，團隊成員自由講述可以需要保持的做法，改進的地方以及持續跟蹤計劃，在會議中不討論具體問題（如技術方案等）。
第一，將團隊討論以及行動計劃形成會議紀要，併發送給整個團隊和有關同事。
第二，需要按照回顧會議的結論，維護一份待辦事項列表，在下次回顧會議上進行跟蹤。
6
團隊成員抱怨會議多怎麼辦？
會議太多是很讓人沮喪的，特別是工作每天排滿，同時白天開好幾次會，工作需要晚上加班完成，這樣導致大家對於開會牴觸。
敏捷開發方式需要快速迭代，資訊快速流轉，很多事情需要依靠開會來同步資訊，這樣就會發現會議比較多，這個時候需要做好解釋，同時落實行動，讓團隊成員理解會議多，同時支援開會。
1）開會之前做好準備
所有的成員都是帶著思考、想法來到會議室，這樣到了會議室就馬上開始討論，節約時間，這就需要Scrum Master做好開會前的引導。
2）開會的時候要專注，不要自由發散
在開會的過程中，Scrum Master能夠控制開會的議題，而不會讓團隊成員自由發散，導致開會總是超時。
我們在開會的時候都是圍繞主題，如果有人跳出主題一分鐘以上，Scrum Master就要把想法記下來，然後把大家拉回到主題，發散出來的問題，可以以後再討論。
3）在安排任務的時候，把會議也作為一項任務安排進來。
很多人覺得煩是因為開會的時間不算做工作，或者臨下班開會，這樣佔用員工的時間。在統計時間的時候，要把會議時間計入，這樣開發就不會反感。
7
寫在最後
在Scrum開發方式中，小步快跑，交付增量，這就需要團隊成員提高效率，而會議是最快同步資訊，提高效率的一種方式。
在專案開始的交付計劃會議讓大家對於產品的目標有清晰的認識，而接下來就是每一個迭代，都會有四大會議，迭代計劃會議、每日站會、迭代評審會議、迭代回顧會議。
每一個迭代就是團隊的一次磨合，每一次回顧就是團隊的一次覆盤總結，這樣團隊不斷進步螺旋上升。
歡迎關注【阿布的分享】，跨界理工男，每天分享職場乾貨，認知成長。
歡迎在下方留言評論 別忘了分享點贊支援阿布哦
想了解更多精彩內容，快來關注
阿布的分享
