本文作者@朱军华Ronzhu 敏捷开发其实不光光要求开发层面和测试层面的敏捷，其实对需求设计层面也是要敏捷的，这样才能配合后续的开发和测试，使之真正的敏捷起来。
我们可以通过在实际操作过程当中在需求层面进行敏捷设计的分析来了解需求的敏捷设计。
大多数情况下需求的处理过程都可以分为需求分析和需求设计两部分，前者要将业务需求转化成产品需求，后者要将产品需求转化为产品设计，也即成品的PRD。
在做需求分析的时候，我们也是接到一部分需求之后，按钮业务优先级来做分析，每次分析肯定是将相互关联的需求放在一起分析，或者是先分析优先级较高的，后分析优先级较低，这个过程将分析的任务进行了划分。
因此其也较为接近于敏捷的模式，这里撇开不谈，主要讲需求设计部分如何与后面的开发、测试结合起来。
在真正开始谈敏捷设计之前，我觉得有必要思考一下是否所有的需求都适合用敏捷设计？ 为什么有这样的疑问，在于敏捷开发其实是较为灵活的，并不是一味的为了敏捷而敏捷，其也可以分成产品敏捷和项目敏捷两种方式。
在我的理解里面，产品敏捷是真正的将敏捷设计、敏捷开发、敏捷测试结合在一起的，从产品的层面讲所有的任务都用敏捷的方式进行管理；而项目敏捷则采用的是需求设计走的是瀑布的模式，开发和测试才是敏捷的，因此两者之间还是有点差异。
有的需求不适合用敏捷的方式的来设计
敏捷的模式总的来讲就是将整体拆为多个个体，然后再单独的完成各个个体以达到这些个体合成之后就是整体的效果，所以这里就有一个问题存在，产品的整体需求是否适合拆分？个人在操作经验中总结如下：
各功能之间较为独立的适合敏捷。一个产品有十个功能点，各个功能点之间相互依赖关系不强的，松耦合，就可以每个功能点单独抽取出来做设计。功能本身的逻辑
遵循某种操作流程的适合敏捷。功能的实现是按照一个较为固定的流程一步一步往下走的，这样可以将每一个步骤单独拆分开。产品上线之后的版本维护适合敏捷。上线之后，对一些BUG、问题、小需求的缝缝补补，都适合用敏捷的方式来设计。上线后的新增需求适合敏捷。上线的的新增需求一般都针对某个功能模块来进行设计，相对来说较为独立，因此也适合敏捷设计。
反之，如果不能满足以上几个条件的，特别是耦合度较高的需求，个人建议还是走瀑布的模式，把整体的需求都梳理清楚之后做整体的需求设计，这样可以避免后面的设计过程要改动前面的设计结果的问题，减少一部分的需求变更.
敏捷虽然说很大的一个优势就在于可以较好的适应需求变化，但这个需求变化是指来自于业务层面的，而不是来自于产品设计人员或者产品经理自身的工作方式所导致产生的。
当然肯定也有人是全部都走敏捷的，这样的话对其产品规划能力要求较高，整体思维逻辑要很清晰，才能避免出错，这里只是个人建议，仅供参考。
敏捷设计的产出如何维护
平常我们称一个功能点为一个CASE或者是一个Story，而在敏捷里面称之为backlog产品条目，其实只是换了个名称而已，实质没有变。
之前我也说过在学习他人长处的时候，重要的是理解和变通，而不是照抄。 产品backlog是敏捷的核心，也是整个产品敏捷过程的起源。从根本上说，它就是一个需求、或故事、或特性等组成的列表，按照重要性的级别进行了排序。
它里面包含的是用户或者业务方想要的东西，并用用户或者业务方可以理解的术语加以描述。通常有如下几个部分：
序号ID
统一标识符，就是个自增长的数字而已，用以唯一标示每个backlog，主要用来做标示用，以及在PRD当中标注每个backlog所对应的需求设计描述；
名称Name
简短的、描述性的backlog标题，比如“查看你自己的交易明细”。它必须要含义明确，这样开发人员、测试人员才能大致明白我们说的是什么东西，其实也方便产品经理自身做checklist检查，可以跟其他backlog区分开。 它一般由2到10个字组成；拆分backlog是有要求的，一般要求每条backlog都能在规定的单个迭代周期里面完成；
重要性Importance
产品经理评出一个数值，指示这个backlog有多重要，一般为1到10之间的整数值，分数越高越重要。 其实就是优先级，只不过有的人所理解的优先级是1最优先，所以这里用重要性来表述。优先级的评定主要参考两个维度，一是业务价值，二是紧迫性，其他的都可以暂不考虑；
工作量估算Initial estimate
团队的初步工作量估算，表示完成该backlog所需的工作量，最小的单位是0.5人/天。为尽量提高估算的准确性，目前个人采用的是整个团队每人都写一个估算工作量，去掉一个最高的，去掉一个最低的，剩下做平均，呵呵。 然后再安排各自讲解一下为什么，最终要在团队内部达成一致；
演示How to demo
大略描述了这个backlog应该如何进行示范，本质就是一个简单的测试规范。一般为“先这样做，然后那样做，就应该得到……的结果”，敏捷对每个backlog的要求就是可演示可单独上线的；
备注Notes
相关信息、解释说明和对其它资料的引用等等，一般都非常简短； 通常都把backlog存放在共享的Excel文档里面，以便团队成员都可以随时查看编辑。一般来说这个文档归产品经理维护，但也并不把其他团队成员排斥在外。开发人员和测试人员常常要打开这个文档，弄清一些事情，或者修改估算值。
这里又会产生一个问题，那就是如何让产品backlog停留在业务层面上？
举例来说，如果产品经理有技术相关的背景，那他就可能添加这样一个backlog：“给Events表添加索引”。真正目的也许是“要提高在后台系统中搜索事件表单的响应速度”。到后面可能会发现索引并不是带来表单速度变慢的瓶颈，也许原因与索引完全不相干。
所以指出如何解决问题的应该是开发团队，产品经理只需要关注业务目标即可。这种面向技术的backlog，可以一直问下去“为什么”，直到发现内在的目的为止.
然后再用真正的目的来改写这个backlog（“提高在后台系统中搜索并生成表单的响应速度”）。最开始的技术描述只会作为一个注解存在（“为事件表添加索引可能会解决这个问题”）。
维护backlog表就是一个对产品需求进行拆分的过程，拆分完成后再根据迭代计划来设计具体的实现，前面所讲的项目敏捷则是将所有需求都设计完成之后才进行拆分，这时主要就是为了把开发任务和测试任务拆分出来了。
相对来说，敏捷还是一种较为新颖的模式，目前在互联网行业用的较多，每个公司在用的时候实际情况可能都不大一样，其实没有关系的，适合自己的就是最好的，只要能提高产品迭代发布的效率，就可以了，先用起来，然后在用的过程当中慢慢优化，发挥敏捷的最大的效用。
作者博客：IT民工