scrum及需求規格書 - PMP

先回答你第一篇問題

:在以往的流程, 我們會花一個月左右的時間不停地與客戶需求訪談
:並釋出需求規格書, 供使用者畫押確認, 再依使用者規格書分析及設計.

先從一開始問題的角色做考量
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.

--
希望有幫到你的忙
※ 編輯: chadtracy 來自: 118.160.253.230 (01/17 01:39)
※ 編輯: chadtracy 來自: 118.160.253.230 (01/17 01:51)