運用Scrum做專案管理真實案例之六
引言:
我會以系列文章的形式跟蹤記錄我現在正在做的一個完整運用Scrum管理專案的筆記,裡面會有一些經驗教訓總結心得,以便讀者與我互相學習勉勵。有寫的不對的或者寫的不好的地方還請海涵,當然我更希望大家多多提寶貴意見,讀者的支持是我最大的動力。(之一,之二,之三,之四,之五,之六)
============================================================================================
這篇將是這個系列文章的最後一篇,主要把我們專案總結會議的一些結論給大家做一個分享:
會議議題
一、如何開好Iteration Planning Meeting迭代計劃會議
1. 會議的目的是什麼
2. 會議的流程是什麼
3. 如何提高會議中的估算效率
二、本專案中的敏捷實踐方法
1. 溝通機制的建立
2. 開發流程的定義
3. 敏捷宣講Training
4. Team所有成員主動性(RD直接參與設計)
5. 測試的早期參與
一、Iteration Planning Meeting
1. 會議目的
ü 全體成員瞭解Story,PO講解本次迭代的所有Story
ü 估算本次迭代的規模
ü 劃定範圍,下一個Iteration我們將要完成什麼
ü 制定本次迭代計劃,產出修正的Sprint Backlog
ü 產出任務看板或者與之相類似的東西(我們用的是Excel看板)
2. 會議流程
2.1 會前準備:
2.1.1 根據Product Backlog挑選出本次迭代會議可能完成的Sprint Backlog列表(可能包括上個Iteration演示後的客戶反饋以及技術改進重構等,列表必須已經按優先順序排序)。
2.1.2 提前把此Sprint Backlog列表發給團隊所有成員,大家事情可以預習,並儘可能對列表中的Story提出問題記錄疑點。
2.1.3 在會議前,還要根據本次計劃會議要討論的Story的個數以及難易度,對每個Story的講解以及評估計劃好時間。以便在會議中主持人可以控制好時間,如果超時可考慮跳過。
2.2 計算本次迭代可以利用的資源時間,根據上次Iteration經驗計算本次Iteration可能完成的SP(Story Point)。
2.3 請PO或者SA按照初步的Sprint Backlog條目順序講解需求,講解完後團隊所有成員與PO或者SA進行Q&A。之後團隊對Story進行評估,估算SP。
2.3.1 Q&A的技巧,我們總結了一下做了一個Q&A checklist如下(一致認為最後三點最為重要):
ü 要做什麼功能?有什麼特殊要求?如效能等
ü 有無UI介面?有特殊操作上的要求嗎?
ü 與系統中其他功能的關係是什麼?
ü 檢出點是什麼,最重要的幾個Test Case
ü 驗收標準是什麼或者說是如何Demo
2.3.2 估算技巧(文章後面單獨列出)
2.4 估算完一條後再進行下一條,直到團隊本次Iteration時間飽和為止。
2.5 大家一起最後再確認一次確定好的Sprint Backlog,並維護任務看板或與之相類似的東西(我們用的是Excel看板)。
2.6 維護看板時,如果有充足的時間最好每個Story都要被分解完Task,團隊一起對Task過一遍看有無異議。
2.7 確認完畢後退出會議。
3. 如何提高會議中的估算效率
PO講解需求,直到可評估即可,細化內容下去和單獨溝通;
只對Story進行SP評估,不評估Task;
PO澄清需求並做Q&A後,利用評估紙牌法做SP評估;
三個六,6分鐘PO講解需求,6分鐘Q&A,30秒內出牌。如果有異議6分鐘PK(並無絕對,總之要控制時間);
二、敏捷實踐
版本釋出順利原因總結,四步驟走:
1. Lock code;
2. 確定範圍;
3. To do list 驗證;
4. 可交付範圍。
具體動作:
1. 釋出前一天:
2. 清楚要釋出的範圍;
3. 自測通過,鎖定程式碼;
4. 準備工作充分,List檢查項,一一檢查,包括安裝手冊、資料庫指令碼、程式包、乾淨環境(虛擬機器)安裝;
5. 釋出當天:
6. Sanity test執行到位;
7. 釋出範圍核實與確認;
---------------------------------------------------------------------------------------------------
最後再次感謝大家,感謝公司,感謝團隊,感謝我的老婆一直以來最我的支援!!!你們的支援是我最大的動力。