如何做好需求管理？敏捷需求管理的重点和方式？我们如何从敏捷管理的角度看待需求？

需求管理真是个磨人的小妖精呐。每一个用心做过需求管理的PO上辈子都是折翼的天使，在接受了需求管理的任务后，他们每天都游走在崩溃和几近崩溃的边缘，经历着炼狱般的反复煎熬。

需求管理为什么如此折磨人，PO又应该如何做好需求管理这件事，需求管理的核心到底是什么。今天的文章将从以下几个方向为你一一揭晓。

1. 我们如何从敏捷管理的角度看待需求？

2. 面对敏捷中的需求我们该如何做准备？

3. 敏捷需求管理的方式是什么？

4. 敏捷需求管理的重点
   

在项目管理中，有个众所周知的三角形，当我们选择瀑布和敏捷两种不同模式时，三角形就是下面这张图的呈现形式：

在瀑布的软件开发模式里面不可变的是范围！

因为在瀑布的软件开发里面先有功能需求说明书，这已经规定好了交付的范围，那么能够变的就只有资源和时间了。

这也是我们会看到瀑布的团队里面经常会加人，会增加时间。

再看敏捷的软件开发模式，不变的是什么？是资源和时间。

因为敏捷团队成员和迭代都是固定的，所以可变的只有范围了。

那么范围是什么，就是我们所说的需求！

如何看待在敏捷管理下的需求呢？

1.不要想一开始就做好全部需求

首先，不同于瀑布一开始就通过功能需求说明书把需求定好了，假设这个项目可能需要一年的时间，按照瀑布的做法，我们在项目开始前的一个月内可能就要确定所有的需求，等同于说在一个月内就要预测到一年以后的事情，这个是很难的，一年会发生什么技术变化，或者市场变化，我们都无法准确得预测到。

所以，在敏捷管理中，我们认为需求是变化的，不会也无法在一开始就做好项目所有的需求规划和细节，因为我们知道后面还会有各种我们无法预测到的情况发生。

2.需求将以涌现的方式出现

在刚开始一个新的项目时，我们总会考虑上一个项目中吃了哪些苦头，有哪些教训，时刻提醒自己，不能在新的项目中继续踩坑。这是我们惯常的做法。

而且，通常这时候，我们就会下一些结论说：我们只要在某方面做得更努力或者更多，结果就会更好。在很多时候，可能真的如我们预料的一样，但这个用在需求的收集上是行不通的。

不管我们在项目的开始阶段工作多长时间或多么努力来确认所有需要的功能，我们总是不能成功，因为总有很多需求只有在产品开发启动以后，才会以用户反馈和开发人员发现的新问题等形式出现。

这些是无法预知的，在软件开发的过程中或是开发结束时才会被发现，所以，我们认为需求就是以这种涌现的方式出现的。

很多重要的项目都会有涌现的需求，而且这些需求涌现出来会引起其他问题，比如，突然涌现的需求让我们很难准确地预测进度。

3.需求的涌现是持续性的过程

需求的涌现，并非一次性的事情，软件开发过程中变数很大，所以需求的涌现也是个持续性的过程。

为什么这样说呢，我们从三个维度考虑：

• 事情会发生变化

在项目的过程中，优先级会发生变化，刚开始我们认为重要的功能可能随着系统向潜在的用户或客户演示，就变得不那么重要了，新的需求会被发现出来，这时候就需要我们重新排列优先级。

• 不需要

美国有位作家说过“写小说就像在夜晚的迷雾中开车，你只能看到前方灯光所及的地方，但是你也能够以这样的方式完成你的旅途”。

软件开发也是一样的，我的前灯不能照亮在我和灯光不能到达的地方之间的所有东西，我刚开始的需求设计也不能全部覆盖到所有未来可能发生的情况。

所以并不需要全部预测，而是让需求就以这样涌现的方式在项目的进程中出现。

• 时间有限

所有的项目都会设有时间限制，往往我们需要的时间比实际更多，所以在一开始就花费同样的精力对待所有的需求是一种浪费。

站在敏捷的角度，从目前的情况来看假设某个功能还不需要马上就去做，可能会放在一个月后，那我们只要简要地描述一下这个功能就够了。

等到后面按照优先级排序终于开始做这个功能时，我们再将这个需求去细化，细化成一个个根据当下的情况而产生的小需求，就是涌现的需求。

需求既然无法一开始就做好全部规划，在项目的进行中，还会一直以涌现的方式呈现出来，那么问题来了，面对这样的需求，我们应该做好什么样的准备呢？

1.从文档到沟通的转变

需求在变化，我们应对需求的方式也可以发生变化，传统的需求功能说明书已然不适合当下，传闻中有个神乎其神的神话：如果你把需求写下来，用户就能得到他们想要的东西。

很明显，在这里不成立，敏捷宣言强调“可工作的软件胜过全面的文档”，敏捷宣言还说“个体和互动高于流程和工具”。

