敏捷开发模式中如何需求规划

敏捷开发模式中如何需求规划

摘要： (2)

一、敏捷开发模式中的需求规划 (2)

1.1需求收集 (2)

1.2需求记录 (3)

1.3需求优先级 (4)

1.4需求变更 (5)

二、敏捷开发模式中的需求实现 (5)

2.1计划会议如何分解Backlog (5)

2.2每日站会确保需求实现的进度 (7)

2.3敏捷测试保证需求实现的准确率 (8)

三、分析复杂需求 (9)

四、结论 (9)

摘要：敏捷开发对需求规划的要求是很高的，首先需求是打散的，一个大的项目需求会拆分成很多小的功能完整的需求，以便排定优先级去逐个实现；其次打散的需求全部实现之后，组合起来的要是一个整体，而不是散碎的个体，这样就要求需求规划非常完整，需求拆分非常精确。所以个人感觉敏捷开发提升了开发效率，但是对需求规划的要求更高了。如果是产品经理来担当PO的话，就是对产品经理的需求规划能力提出了更高的要求，必须有清晰的思路，很强的需求规划能力才行，这样才能保证敏捷开发可以按照既定的设想去一步一步实现产品的设计。

很多人认为既然敏捷开发了，那就应该不用写文档了，其实不然，最基本的PRD 还是要有的，哪怕是本来要一口气写一份完整的PRD，采用敏捷开发之后，拆分成好几个部分去写，最后才合在一起。PRD除了讲解需求的作用，还是产品历史功能追溯、记录的作用，用来保证需求设计、开发实现、测试验证的过程是在同一个基准的理解基础上的，避免出现各自的想法不一致导致的产品形态走样。要保证整个产品的过程流畅的走下去，首先就得保证需求规划的过程是完备且正确的。

一、敏捷开发模式中的需求规划

1.1需求收集

敏捷开发模式下照样有需求收集的过程，不然开发个什么劲呢，不管是产品经理自己的想法，还是用户的需求，总有一个收集验证的过程。那么如何进行需求收集呢？除了老三样的问卷调查、意见反馈、竞品分析外，还可以有数据分析、同事反馈、用户观察等。

意见反馈：现在做任何互联网的产品，一般都会在产品上预留一个给用户反馈使用意见的口子，这就是我们经常在各个产品中见到的“意见反馈”链接页面或者是按钮弹窗，用以收集用户在使用过程当中反馈过来的信息，进而把这些信息收拢起来做统一分析，以得出相应的分析结果，看是否可以转换为产品需求。具体的处理过程可以参见意见反馈—小功能大设计。

问卷调查其实也是用户反馈中的一种，用以对特定人群或者不限人群投放预先设计好的问卷调查内容，适当加以鼓励填写的措施，以收集到一定数量的用户填写信息。

竞品分析应该是最常用的一种方式，这种方式最为直观，可以直接找到相类似的产品进行使用，然后分析其功能点和特性，找出优缺点。这种方式最常见，所以也经常造成功能上先类似的产品之间长的都差不多，也就是大家都说的“天下文章一大抄”，加引号的哈，我们还是有创新的，呵呵。

数据分析的方式是比较适合敏捷开发的，原因在其分析的结果可以快速的反应在开发结果上，以观察实际更改后的效果，比如一个购物流程，发现用户老是停留在购物车页面，就是无法转换成有效订单，这个结论一出来，我们就可以去分析购物车页面是否哪里体验做的不够好，导致用户提交订单的比率下降，分析的结果可以马上进行开发改进。

用户观察是要坐到用户旁边去观察用户使用产品的操作过程，不做任何限定，让用户以自己的方式随意使用产品，观察整个使用过程，适当的还可以进行一些提问。这种方式成本比较高，比较适合观察公司内部用户，或者是在用户的电脑上安装录屏软件，以达到事后观察的效果。

同事反馈只能小范围使用，其实就是内部PK，三个臭皮匠顶个诸葛亮，一群产品经理的智慧是比较可怕的，自己设计的产品要勇于拿出去分享，在PD内部做头脑风暴，有时候会有意想不到的效果。

此外还有微博搜索、博客搜索等信息收集的渠道，不再一一阐述。

1.2需求记录

把搜集回来的需求做一定的分析之后得出的结论就是我们要记录的需求条目，也就是可以排到敏捷开发计划里面去实现的需求列表。一般我们记录某个需求条目的时候都会考虑到用户场景，以一个故事的形式表述出来。

用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：

1.角色：谁要使用这个功能。

2. 活动：需要完成什么样的功能。

3. 商业价值：为什么需要这个功能，这个功能带来什么样的价值。

用户故事通常按照如下的格式来表达：作为一个<角色>, 我想要<活动>, 以便于<商业价值>。举例：

作为一个“网站管理员”，我想要“统计每天有多少人访问了我的网站”，以便于“我的赞助商了解我的网站会给他们带来什么收益。”