Open zw334 opened 4 years ago
问:大佬们，作为承接客户定制开发项目的公司，在需求开发过程中有评审的要求。跑敏捷的团队，按照不断的进行需求迭代、增量式开发与交付，如何开展需求评审活动呢？
在新衝刺開始之前進行，但我看不出來問題在哪裡 每個產品開發都會有不斷的需求評審發生 ，你們遇到的問題是什麼呢？
原来的需求评审都是组一个比较有规模的会，客户方的业务部门、信息中心的人员，和开发方的一堆人参加，形成一个评审结论，有一个明确的评审对象是需求规格说明书。
按照迭代开发，每个迭代的需求都需要一次评审
是否就是scrum在迭代中的需求梳理，可以搞成一个迭代的需求评审，但这个参与的范围可能就有局限了，毕竟不能每个迭代拉领导来参与评审？
领导参加评审，解决什么问题？如果是领导提的需求，就需要找领导参加
需求的范围、总体思路都是甲方领导提的。在很多项目中实现完成后的具体业务流程、主要功能也要领导点头了才算完成
那需要邀请领导，包括迭代演示也需要邀请领导
回答你的问题之前，我先问你几个问题。需求评审，这是一次性的还是周期性？评审的内容和范围是什么？都有谁来参加？评审完的结果是什么？
我们原来是一次性的评审。评审的是整个项目的需求。参加人包括客户方的项目发起者、业务代表、信息化主管部门人员，开发方的领导（视项目重要程度，出席的领导层次不同）、项目经理、需求分析人员。评审完的结果就是出一个需求评审结论，表示需求明确清晰，可以按此开展开发工作。但在实际项目中，经常是项目干了一半了，才召开需求评审会。所以我们想改成一个按迭代的模式，但想不明白这种迭代模式下如何来做这种需求的评审。
干一半再召开能说明你们还是能跟甲方扯一扯的。那你们按迭代开评审会有什么阻碍呢？
在做迭代，有计划的讨论，但还没当作评审，但都是自己内部的人，没有用户方。不知道怎么把用户拉进来
既然按照迭代来评审，肯定和原来的需求评审不一样。第一，时间频率不一样，现在是每个迭代一次，你原来是一个项目一次，第二评审的范围不一样，现在一次评审就是评审接下来1~2个迭代的需求，而原来的评审是整个项目的事情。
还没试过怎么拉甲方进来
问:大佬们，作为承接客户定制开发项目的公司，在需求开发过程中有评审的要求。跑敏捷的团队，按照不断的进行需求迭代、增量式开发与交付，如何开展需求评审活动呢？
在新衝刺開始之前進行，但我看不出來問題在哪裡 每個產品開發都會有不斷的需求評審發生 ，你們遇到的問題是什麼呢？
原来的需求评审都是组一个比较有规模的会，客户方的业务部门、信息中心的人员，和开发方的一堆人参加，形成一个评审结论，有一个明确的评审对象是需求规格说明书。
按照迭代开发，每个迭代的需求都需要一次评审
是否就是scrum在迭代中的需求梳理，可以搞成一个迭代的需求评审，但这个参与的范围可能就有局限了，毕竟不能每个迭代拉领导来参与评审？
领导参加评审，解决什么问题？如果是领导提的需求，就需要找领导参加
需求的范围、总体思路都是甲方领导提的。在很多项目中实现完成后的具体业务流程、主要功能也要领导点头了才算完成
那需要邀请领导，包括迭代演示也需要邀请领导
回答你的问题之前，我先问你几个问题。需求评审，这是一次性的还是周期性？评审的内容和范围是什么？都有谁来参加？评审完的结果是什么？
我们原来是一次性的评审。评审的是整个项目的需求。参加人包括客户方的项目发起者、业务代表、信息化主管部门人员，开发方的领导（视项目重要程度，出席的领导层次不同）、项目经理、需求分析人员。评审完的结果就是出一个需求评审结论，表示需求明确清晰，可以按此开展开发工作。但在实际项目中，经常是项目干了一半了，才召开需求评审会。所以我们想改成一个按迭代的模式，但想不明白这种迭代模式下如何来做这种需求的评审。
干一半再召开能说明你们还是能跟甲方扯一扯的。那你们按迭代开评审会有什么阻碍呢？
在做迭代，有计划的讨论，但还没当作评审，但都是自己内部的人，没有用户方。不知道怎么把用户拉进来
既然按照迭代来评审，肯定和原来的需求评审不一样。第一，时间频率不一样，现在是每个迭代一次，你原来是一个项目一次，第二评审的范围不一样，现在一次评审就是评审接下来1~2个迭代的需求，而原来的评审是整个项目的事情。
还没试过怎么拉甲方进来