综合这两条，我们看到敏捷宣言强调了个体和互动的价值，也提醒了全面文档的价值是不及可工作的软件的。

Mike Cohn老师对书面文档的弊端总结为以下三点：

• 书面文档会让你暂停做出判断

• 书面文档不能像谈话时那样反复声明要表达的意思

• 书面文档不利于团队责任制

敏捷认为个体互动价值更高，所以在以产品待办列表这样的书面文档形式呈现出需求时，更重要的是增加了PO和团队一起针对产品待办列表的讨论，

大家对于事项的安排有什么意见，产品做成什么样有什么想法，围绕着这张产品待办事项，坐在一起讨论。

所以：少量的/简化的书面文档+沟通>全面的书面文档

2.持续提炼需求的转变

处理涌现需求的第一步就是认识到我们不可能想到每一件事情。

如果能够认识到某些需求只会在我们开发系统的过程中才会涌现，就比较容易接受这样的观点：我们不需要，也不可能，提前就拥有一份已规定好待开发系统的所有细节的完美文档。

事实上，我们最好根据功能要被实现的时间，采用不同精确程度的方式来规定功能需求，而不是从一开始就为了它的完整性苦苦挣扎。

“对需求变化的抱怨就好比对天气的抱怨，你不可能改变大自然的规律，但可以找到方法来应对它，请不要寄希望于雷公电母会不会休息了，我们应该随身带一把伞”。

当需求出现时，持续地去提炼它。

我们了解了在敏捷管理中是如何看待需求的，也知道要做好哪些准备去应对需求，那么，在做敏捷需求管理时，具体采用什么方式呢？

答案是：产品待办事项列表。

产品待办事项列表，就是一张一张贴在我们白板上的便签纸，每一张便签纸上面，都有我们用更易懂更理解的方式呈现出的需求。

这种更易懂更理解的方式就是我们经常会采纳的用户故事。

用户故事通常的表达格式为：作为一个<什么用户角色>, 我想要<完成什么样的活动>, 以便于<实现什么样的价值>。

我们的需求通过这样用户故事的方式呈现在一张一张小卡片上，团队和PO都围着这块贴满小卡片的白板，开始讨论对每一个用户故事的理解。

这种方式相对于传统的瀑布里一张功能需求说明书，你觉得哪个更好呢？

需求管理的形式大概了解了，我们需要再强调一点，是我们在将需求以产品待办列表的方式创建出来时，要符合一个DEEP原则。

详略得当（Detailed Appropriately)团队需要充分理解产品待办列表中计划实现的用户故事，以便他们能够在接下来的Sprint中去完成这些用户故事。

做过估算的（Estimated)产品待办列表不只是一份拟实现工作列表，它还是一个有用的规划工具。即将要处理的，靠前的事项就要做好精确的估算。

涌现的（Emergent)产品待办列表不是固定的一成不变的，它随着时间会发生变化，比如用户故事会增加，移除或者重新排优先级。

排列优先级的（Prioritized)产品待办列表应该按照顶部到底部的每个条目的价值从高到低进行排序。

接下来我们就看看具体是如何来管理我们敏捷中的需求，即如何管理这份产品待办列表。

Mike Cohn老师提出过一个知名的冰山理论。

当我们写好了用户故事，制作好了一个Backlog时，将会发现那些即将要去实现的条目有足够的细节，而那些比较靠后的需求可能就没有那么多细节。

这将导致在Product Backlog中，位置靠前的用户故事会更小并容易理解；而位置靠后的用户故事则更大，理解上也相对粗略。

而那些剩余的规模较大的用户只要给出足够的细节，就马上可以进入优先级更高的位置。以此类推，我们可以看到产品Backlog形成了类似于冰山的形式。

如果能够理解这座冰山所代表的产品待办列表管理方式，你将会在敏捷管理需求的过程中无往而不利！

我们一起来梳理一下，看看冰山管理需求的核心是什么？

冰山理论管理需求的核心：如何将浮出水面的部分做到价值最大化？

隐含的意思是我们如何去操作，以保证我们冰山露出水面的部分对用户来说是价值最大的。

具体的实践过程包括：PO通过筛选梳理产品待办列表选择价值最大的需求，开发团队通过开发产品待办事项而实现用户的价值最大化。

PO梳理产品Backlog使价值最大化

当冰山最顶部的待办事项处理完成后，这时候冰山将会呈现出一个大平台的形状，就是提醒PO要行动了。

PO此刻应该根据开发团队现有的开发成果，衡量一下水面上的待办事项哪些是优先级更高的需求，然后将这部分高优先级的待办事项拆分出合适大小的用户故事；

同时，在PO衡量现有开发成果时，结合当下的市场，干系人的意见，用户的反馈等，权衡哪些需求是可以纳入到接下来的开发工作中（即涌现的需求，也代表着冰山水下面潜藏的需求），而后将这部分需求也整理成产品Backlog，并拆分成合适大小的用户故事。

