對於乙個專案而言，不開會是不能很好達成共識的，統計一下會發現整個專案的會議確實開的不少，但真的有成效的有多少呢？不要為了開會而開會，開會要解決實際問題，開會不是大家無聊的瞎扯，每個人低頭各自玩手機，而沒有任何實質性的共識和決策。
低效率的會議、不必要的會議，是浪費大家時間，是增加專案成本，是消耗團隊積極性，是培養團隊惰性，公司的氛圍和文化也會逐步惡性改變。所以，需要反思下哪些會議是真正需要積極去組織的，哪些是對專案開展無益需要去掉的，哪些是需要選擇性組織召開的，讓會議變得更加高效而有成效。
專案管理有其適應性，針對不同的企業、不同的團隊、不同的業務、不同的行業、不同的外界環境，需要裁剪選擇適合其良好運作的方式方法，保障高效的協同為專案目標達成而服務。
一、專案流程會議
1.立項評審會
主要是對專案的價值進行評審，是否值得公司投入人力、物力、財力去開展；
討論內容：市場前景、可行性分析、研發內容、上市計畫、投入成本分析等；
2.專案啟動會
3.迭代規劃會
主要是對迭代進行需求的明確，功能優先順序的調整，進度計畫的澄清，確保當前迭代的順利交付；
討論內容：迭代內的需求澄清、進度計畫、任務安排、需要配合支援事項、風險和問題等；
4.迭代驗收會(按需組織)
主要是對迭代交付的成果進行演示，產品專案對迭代成果進行體驗確認，及時發現問題；
討論內容：迭代規劃會功能點、測試驗證功能點、產品專案體驗問題點、優化解決方案等；
5.迭代回顧會(按需組織)
主要是迭代結束時，對該迭代團隊溝通配合協調等方面做的好的和不足的，在後續迭代改進實施；
討論內容：團隊溝通配合中做的好的、做的不足的、改進方案等；
6.結項評審會
主要是對專案進行回顧總結，對交付功能進行演示，對專案取得成效給出評定，團隊激勵等；
討論內容：專案簡單回顧總結、專案交付功能演示給主干係人、團隊暢所欲言分享經驗教訓、後續改進事項等；
二、專案日常會議
1.每日站立會
主要是對風險前置，風險暴露和問題跟進；功能優先順序調整，按迭代計畫調整功能優先順序，粒度到天；
討論內容：昨天做了什麼？今天要做什麼？碰到什麼問題？需要什麼支援？
2.原型評審會
主要是對需求的形象具體化，足以引導ui設計和程式開發，確定對原型(需求)理解正確；
原型很難一步做到位，需要建立原型版，不斷進行完善，並組織原型評審，可在迭代規劃會開展；
討論內容：對原型進行講述、討論業務流程互動、討論原型變更、進行評審決策；
3.架構評審會
主要是對整個專案的架構進行評審，討論分析架構風險和問題，澄清技術方案和規則；
討論內容：功能模組、架構圖、業務流、資料流、核心演算法和規則、資料表結構、介面說明、部署檢視；
4.ui評審會
主要是對產品ui風格、產品ui介面進行評審決策，產品功能複雜需組織多次ui評審，可按迭代去交付；
討論內容：產品定位、ui風格、ui的介面設計和互動，各相關干係人發表意見，並尊重ui的專業度；
5.用例評審會
主要是對產品的測試用例進行評審，確保測試用例對產品功能的覆蓋是全面而準確的；
討論內容：產品功能模組覆蓋的全面性，測試邏輯的合理性，對產品業務正確的闡釋；
6.**評審會(按需組織)
7.上線評審會
8.每週例會
主要是對多專案並行，非緊急重要專案，採用周例會的形式，進行專案任務、風險和問題的討論，粒度到周；
討論內容：本週完成工作、下週計畫工作、目前的風險和問題、其他討論事項；
三、專案管理工具
1.研發管理工具
(1).專案需求管理；
(2).團隊任務管理；
(3).風險管理(未知)；
(4).問題列表(已知)；
(5).專案缺陷管理；
(6).專案干係人管理；
2.週報
(1).本週完成工作；
(2).下週計畫工作；
(3).目前專案風險；
(4).目前專案問題；
(5).其他事項；
3.進度計畫表(日曆提醒)
(1).任務開展計畫時間(迭代時間段)；
(2).專案的重要里程碑；
(3).計畫節點的日曆提醒；
4.迭代交付功能(使用者故事地圖)
(1).功能交付的時間表；
(2).任務完成時間節點；
(3).提測發布時間節點；
5.功能提測任務單
(1).測試目的；
(2).測試環境；
(3).測試版本；
(4).提測功能；
(5).其他事項；
敏捷落地的會議和工具
對於乙個專案而言，不開會是不能很好達成共識的，統計一下會發現整個專案的會議確實開的不少，但真的有成效的有多少呢？不要為了開會而開會，開會要解決實際問題，開會不是大家無聊的瞎扯，每個人低頭各自玩手機，而沒有任何實質性的共識和決策。低效率的會議 不必要的會議，是浪費大家時間，是增加專案成本，是消耗團隊積...
專案中站立會議和故事牆的那些事兒 敏捷開發
專案組一直在推敏捷開發，但發現乙個關於每日例會的問題。場景 有時大家比較忙時，主持人會乙個個去詢問團隊成員工作狀況。問題 不應該有個主持人，這會導致主持人過於繁忙，而其他人投入度降低 只關注自己的問題 建議每人個人主動去講解自己的工作和計畫，主動，自發和自組織，這才是關鍵 最糟糕的是，主持人挨個詢問...
我們的敏捷之路 回顧會議
我們引入敏捷已經超過2年了，經過長時間的不斷嘗試逐漸摸索出一套適應於我們團隊的方 即計畫會議 看板 每日站會 評審演示 回顧會議。這篇文章將著重介紹我們進行回顧會議的經驗教訓。回顧會議是scrum中最有價值的會議之一，雖然這個會議很重要，但是在實際的工作中我們會發現往往最容易被砍掉的也是這個會議。主...