实践和理论需要同步，本文作者记录了自己的敏捷开发流程，与大家分享。
需求的收集
首先对于不同的公司，大家对于需求的管理和搜集都是不一样的，是什么原因造成了这种百花齐放的原因，主要因为在需求收集和整理时会需要花费大量的时间和精力,来甄别。而对于处于不同规模、阶段、行业的公司，它们所能耗费的成本（人力、时间、资源）都是不同的。自然大家对于如何搜集需求，如何整理需求，如何输出需求都不相同。但最后都想达到需求明确的结果。
收集需求的方式有但是大致可分为几类：
问卷调查——通过制定详细周密的问卷，要求被调查者据此进行回答以收集资料的方法。
用户访谈——通过线上，线下的方式进行一对一单独对话访谈。
竞品分析——通过观察直接或间接竞争对手，得出自己或竞品的优劣。
内部搜集——通过个人（用户模拟）或他人获取“直接”需求。
第三方——通过第三方资讯/报告/白皮书/数据分析等手段了解当前需求。
等等
需求整理
然而收集需求的方法处理这列举出来的之外，还有更多的我们并不知道的方法。但是他们终究是为了达到“搜集需求”而已。在我们搜集了足够的需求之后，就到了需要我们记录下来的时候了，至于如何记录，这里和前面一样。
对于需求记录，每个人都有着自己常用的记录方式，比如有喜欢用看板类teambition、trello、leangoo，等软件的。而我这里的话，我十分推崇使用Excel来记录我的需求。
推崇使用Excle主要是原因有几个原因有很多：
首先就是普及率高。在这个互联网时代，只要不是太过于困难的偏远地区，我们在读书时都或多或少接触过Office三件套。就算没有接触过，大家也可以在短时间能上手使用。
其次就是装配率高，除纯净版的系统，基本所有的系统都会携带office三件套，就算没有携带，我们也可以轻而易举的从网上下载来使用。
其他的如功能强大之类话题我就不在过多阐述，因为在日常使用中我们也只用那固定的几个小功能而已，并不需要过多的了解太多的“高级”技巧。
创建功能需求表之前，我会先浏览用户Story，做到场景还原化，之后再根据记录的用户Story来进行功能拆解。
首先说明，这种拆解不是盲目的拆解，是需要根据一定规则进行拆解的。不同的人或许有不同的拆解方式，而我遵循的是从上到下的拆解规则。
我将他们分为 系统，模块，功能，内容，备注：
系统：明确story拆分出来的功能是属于那个需求或者是那个端的。
模块：这里期有两种划分思维：将有共通性的功能划分到一起、将在同一页面的功能划分到一起。
备注：对于一些有歧义或需要特别说明功能进行补充说明。
这样拆分有助于我梳理整体架构。
在分解的过程中，我们还需要注意功能的准确性，因为这个功能始终是围绕着用户Story来的，是为了解决用户故事中用户的需求而存在的，不能让功能偏离了用户Story的出发点，偏离后会出现几种情况，一个是偏离后做出来的功能牛头不对马嘴，无法满足用户。
另外一种是功能给用户造成损失，最终都会造成用户流失。所有在拆分完后，我们需要多次的复查这些功能，以保证这个功能点基本满足用户需求。
复查后就是我们的下一步操作分优先级（优先级我将放入原型后，禅道驱动中来讲解），随后就是原型绘制。
最后根据上面来进行操作，我们得到了功能需求表。但是得到了功能需求表，并不能代表我们的这个阶段的工作完成了 ，我们可以直接推进到下个工作环节当中。
反而这个时候我们还需要反复的拿着用户Story与功能需求表进行对比，除了反复对比之后，我们还需要拿着功能需求表和用户Story，与需求者进行需求校对，校队是否真正的满足了用户需求，在校对过程中我并不推荐将功能需求表直接交予对方进行直接进行校对，因为这种方式会适得其反，会直接出现对方看不懂，或者是看之后，他突然说我还有个IDEA。
所有我们需要使用交谈的方式进行试探用户。最后基本确定后，我们这个阶段的工作就可以暂时告一段落，进入下个环节单中。
备注：当遇见一些功能复杂的业务或需求时（常见于0到1）我们可以适当的将模块进行再次拆分，拆分成模块，子模块以便更好的进行维护功能需求表
Tips：在创建过程中明确了《范围层》
