敏捷落地的會議和工具

2021-09-22 09:55:31 字數 2309 閱讀 3598

對於乙個專案而言,不開會是不能很好達成共識的,統計一下會發現整個專案的會議確實開的不少,但真的有成效的有多少呢?不要為了開會而開會,開會要解決實際問題,開會不是大家無聊的瞎扯,每個人低頭各自玩手機,而沒有任何實質性的共識和決策。

低效率的會議、不必要的會議,是浪費大家時間,是增加專案成本,是消耗團隊積極性,是培養團隊惰性,公司的氛圍和文化也會逐步惡性改變。所以,需要反思下哪些會議是真正需要積極去組織的,哪些是對專案開展無益需要去掉的,哪些是需要選擇性組織召開的,讓會議變得更加高效而有成效。

專案管理有其適應性,針對不同的企業、不同的團隊、不同的業務、不同的行業、不同的外界環境,需要裁剪選擇適合其良好運作的方式方法,保障高效的協同為專案目標達成而服務。

一、專案流程會議

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中最有價值的會議之一,雖然這個會議很重要,但是在實際的工作中我們會發現往往最容易被砍掉的也是這個會議。主...