从需求规划，需求分析到需求设计的过程，都可以归类为产品的设计过程，这中间现在有很多细分，诸如市场调研、竞品分析、交互设计等，其本质都是都是产品设计，并在最终可以形成一份产出物《产品需求设计说明书》，以提供给开发和测试人员去实现产品。瀑布型开发模式要求需求必须先全部梳理清楚，才会投入开发资源，这样的好处是需求完整，可以从整体上把握产品；而敏捷模式下的产品设计，也需要从整体上规划产品，但会拆分成若干个相互间较为独立的部分，分别实现，最后又能整合成为一个完整的产品，这就对产品设计人员提出了更高的要求。

通常情况下，当我们接到一部分产品的需求之后，会按业务优先级来做分析，并将相互关联的需求放在一起，或者是按优先级高低进行分类，这个过程将需求进行了划分，可以依据这个划分来决定哪些需求是要先做的，哪些是可以后做的。不过这里有一个问题需要注意，那就是什么样的需求适合拆分，一般有以下几种类型：

1、各需求功能之间较为独立的适合拆分。一个产品有十个功能点，各个功能点之间相互依赖关系不强的，松耦合的，就可以每个功能点单独抽取出来做设计；

2、需求功能本身的逻辑遵循某种操作流程的适合拆分。功能的实现是按照一个较为固定的流程一步一步往下走的，这样可以将每一个步骤单独拆分开来设计；

3、产品上线之后的版本维护适合拆分。上线之后，对一些BUG、问题、小需求的缝缝补补，都适合用敏捷的方式来设计；

4、产品上线后的新增需求适合拆分。新增需求一般都针对某个功能模块来进行设计，相对来说较为独立，因此也适合敏捷设计；

拆分后的需求会分别写PRD，最后合成一份。敏捷开发模式中把需求都称为Backlog，维护backlog表就是一个对产品需求进行拆分的过程，拆分完成后再根据迭代计划来设计具体的实现。一般有名称、优先级、工作量估算、描述、备注信息等几个维度，如下实例：

通常都把backlog存放在共享的Excel文档里面，以便团队成员都可以随时查看。一般来说这个文档归产品经理维护，但也并不把其他团队成员排斥在外。开发人员和测试人员常常要查阅这个文档或者修改工作量估算。需要注意的是，描述Backlog的时候只需说明要达到什么结果即可，而不能说如何去达到。

产品的敏捷开发

需求Backlog清单都列出来了之后，开发人员需要根据排定的需求优先级，从需求池当中选出需求排到当前的迭代中，直到所有需求的估算工作量加起来达到迭代周期的工作量为止，一般会留一小部分时间来做为缓冲。开发人员集体估算每个需求的工作量并维护到上述的Backlog列表中，这些都是在敏捷的迭代计划会上完成的。通常一个迭代的开始都是通过计划会议来开始的。

接下来是确定Backlog是否还需要拆分，即判定是否可以在一个迭代内完成，或者是否可以在一天内完成，敏捷开发模式可以建立详细的考核机制，每天都跟踪之前一天的任务是否已经完成。开发人拆分Backlog出来的结果就是一条条的Task，然后开发人员根据各自的任务来编写《产品系统设计说明书》，最后汇总。

这里涉及到工时估算的问题，一般的估算方法都是让团队中不同级别的成员对某个Backlog进行估时，并取某个中间值或者团队都可并接受的值为最终的估算工时。一般拆分的依据如下：

1、  每个拆分出来的Task都是可单独验证并上线的；

2、  每个拆分出来的Task都是可以在单个迭代内完成的；

每日站会可以跟踪需求实现的进度，检查每天的工作进展是否按照迭代计划在进行，永远确保资源投入在高优先级的Backlog上；该完成而未完成的任务有哪些以及是什么原因？及时识别出对迭代中后续问题的影响，并根据风险和应急方案努力规避；遇到的问题应该由谁来负责解决以及何时必须解决，否则会影响后续计划中哪些条目？尤其是那些有前后依赖关系的条目；开发过程中会出现对原有需求的进一步细化，可能会和迭代计划时讨论的结论有一些差异，那么变更的内容是否会对既定的业务需求产生调整？

需求变更一般发生在计划会议之后，既定的Backlog尽可能保持稳定；但是需求变更是很难避免的，若业务或者技术发生变化时，敏捷团队该如何响应呢？一般从需求的紧急程度来考虑，紧急的需要团队内部开发讨论，如果能在缓冲时间内完成的就完成掉，如果不能则需要从已安排的任务当中挪出一部分到下个迭代。

产品的敏捷测试

有人说敏捷测试是顺应敏捷开发方法，是力求达到质量和效率平衡的一系列的测试实践，其实并一定要敏捷开发了才敏捷测试，其他开发模式下也可以采用敏捷测试。敏捷测试只是测试的一种，强调从用户的角度，即从使用系统的用户的角度来测试系统。重点关注持续迭代的测试新开发的功能，而不再强调传统测试过程中严格的测试阶段。

所以在敏捷开发模式下，开发人员不是等整个迭代的任务都开发完了才送测，而是做完一个送测一个。前面也讲到Backlog拆解成Task时要求每个Task都是可以单独验证的，也就是说每个Task都是可以单独测试的，这样测试人员可以对每个已开发完成的Task进行测试，及时发现问题，及时改进。这种模式下，效率高的话可以精确控制到每天的开发结果验证，这样可以确保产品需求都是按照计划来进行的，并且不会偏离需求本身。

测试人员也是从迭代计划会议开始参与到每个迭代当中，对本次迭代中安排的所有需求清单编写测试用例，最后形成一份汇总后的《测试用例及测试报告》。在每天的站会上，测试人员可以及时告知每天的测试进展和测试的问题，及时帮助开发人员修正。这样测试人员就可以持续测试、持续反馈，整个测试的阶段性会比较模糊，主要强调测试的速度和适应性。

敏捷测试要求测试人员去扮演“用户”的角色，确保产品满足既定的需求；强调直接的沟通、协作以及团队责任，不太关注对缺陷的记录与跟踪；需要建立起有效的自动化测试方法，对老模块的功能用自动化测试，新模块用手工测试结合的方法。

从以上的内容可以看出，一个好的高效的迭代计划会议非常重要，可以将需求拆分成可在一个迭代内实现的几个部分，再加上每日站会的过程跟踪，发现问题及时解决，最后通过敏捷测试及时验证已开发完成的任务，这样的过程基本可以保证每个需求的实现都是按照原先的需求规划来的。

敏捷开发模式下也并不是没有文档的要求，设计、开发、测试这样的过程下来，会有《产品需求设计说明书》、《产品系统设计说明书》、《测试用例及测试报告》三份文档，而且文档也是走敏捷的模式，每个迭代更新其中的一部分，最后合成在一起，这样的方式有过程也有记录，敏捷开发照样重视文档的作用，也重视文档的维护，只不过比较强调宜少且精炼。

敏捷开发是否深入到团队中，一般是根据团队呈现出来的工作氛围、项目运作状态、团队成员的感性认识等方面来评估团队和其开发过程的敏捷成熟度。团队有共同的愿景，并且对这个愿景充满信心的；有明确的阶段目标并且为每个成员所知晓；知道当前计划：做什么、何时完成、预期效果等；所有任务是低耦合的，团队之间紧密协作。

采用敏捷开发模式，一定要把敏捷设计、敏捷开发、敏捷测试连在一起，这样才能最大限度的发挥敏捷的效用。

来源：《网络传播》2013年第8期，作者：朱军华