标签: 敏捷开发

SCrum中如何拥抱需求变更

前些日子,组内开了个技术讨论会,讨论如何在项目中应对需求方面的变化。项目组一直采用敏捷的开发模式,快速开发,快速上线也是百度新产品的追求,但在实施敏捷的过程中,RD,FE,PM,QA如果和谐的组合在一起,“猪和鸡”的需求都不能割舍,这中间的熵值就值得不同的人员合理的去协商解决了。

下面分享组员的一些观点,算是不同经验的RD在项目实施过程中,逐渐积累起来的经验。

1、 如何应对需求变更?

(1) 先不要盲目的拒绝PM提出的大量需求,充分了解PM的想法。经过讨论后再确定需要做哪些内容、不做哪些。

(2) 可能MRD不是很详细,RD应该主动思考,主动提出PM可能以后会提的需求供大家讨论。

(3) 在新产品开始时会遇到很多这种问题。需求的改动需要大家的确认得到认可。

对于小的改动一般会在本阶段来解决,如果改动较大会考虑单独进行处理。

(4) MRD的评审最好能分为小的阶段的来评审,这样效果可能会更好。

(5) 新加的需求可以考虑一下该需求的重要性,放在什么阶段开发更为合适。

(6) 典型的应用:敏捷开发。

2、 怎样保证大家对需求的理解一致?

(1) 以MRD为根本,需要对MRD有比较清楚的了解。

(2) MRD可以考虑把共性的部分抽取出来,MRD不需要写的太细,太多反而不方便查看、理解。

(3) 反复的沟通、有问题把大家组织在一起讨论一下,是大家的对需求的理解更明确、更深刻,然后可以将结果记录到icafe或者oneNote。

(4) 尽量避免点对点沟通、将结果分享给大家了解。

(5) 最好团队能提前制定出一些规范,让大家提前有个意识。目前经验就是按照这种思路做的,可以借鉴一下。

(6) 最好将需求进行分阶段的划分,对需求更容易理解。

3、 怎样帮助产品提出有建设性的建议?

(1) RD需要帮助产品发展、帮助PM决策

(2) 意识的转变,不要只把自身看作是开发人员,对产品有爱。

(3) 多去了解一些业界的动态、多看同类的产品、竞品的情况。

(4) 需要对思考,大局观。如开放知道

(5) 技术实现不是问题。

4、 面对产品分歧时如何说服大家意见达成一致?

(1) 可以用数据说话、更有说服力,RD主动去取得一些数据,不能取得数据时可能需要用一些经验来说明。

(2) 可以提前告知PM可能会面临的风险、收益比

(3) 首先要明确我们做的事情是正确的,从更高的层次去把握

(4) 调研一下其他产品的使用情况,辅助来做一些决策。