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