scrum及需求規格書 - PMP

非常謝您的回答, 這些對我是很大的幫助, 解決我不少對敏捷開發的疑問
因為我必須瞭解scrum與傳統開發的每個作業上的對應關係, 才好讓我在團隊裡試行.


------
Product Backlog相當於客戶對系統的需求,或是業務/協銷對客戶提出的產品功能保證
在專案kickoff時, 會對這些需求/功能作使用者需求分析, 並產出每個需求裡的story..
最後會依據這些story的優先順序及花費時間, 去排入sprint backlog

Product Backlog 裡的描述屬於概略的
Sprint Backlog 裡的需求描述屬於較完整的
假設這個scrum被分出了5個sprints, 這五個sprints的story皆是在需求會議中所收集的.
真正的設計分析, 皆是在每個sprint開始才進行(task)...

而以往在各階段的驗收文件(functional spec., design spec.)
可能僅出functional spec, 而design spec則以各sprint成果取代
-------

虛線中的描述有問題嗎? 幫忙再解惑^^"


※ 引述《chadtracy (無名)》之銘言：
: 先回答你第一篇問題
: :在以往的流程, 我們會花一個月左右的時間不停地與客戶需求訪談
: :並釋出需求規格書, 供使用者畫押確認, 再依使用者規格書分析及設計.
: 先從一開始問題的角色做考量
: Scrum本身是極為重視使用者互動的一種開發流程
: 與傳統的PMP不同的是，PMP的架構為Waterfall式的傳統專案流程模式
: Scrum/Agile走的是Concurrent甚至Overlap、平行處理流程的專案開發模式
: 一開始會議的角色可能有下列幾個
: Product Owner, Scrum Master, Team Member
: 確認客戶的需求裡面，基本上會邀請Product Owner加入會議
: 在與客戶談案子的時候會將團隊裡面針對專案的理解與功能開發加以排序
: 並針對每一個排序出來的功能初步寫下推估的時間值
: 這就是你所說的Product Backlog
: 裡面必須包含的:根據所謂的客戶狀況寫下來的Product Feature,估計值，跟優先次序。
: 這是所謂的大項目，Break Down下來就是所謂的Sprint Backlog
: 或許有PMP會認為這就是WBS，但精神是完全不一樣的。
: Sprint Backlog是把工作除了細分外，另外也將每個細部部分加上所謂的User Story
: 資深的團隊成員在讀完整個Feature Requirement跟必須完成的先後工序之後
: 由專案的各個成員一致推估出所需要的時間，這也算是一種專家決策方式吧。
: 然後將所需的估計值在重新謄寫上去。
: 最後集合出來的時間就是Sprint所需要的時間，並彙整出整個專案所需的Burn Down Chart
: :但若套用了scrum的開發架構, 仍會需要先進行需求訪談會議嗎?
: 有可能，Scrum本身的精神是強調使用者可以隨時介入並更改需求。
: :還是每一個功能可能會被畫成一個story, 再將story裡建立一個需求訪談及文件的task嗎?
: :看了些文件還是不大明白scrum對於需求規格書的產出作法..
: :在許多前輩的經驗分享文件中, 似乎沒看過有人列出這樣的task
: :若不需要產出需求規格書, 要如何讓使用者確認最後需求.
: :這樣story若被使用者拒絕驗收, 是否又必須要再重新再走一次(下個sprint)?
: 應該講，在精神上Scrum是允許使用者三心二意的
: 但在執行面上，做為一個Scrum Master必須隨時確認你團隊的工作狀況
: 另一方面隨時確認客戶或是使用者的要求，以期可以達到使命必達。
: 所以在開發的流程中，Burn Down Chart有可能是越長越高的。
: :似乎這樣變成xp的玩法了 @@
: 這段你就答對了，Scrum不是解藥，他是藥引子。
: ※ 引述《vipin (Vipin)》之銘言：
: : scrum屬於敏捷開發(agile)的一種架構
: : 敏捷開發不外乎都希望快速的交遞可執行版本
: : 書面文件描述得並不多, 希望來板上求教各位
: : 依以往經驗, 需求分析及文件絕對會與使用者確認 (與階段款項有關)
: : 且在需求訪談階段的這段时間, 部分的member可能沒事可做(?)
: 書多到滿坑滿谷啊?
: 開課的也很多，有機會可以去聽聽。
: 怎麼可能沒事情可以做?
: 客戶的時間是錢，你的不是錢嗎?
: 在開會的時候基本上都是Time Battle
: 一邊在客戶訪談，FAE就一邊在寫計畫了，另一邊還要準備Simulation或是相關的數據搶單
: : 收集的需求在最後又可能被推翻.
: : scrum著重的是時間框的概念, 可以解決一部分的問題
: : 將product依story權重分配, 每次sprint結束後釋出一個可執行版本
: : 讓專案成員在一開始就能投入工作
: 專案成員並沒有在時間上有所浪費，一開始的會議就是由PO,Scrum Master,Team Member
: 所組成的，基本上你可以把PO看成是PM或是客戶，原則上還是希望這個PO是客戶。
: : 我的發問在於, 需求訪談會議的結果是不是就成為了Product backlog
: : 而Product backlog不是應當在 Sprint進行之前就須準備好的嗎?
: : 如果說在sprint之前就進行需求訪談會議, 這不就回到waterfall的流程了@@
: 你抓到了一個重點，但我之前也有提過，客戶隨時可能三心二意
: 所以這個架構的論點在於，專案團隊可以隨時因為客戶的需求而在中途再評估
: 決定Sprint中間的Scope甚至可以在於客戶討論之後把Task砍掉，或是丟到下個Sprint去
: 基本上在Waterfall的架構下，你是沒有辦法這樣Interupt處理
: 而所謂的Scrum你就可以把他當成在做打帶跑的案子
: 你今天可能有人的Task是因為工作A而延伸出來A+這個Task,而有人需要再去研究這個功能
: 並提出另外的開發方案加進這個案子裡
: 也有可能你今天在Product Backlog都沒有完成的狀況下，你只有一個Kick Off Day就開始
: 根據不完全的使用者需求去寫User Story跟相關的Sprint Planing.
: Scrum就是打帶跑.
: 講難聽一點，有時候客戶要什麼他自己都不知道
: Scrum強調溝通的特性除了會讓案子更容易趨近客戶需求外
: 還有讓整個專案執行更為合理化，而不是做到後來大家覺得自己不知為何而戰。
: : 我的觀念可能有錯, 誤解scrum的product backlog, 希望前輩能指點一下
: 最後你可能會覺得如果放任PO任意的漫天喊價工作會做不完對不對?
: 是啊，所以有兩個部分需要注意，傳統的專案鐵三角是Scope,Time,Cost是不是
: 傳統的法則是由Scope去Drive Time跟Cost.
: 最後因為溝通不良，案子變成拖屎連，怎麼做都沒辦法點收。
: Agile的精神是Time跟Cost去Drive Scope
: 你今天哪時候要，要花多少錢，來決定你能做出來的成果
: 這是比較合理，而且你看得到最接近客戶需求的方法。
: 最後還是要把Agile Thinking的四大精神在寫一次
: Individuals and interactions over process and tools
: Working software over comprehensive documentation.
: Customer collaboration over contract negotiation
: Responding to change over following a plan.

--

--