Re: [問題] scrum及需求規格書

看板P_Management (專案/產品管理)作者vipin (Vipin)時間13年前 (2012/01/16 21:14)推噓0(0推 0噓 0→)

留言0則, 0人參與討論串3/6 (看更多)

scrum屬於敏捷開發(agile)的一種架構敏捷開發不外乎都希望快速的交遞可執行版本書面文件描述得並不多, 希望來板上求教各位依以往經驗, 需求分析及文件絕對會與使用者確認 (與階段款項有關) 且在需求訪談階段的這段时間, 部分的member可能沒事可做(?) 收集的需求在最後又可能被推翻. scrum著重的是時間框的概念, 可以解決一部分的問題將product依story權重分配, 每次sprint結束後釋出一個可執行版本讓專案成員在一開始就能投入工作我的發問在於, 需求訪談會議的結果是不是就成為了Product backlog 而Product backlog不是應當在 Sprint進行之前就須準備好的嗎? 如果說在sprint之前就進行需求訪談會議, 這不就回到waterfall的流程了@@ 我的觀念可能有錯, 誤解scrum的product backlog, 希望前輩能指點一下感謝daimond的回覆 ※ 引述《daimond (哎)》之銘言： : ※ 引述《vipin (Vipin)》之銘言： : : 在以往的流程, 我們會花一個月左右的時間不停地與客戶需求訪談 : : 並釋出需求規格書, 供使用者畫押確認, 再依使用者規格書分析及設計. : : 但若套用了scrum的開發架構, 仍會需要先進行需求訪談會議嗎? : : 還是每一個功能可能會被畫成一個story, 再將story裡建立一個需求訪談及文件的task嗎? : : 看了些文件還是不大明白scrum對於需求規格書的產出作法.. : : 在許多前輩的經驗分享文件中, 似乎沒看過有人列出這樣的task : : 若不需要產出需求規格書, 要如何讓使用者確認最後需求. : : 這樣story若被使用者拒絕驗收, 是否又必須要再重新再走一次(下個sprint)? : : 似乎這樣變成xp的玩法了 @@ : : 請各位前輩指點 : : 謝謝 : 我不懂scrum的東西但就經驗來判斷 : 1. 需求釐清跟書面化確認是一定要作 : 2. story應該是類似工作包拆解確認的另外一種方式如果PM有足夠資源來作 : 各工作包的需求確認我想這是對的也是需要的 : 3. 每一個階段若有文件產出是最好但這又涉及PM有多少資源可以用. 文件 : 會成為組織過程資產. -- -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 220.135.237.13