根據(jù)發(fā)布目標分析需求把需求分析成獨立故事初步分析可以是粗略隨著需求不斷深入刻意對故事進行整合或者切割
要注意是分析出來需求盡量在發(fā)布目標范圍的內超出發(fā)布目標需求應該盡量避免過深分析
所謂發(fā)布目標是確定了這個版本可以讓用戶滿意條件
故事模式:做為(用戶角色)我可以(做什么)以便(業(yè)務價值)后面業(yè)務價值在比較簡單或者大家都比較明確時候刻意不需要注明
當前團隊(Team)實戰(zhàn)推行思路方法:
第階段這個分析工作開始由PM進行收集、整理和分析
第 2階段當大家都為用戶故事方式接受以后采用需求討論方式來明確和分析用戶故事
2、對分析故事進行相對估計估計出來故事點是對用戶故事和復雜度無單位估計值使用數(shù)值大小本身沒有絕對意義只有相對于其他故事規(guī)模相對意義
比如用戶登錄這個用戶故事估計值是2那么做為同等開發(fā)規(guī)模用戶推出這個用戶故事估計只也應該是2
當前團隊(Team)實戰(zhàn)推行思路方法:
第階段這個估計工作暫時由PM來負責完成但是由于個人估計肯定會有偏差所以在估計完成的后需要進行調查來進行修正
第 2階段用估計撲克會議來統(tǒng)對用戶故事進行估計當主持人拿出個新用戶故事的后大家給出自己對這個故事使用撲克打分然后取出平均值對差異較大估計值要給出解釋來消除對用戶故事理解估計撲克會議實戰(zhàn)不超過１個小時
3、準備產品調查對用戶故事進行功能存在和功能缺失性產品調查然后根據(jù)調查結果對用戶故事進行劃分劃分成3類:基本需求線性需求非線性需求
此外還有反對需求、存在疑問需求、無所謂需求3種類型需求這些需求將根據(jù)進步發(fā)展進行確認
當前團隊(Team)實戰(zhàn)推行辦法:
第階段由PM發(fā)出調查問卷在參和到項目開發(fā)團隊(Team)、測試團隊(Team)、技術支持團隊(Team)來進行調查然后匯總答案根據(jù)存在問題和缺失問題答案對用戶故事進行定性
第 2階段由PM發(fā)出調查問卷擴展到相關用戶群體中進行調查然后匯總答案根據(jù)存在問題和缺失問題答案對用戶故事進行定性
4、確定發(fā)布規(guī)劃首先要確定是迭代周期長度以周為單位然后估計出每個迭代周期團隊(Team)速度然后可以從用戶故事池中選擇出合適用戶故事來填充到第次和第 2次迭代周期中其余暫時可以先不用填充隨著每次迭代周期完成來對發(fā)布計劃進行更新最后根據(jù)估計速度和需要開發(fā)故事來確定需要幾個迭代周期并最終有幾個迭代周期來確定需要開發(fā)時間周期發(fā)布計劃可以以功能來驅動進行也可以以日期來驅動進行 [Page]
發(fā)布規(guī)劃特點以月做為時間范圍規(guī)劃對象是用戶故事估計單位是故事點
當前團隊(Team)實戰(zhàn)推行辦法:
第階段使用1周做為迭代周期開始時團隊(Team)速度使用估計方式做出簡單估計根據(jù)每個周期結束后團隊(Team)速度再進行發(fā)布計劃調成迭代周期內用戶故事完成暫時以開發(fā)完成做為標準
第 2階段使用2周做為迭代周期可以使用原有歷史速度做為團隊(Team)速度多出周時間做為測試修復時間迭代周期內用戶故事完成以測試完成完整功能提交做為標準并在開發(fā)過程中熟練使用單元測試來進行確保功能完整完成
5、確定迭代規(guī)劃根據(jù)填充到迭代周期內用戶故事來分解成工作任務工作任務包括設計工作區(qū)別層次開發(fā)工作調試工作和測試工作等等具體任務然后對任務進行估計這時候估計單位以理想工作小時做為單位比如設計需要兩個人小時開發(fā)持久層需要1個人小時調試持久層需要半個人小時開發(fā)業(yè)務層需要2個人小時調試中間層需要1個小時等
然后根據(jù)每個故事人小時和這個迭代周期內參和人數(shù)以及每個人所能參和實際有效時間(注意有效時間約為每天6小時需要考慮到會議討論頭腦休息等非理想工作時間)來判斷這個迭代周期填充是否足夠如果不夠則再加入個用戶故事如果超出則移出個用戶故事到下個迭代周期中
迭代規(guī)劃特點以周做為時間范圍規(guī)劃對象是工作任務估計單位是理想小時
當前團隊(Team)實戰(zhàn)推行辦法:
第階段使用速度驅動思路方法來進行迭代規(guī)劃即確定了本次迭代速度然后選擇用戶故事擴展成任務對任務進行估計
第 2階段使用承諾驅動思路方法來進行迭代規(guī)劃即提出個故事把故事擴展成任務對任務進行估計讓小組承諾是否可以完成這個故事如果可以在迭代周期內完成則加入這個故事如果不能完成則推遲到下個迭代走起
6、迭代開始在迭代開始時召開迭代啟動會分配迭代周期內用戶故事和工作任務到個人每個工作任務必須精確到個人同個用戶故事區(qū)別工作任務可以根據(jù)情況適當分配給區(qū)別人來完成
當前團隊(Team)實戰(zhàn)推行辦法:
第階段任務分配給個人通常個故事任務分配給同個人
第 2階段任務分配給結對通常個故事任務分配給同個結對 [Page]
7、迭代進行每日早對昨日完成工作任務和問題進行匯報并且同時計劃今天需要完成工作任務對于迭代過程中進度和問題進行及時觀察和調整要求每個人完成某個任務的后要及時告知整個小組知道(qq群方式最為快捷)
當前團隊(Team)實戰(zhàn)推行辦法:
第階段由PM及時地對當日工作進行詢問并負責把遇到問題跑出來進行解決
第 2階段小組成員主動地對已經完成任務進行匯報并及時把自己遇到問題拋出來
8、迭代結束確認本次迭代完成用戶故事對于完成部分用戶故事計算到下次迭代中并對本次迭代過程資產進行整理總結形成FAQ方式文檔進行規(guī)整
同時根據(jù)新需求情況資源情況已完成功能回饋以及開發(fā)中遭遇不確定性問題對發(fā)布規(guī)劃和迭代規(guī)劃作出調整
當前團隊(Team)實戰(zhàn)推行辦法:
第階段使用學習網站WebSite或者博客等方式對經驗進行記錄
第 2階段使用完善skills對經驗進行記錄可以方便組織成培訓文檔并方便進行搜索查找
9、迭代測試為了保證用戶功能完整提交每個用戶故事開發(fā)完成的后都要對該用戶故事進行測試然后在針對開發(fā)中出現(xiàn)問題進行修復以便完整完成個用戶故事
第階段:測試迭代周期和開發(fā)迭代周期分開
每次迭代開始階段由PM告知開發(fā)組需要開發(fā)和修復用戶故事同時告知測試組本次迭代需要測試故事需要準備故事需要復測故事
并在分配任務時把修復故事工作規(guī)劃到本次迭代中來
每次開發(fā)完成用戶故事點算作本次迭代速度
迭代1 迭代2 迭代3 迭代4 迭代5
測試 準備故事12 測試故事12
準備故事34 測試故事34
準備故事56 復測故事12
測試故事56
準備故事78 復測故事34
測試故事78
準備故事910
開發(fā) 開發(fā)故事12 開發(fā)故事34 修復故事12
開發(fā)故事56 修復故事34
開發(fā)故事78 修復故事56
開發(fā)故事910
第 2階段:測試迭代周期和開發(fā)迭代周期合并
每次迭代開始階段由PM告知開發(fā)組需要開發(fā)故事同時這些故事也是測試組需要準備測試故事要求這些故事分解工作任務中要包括測試工作和修復工作
每次測試完成用戶故事點算作本次迭代速度
迭代X
測試 準備故事1234 測試故事1234 復測故事1234
開發(fā) 開發(fā)故事1234 修復故事1234 完成故事1234
十、發(fā)布結束對本次發(fā)布中完成用戶故事進行會議整理總結:
1 確定最終完成用戶故事以及花費迭代周期
2 通過計算得到個團隊(Team)人平均速度這個速度做為下次發(fā)布規(guī)劃參考
3 分析哪些用戶故事估計出現(xiàn)了失誤以及出現(xiàn)失誤原因是什么
4 最初發(fā)布版本在市場上有了初步反饋信息的后可以延長1個迭代周期用來做為發(fā)布版本反饋收尾
文章來源：中國項目管理資源網
|
Leadge.com首頁 > 知識庫 
