scrum及需求規格書 - PMP

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有多少資源可以用. 文件
: 會成為組織過程資產.

--

--