※ 引述《vipin (Vipin)》之銘言： : 非常謝您的回答, 這些對我是很大的幫助, 解決我不少對敏捷開發的疑問 : 因為我必須瞭解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成果取代 : ------- 大致沒錯。 不過在Sprint Backlog階段會根據現實狀況與權重關係(80/20 Rule之類的)做微調 當然更細部的就是所謂的Task. 然後把結果反饋到之前的Product backlog與Burndown Chart上 另外就是Daily Scrum的要義你沒有在裡面提出來 Daily Scrum只有15分鐘，你完成了什麼，還有什麼有問題還沒做完的需要協助? 基本上在Product/Sprint Plan階段都是Time battle 你可能需要準備一個碼錶跟一份Scrum撲克牌。 相關的開始，強烈建議給你的團隊看過下面的影片 https://www.youtube.com/watch?v=Q5k7a9YEoUI 另外，你自己可能要考慮 http://pragprog.com/book/olag/agile-in-a-flash 這份資料不錯...網路上應該找得到...(笑) --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 114.36.26.48