非常谢您的回答, 这些对我是很大的帮助, 解决我不少对敏捷开发的疑问 因为我必须了解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. -- --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 220.135.237.13