敏捷開發模式中的四種會議

從敏捷開發流程模型圖當中可以看出，在敏捷實施過程當中，有四種會議，分別是計劃會，每日站會，回顧會，評審會，其中數計劃會最為重要。應該來說會議是有點多的，不是流傳一種說法嘛，不開會的團隊的一定不是一個好團隊，好的團隊一定經常開會。經常開會是需要時間的，因此有利有弊，如果會議時間和節奏控制的不好，就會佔用掉團隊很多的精力和工作時間，那就得不償失了。在敏捷開發模式中，每種會議都有其特殊的職責和使命，不同的會議上所討論的內容是不一致的，只要把握住會議的關鍵點，就可以為團隊的敏捷模式服務。

關於開會，日常工作當中各種會議、培訓、溝通等都會佔用掉大量的工作時間，因此會議貴精不貴多，在最短的時間內達成最有效的決議，這才是一個有成果的好會議。產品團隊必然也會面臨這樣的問題，在敏捷團隊內部，除了必要的全員培訓外，儘量保持在團隊內部只有敏捷的這四個會議，其餘的溝通和會議都可以由PO和SM去參加，然後回來傳達給團隊成員即可，這樣可以減少團隊整體的時間消耗，保證團隊的工作效率。

Sprint Planning敏捷迭代計劃會議

在每個敏捷迭代開始之初，由產品負責人講解需求，並由開發團隊進行估算工時的計劃會議。 在會議上需要：排列需求優先順序；分析和評估產品Backlog並確定該迭代的目標；計劃會議上還需要制定迭代計劃，包括： 根據產品Backlog（功能點）建立Sprint Backlog（即迭代任務）；然後為Sprint backlog中的任務做估算；團隊成員從產品Backlog中挑選他們承諾完成的條目。

敏捷的迭代實現始於計劃會議，所以一個好的計劃會議是每個迭代成功的基礎，一般分兩個階段進行，兩個階段參與會議的人員會不一樣；

計劃會議的目標：

1、基於敏捷規劃產生的Product Backlog以及優先順序，通過計劃會議，確定迭代的目標、團隊成員、形成Sprint Backlog，明確評審會、回顧會時間；

2、分解Sprint Backlog並確定相應的完成時間，並由團隊成員共同挑選這些Sprint Backlog；

階段一參與人員：產品經理、Product Owner、Scrum Master、團隊成員，有業務人員的話還可以邀請業務人員一起參加。

會議時長：1-4小時

一般參考程式安排如下：

1、Scrum Master公開迭代時間表；

2、產品經理和Product Owner講述Product Backlog，對應的業務價值和優先順序；

3、團隊針對Sprint Backlog和優先順序達成一致；

4、Scrum Master和團隊成員共同確定Sprint Backlog；

階段二參與人員：Scrum Master、團隊成員，其他人員選擇性參加

會議時長：1-4小時

一般參考程式安排如下：

1、團隊成員針對Sprint Backlog共同分解任務；

2、團隊成員共同進行工作量評估(每個Task不超過2天)，確定開始時間和完成時間；

3、團隊成員共同認領任務；

4、共同確定DoD，團隊達成一致；

5、團隊共同確認迭代目標和價值；

如果單個迭代內安排的Product Backlog安排的比較多的話，一般迭代計劃會議需要開一個整天，雖然時間有點長，但這個會議會確認整個迭代的詳細計劃和安排，因此也是值得的。

Daily Stand-up Meeting每日站會

團隊每天進行溝通的內部短會，因一般只有15分鐘且站立進行而得名，團隊成員通常會在會議上講述如下3點內容：

1) 昨天我做了什麼

2) 今天我計劃要做什麼

3) 我遇到了什麼問題，妨礙了我儘可能有效地工作

Scrum Master記錄會議上提出的問題，但是不要在會議上討論和解決問題，而是要會後在找相關人員進行討論和解決。

Sprint Review敏捷迭代評審會議

在迭代結束前給產品負責人演示並接受評價的會議，並根據反饋結果，提出新的產品Backlog

參與人員：產品經理、Product Owner、Scrum Master、團隊所有成員

會議時長：1-4小時，視演示內容而定

主要是檢驗迭代成果，檢查是否完成迭代計劃中的迭代目標，有可能的話要求使用者參與測試流程，並得到使用者對產品的認可，鼓勵使用者自己進行測試設計和進行破壞性測試，充分暴露產品的設計和功能問題。

由Scrum Master來推進會議程式，Product Owner記錄使用者反饋，根據結果維護產品 backlog，一般在迭代結束前做一次。

Sprint Retrospective敏捷迭代回顧會議

在每個迭代結束後召開的關於自我持續改進的會議，圍繞如下三個問題進行討論：

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

2) 本次迭代我們在哪些方面還能做得更好；

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

團隊確定問題優先順序，並根據優先順序確定團隊能夠解決的Top問題；團隊討論Top問題的措施，並選擇在下一個迭代可以完成措施，分配責任人進行跟蹤。

參與人員：Scrum Master，Product Owner，團隊成員。

會議時長：0.5-1.5小時

主要針對當前迭代，團隊成員自由講述可以需要保持的做法，改進的點以及持續跟蹤計劃。

Scrum Master將團隊討論以及行動計劃形成會議紀要，併傳送給整個團隊和有關同事。需要按照回顧會議的結論，維護一份待辦事項列表，在下次回顧會議上進行跟蹤。

案例分析

案例一：某Team在每日站會中，Scrum master準時組織大家開始晨會，成員一個接著一個說，昨天做了什麼事情，今天計劃做什麼事情，遇到什麼問題，成員A說昨天遇到了一個問題未能解決，Scrum master問遇到的是什麼問題，成員A詳細說明了該問題，這時成員B說這個問題他也遇到過，他是通過XX方式解決的，討論後成員A明白了，然後繼續晨會，由於小組成員有10個人，整個會議開下來大概花費了30分鐘。

問題分析：Scrum master不應該在每日站會上詢問詳細的問題細節，而應該轉移到會下詢問，當團隊成員之間進行討論的時候，Scrum master需要及時拉回來，討論應該轉移到會下進行，晨會要在固定的時間固定的地方並且在固定的時間內完成。會議時間需要控制在15分鐘之內。

案例二：某Team在開回顧會議中，Scrum master詳細總結了本次迭代中有哪些做不夠好的，並指出了對應的事和人，接著對應的責任人開始述說哪些地方確實是做的不夠好及其原因，最後給出改進措施然後結束會議。

問題分析：回顧會不是批鬥會，不應該只說做的不好的，做的好的也要說，Scrum master主要是鼓舞大家的士氣，應該先從做的好的方面開始說起；並且做的不好的方面都只對事，不對人，做的不好是整個Team的責任，不僅僅是某幾個人的責任；最後的改進措施需要給有後續跟蹤的責任人和有效性的反饋。

在敏捷的迭代執行過程中，上述四種會議會隨著每個迭代一直進行，基本上形成了一個閉環，可以讓團隊在每個迭代的執行過程當中去學習和總結，從而正確的按照敏捷的要求去做，使團隊真正的敏捷起來。