这两部分拆分的用户故事就会填满冰山的最顶部，填充上之前已完成用户故事撤去后的大平台。

而水面以下的那些更大更模糊的需求，也会在这样循环中从底部升至水面以上直至顶部，当然也有可能被删除或新增。

需求以持续涌现的方式呈现，必然要求PO要持续地提炼需求，所以每次迭代开始前都要重新梳理这座产品待办列表冰山图。

团队实现产品时达到价值最大化

大多数团队成员，认为自己的核心工作就是写代码，给了什么需求就写出来，完事！

很多情况下他们并不真正地清楚客户想要的是什么，或者说他们也并不想去了解客户想要的是什么，他们认为这是PO的工作职责，他们只要负责实现就可以了，这样对吗？

举个例子，当一个三岁的小孩子，家长为了培养他独立，想让他开始做家务，于是把正在玩玩具的他拖过来说，你要先擦好桌子，他迫于想快速完成好交差给妈妈的压力，拿着抹布擦一擦，就要去玩游戏。

如果这个小孩子看到家里还有个小姐姐在擦桌子，擦桌子时妈妈还夸奖小姐姐。他觉得擦桌子是一件很光荣的事情，还能得到妈妈的表扬，于是自己抢着去拿抹布，认真地擦了又擦，擦好了还要拉妈妈过来说，你看我把桌子擦好了。

这两种方式，哪种更好？

在实现每一个需求时，开发团队的成员只有用心地，投入地站在客户的角度考虑问题，才能够将我们开发出来的东西实现产品价值最大化。

小结一下：优先完成用户价值高的事情，开发团队和PO都有责任，不仅PO要把做的事情讲清楚，团队也要明白怎样才能把事情做得更好。

而利用Mike Cohn老师的冰山图处理持续涌现的产品待办列表，确实有助于PO把精力投入到最高用户价值的事情上。

记得：PO的精力有限！所以PO需要的是集中精力将最需要的工作做好，而不是摊大饼，力求每一个需求都细化，最后都做不好。

多花一点精力和时间投入在梳理这块冰山，对我们的工作将会产生事半功倍的效果。

作为Scrum大护法，Mike Cohn老师认为我们应该花费每个迭代10%的精力去梳理产品Backlog，以便为将来的Sprint做准备。这是更加符合当下实际情况的需求管理实践方法。

学习了冰山理论应该关注的重点后，在按照冰山理论来梳理需求前，我们还应该考虑一些因素：

1.哪些需求或者说事项是最有商业影响力的？

2.哪些需求功能对顾客即终端消费者最重要？

3.哪些需求可能在实现后盈利最为突出？

4.哪些需求是最容易实现的？

结合冰山理论，考虑到以上因素时，我们就开始对我们的产品待办列表进行梳理了，即对我们的需求进行管理：

1.保持产品待办事项列表有序，其实就是把要做的事排好优先级顺序；

2.把看起来不再重要的事项移除或者降级；

3.增加或提升涌现出来的或变得更重要的事项；

4.将事项分解成更小的事项，这就是拆分需求；

5.将事项归并为更大的事项，这里要求可以归纳需求；

6.对事项进行估算，看看需求的复杂程度；

第一，在敏捷管理需求时，我们应该以用户价值为中心，而不是一开始就从产品的功能出发。

什么意思呢，你要做一部车，我们并不是按照功能，座椅做好，轮胎做好了，车窗做好了，等等，最后组装在一起。

我们管理需求是以用户价值为中心的意思是，以做出一个能够马上展示的产品为主，我先做一个能够行驶的东西，然后在这个基础上继续完善，能够飞起来，能够跑起来，能够被用户用起来，这是用户价值。

这里要格外强调一点，即便是以用户价值为中心，用户价值仍然会有轻重缓急，有优先级，有次第排序，这对于PO而言是极其重要的。他必须经常与干系人，与用户保持紧密联系，明白如何判断用户价值的优先顺序。

这就引出来另一个要点，不仅是以用户价值为核心，我们拆分需求也是需要满足端到端的交付。

第二，只有拆的需求满足端到端的要求，这个需求才能被验证是否正确。

为什么要这样设置呢？

1，敏捷软件开发有核心的精益理论，减少浪费，先出MVP。因为在精益的理论里，半成品是不产生价值的，我们应该减少库存，尽快出对用户有价值的产出，所以在一个迭代里我们需要创造出一个可以衡量可以交付的东西，交付给用户，这样才会有价值。

2，其实是我们软件开发的特性导致的，如果拆功能，就会把问题后置，而敏捷的逻辑，越困难的就让它越早越频繁的发生。

一开始问题在需求阶段或是在设计阶段被隐藏了，但因为是瀑布开发所以直到最后做出来了在测试阶段才能看到。

而我们Scrum团队，在每一个迭代都交付一个质量内嵌的产品。

通过拆分端到端的需求，就是为了保证在迭代结束时交付一个能够端到端测试的产品，如果有问题，当然是越早发生越好，在每个迭代被及时识别出来。