在敏捷的專案管理中，團隊發揮每個人的主觀能動性，做到團隊自組織，在這個過程中，需要不斷同步資訊，在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、 開發團隊

3）開會議題：

第一，確定團隊成員的Capacity， 需要去掉假期、會議的時間，一般8%的會議時間，2個星期大概有一天的開會時間。

第二，Product Owner跟團隊確定這個迭代需要做的Story、優先順序，Product Owner給開發和QA講解詳細的需求。

第三，開發團隊確定技術框架、根據需求確定技術方案。

第四，開發、QA明確需求以後，開始認領任務。

第五，團隊確定DoD， 統一完成的認識。

4）會議輸出

第一，規劃到迭代的Story條目、優先順序、詳細時間估算。

第二，開發，QA明確需求，確認技術方案。

第三，開發，QA認領任務

第四，團隊Capacity

第五，團隊完成的共識DoD

開完迭代計劃會議，大家就開始進入了專案迭代階段， 在迭代的每一天，都會開每日站會。

3每日站會

迭代計劃會議完成以後，就要開始進入開發測試階段，在這個階段，需要大家全力合作，高效率完成任務，這就需要大家知道彼此的進度，解決遇到的問題，而這個就在每日站會來解決。在這個會上，主要就是更新任務狀態，解決遇到的問題。

1） 開會的時間每天上午10點，會議持續時間大概是15分鐘，不能超過這個時間，如果超過，需要重新評估開會，包括開會的方式、內容。

2）參會人員：Scrum Master、 開發團隊

3）開會議題：

第一，昨天每個人做了什麼？完成了什麼，什麼東西可以提交測試。

第三，今天準備做什麼。

4）會議輸出

第一，所有的團隊成員知道各自的工作進展，這個可以為各自的合作提供基礎，比如說前後端合作，開發、QA的合作，這樣就不需要等，可以協商進度。

第二，得到問題的列表，這些問題都需要跟進，需要外部資源就需要Scrum Master去協調。

第三，更新任務板，得到最新的燃盡圖，這樣就知道任務實際執行與計劃的差別，進而做出下一步行動。

每日例會需要大家準時參加，同時也必須參加，不能把自己的進度發給Scrum Master， 這樣可以同步進度，不能發現問題，解決問題， 同時同事之間的協作如果沒有溝通會降低效率。

4迭代評審會議

1） 開會的時間一般為迭代最後一天下午，會議持續時間大概是2個小時。

2）參會人員：Product Owner、Scrum Master、 開發團隊、客戶、公司高層

3）開會議題：

第一，開發或者QA演示迭代成果，Product Owner檢驗迭代成果，檢查是否完成迭代計劃中的迭代目標，並且使用迭代成果。

第二，對於迭代的成果提出自己的意見和建議，把這些安排放入到迭代Story裡面，更新產品的Backlog

4）會議輸出

第一，迭代成果，如果需要，Product Owner和客戶同意，就可以釋出了。

第二，問題列表，根據問題列表，更新產品backlog

5迭代回顧會議

迭代完成以後，團隊檢視最近 Sprint 中有關個體、互動、過程、工具和他們的 Definition of Done 的情況如何。對於迭代的工作進行復盤總結，對於團隊的工作進行反思，這樣才能促進團隊的能力提升，效率提升。

1） 開會的時間一般為迭代結束下午，會議持續時間大概是2個小時。

2）參會人員：Product Owner、Scrum Master、 開發團隊

3）開會議題：

a) 本次迭代有哪些做得好；

b)本次迭代我們在哪些方面做得不好；

c)我們在下次迭代準備在哪些方面改進；

4）會議輸出

第二，需要按照回顧會議的結論，維護一份待辦事項列表，在下次回顧會議上進行跟蹤。

6團隊成員抱怨會議多怎麼辦？

會議太多是很讓人沮喪的，特別是工作每天排滿，同時白天開好幾次會，工作需要晚上加班完成，這樣導致大家對於開會牴觸。

敏捷開發方式需要快速迭代，資訊快速流轉，很多事情需要依靠開會來同步資訊，這樣就會發現會議比較多，這個時候需要做好解釋，同時落實行動，讓團隊成員理解會議多，同時支援開會。

1）開會之前做好準備

2）開會的時候要專注，不要自由發散

在開會的過程中，Scrum Master能夠控制開會的議題，而不會讓團隊成員自由發散，導致開會總是超時。

3）在安排任務的時候，把會議也作為一項任務安排進來。

很多人覺得煩是因為開會的時間不算做工作，或者臨下班開會，這樣佔用員工的時間。在統計時間的時候，要把會議時間計入，這樣開發就不會反感。

7寫在最後

在Scrum開發方式中，小步快跑，交付增量，這就需要團隊成員提高效率，而會議是最快同步資訊，提高效率的一種方式。

在專案開始的交付計劃會議讓大家對於產品的目標有清晰的認識，而接下來就是每一個迭代，都會有四大會議，迭代計劃會議、每日站會、迭代評審會議、迭代回顧會議。

每一個迭代就是團隊的一次磨合，每一次回顧就是團隊的一次覆盤總結，這樣團隊不斷進步螺旋上升。