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