2016年11月开始了休长假回来后的第一个项目。也是我职业生涯中的第一个敏捷项目。本人在项目中担任需求分析。 项目启动已经五个多月，目前一切运行乐观。闲来觉得有必要总结下人生中第一个敏捷项目，于它人可以取良去莠， 于自己可以沉淀一二。

回想一下之前做过的项目都是用瀑布+迭代。 需求收集用瀑布。即尽量在需求收集时期定义到所有需求的所有细节，产出产品需求说明书。开发阶段采用迭代。即把需求划分为多个模块，分Sprint 开发。所以不同之处主要在于需求收集和需求管理，其次是才是开发，再次是测试。下文将在需求，开发和测试三个方面总结。

需求方面

在这个敏捷项目里，我们弃用了之前公司项目一直在用的产品需求说明书。直接用一个个用户故事来呈现功能需求。 这点到是为我省了很多事。 之前我们产出需求文档的过程如下：

1. 和客户沟通，产出功能点列表。(这个列表一般在销售阶段会由销售团队完成，用来做项目估算。后期需求细化也是以这个列表作为基准。)

2. 根据功能列表沟通详细需求。期间产出用户界面，多个产品功能需求规格书。

3. 将功能需求规格书拆分成便于开发任务分派的用户故事。

现在，需求收集阶段直接产出一个一个相对独立的用户故事就省去了绞净脑汁分割需求的过程。尤其当需求规格说明书章节没分配好，各个章节相互牵连重复时，分割需求的过程就会尤其痛苦。尽管如此，在项目开始前期，团队对用用户故事管理需求上有很大的争议。对用户故事管理需求提出的问题、最终讨论出的解决方案及实际操作后的效果如下：

问题一：

一个个用户故事太散。 新人没有系统的需求文档学习系统的需求 (话说实际情况也没哪个新人进项目后会系统的学习需求。都是只看自己负责那部分) 需求查阅也不方便。比如想起来要查阅某个需求点，在用户故事的茫茫大海里怎么找？

解决方案：

用记故事地图。 绘制一个用户故事地图大概相当于需求文档的章节索引。找某个需求点或想系统学习需求时可以从用户地图里找。

实际效果及问题总结：

用户故事地图得将用户故事分类总结好才能真正起到地图的作用。比如，如果你想确认购物车页面能否修改选购产品，但是从地图里完全看不出来这个功能点分布在哪个用户故事里。那这样的地图就是失败的。这次项目需求范围比较窄，只有browsing 和Search. 所以做出来的用户故事地图对分类水平要求不高。个人认为对用户故事分类难点在于要想清楚是按功能点按功能模块分，还是按页面分。比如B2B用户注册过程中会要求搜索公司以便将个人用户关联到某个公司. 如果按功能模块，搜索公司这个功能点应该属于搜索模块，如果按页面，那就应该属于注册页面。那应该用哪种分类呢？就个人经验而言，如果划分用户故事时页面已经清楚了，那可以按页面划分。因为我们公司开发基本是按页面开发。这种情况 一般发生在做系统维护升级的项目。对于新项目，功能需求都没有出来，页面肯定是出不来的。这种情况就可以按功能模块划分. 下文中有本人对Bowsing 和Search 的功能点划分图。供参考。
严格来说，我们其实也没有严谨的遵守用户故事划分原则。更倾向于将需求划分为相对独立的小的功能点，而不是用户故事。对于用户故事的定义及划分原则，大家可以自行百度goole. 个人认为一切的方法和理论目的都是解决问题，不必要一定要遵守定义的条条框框。根据公司项目实际开发习惯，高效解决问题就好。

问题二：

用户故事直接建到工作系统(JIRA) 里作为ticket使用，没有用文档记录。用户故事的状态反应对其进行开发的状态。如开发完成，那用户故事的状态会被置为关闭。如果一个用户故事关闭后发生需求变更，该怎么处理？

解决方案：

如果需求变更时用户故事还没有关闭，那就在原始用户故事上改需求描述并进行开发。如果用户故事已经关闭，那就创建新的用户故事描述新的需求。

实际效果及问题总结：

对正在开发过程中的用户故事进行修改，要事先和开发沟通好。避免造成修改的部分没被开发注意到。同意也要通知到正在准备测试用例的同学， 以便测试用例同步更新。



问题三：
如何统计需求变更? 比如某天项目要求统计出项目的需求变更(做了五年的项目貌似只被要求过一次)。对于新建的需求变更用户故事上加一个标签就很容易被统计出来。但是对于在原始用户故事上进行改动就统计不出来。因为在整个原始用户故事上加标签不合理，尤其当只有很小的一部分用户故事需求发生发动时。

解决方案：
需求变更控制沿用非敏捷时期的变更控制流程。控制流程图附入下文。该流程中会使用需求变更表单文档记录需求变更内容和实现变更需要时间和客户应该付的额外经费。需求变更文档配合变更列表就能很好的追踪和统计需求变更。

实际效果及问题总结：
任何流程都是为了有章法地解决问题。不能被流程绑架。比如在该项目实际执行过程中PM这段基本是由BA来完成。
判断是否是一个收费的CR的标准有些是用审批过的需求文档作标准，有时是用项签订项目合同时的功能列表作为标准。


问题四：
在系统中查看用户故事查阅需求时如何时知道这是不是最新的需求？

解决方案：

用户故事可能在关闭后发生需求变更。这种情况下已关闭的用户故事里的描述是不允许更改的。
JIRA 系统里的ticket 有相互链接的功能。如果一个用户故事在关闭后发生变更，必然会有新的用户故事ticket 产生。把新的用户故事链接到已关闭的用户故事即可解决。
需求变更产生的用户故事在ticket 在用户故事名称上加明显标识有助于快速找到需求变更对应的用户故事。如Change - [story name]

问题五：
项目要求用文档记录需求。方便某些人不想用用户地图+JIRA 系统查看需求时可以直接用文档搜索。

解决方案：
把用户故事按故事地图为章节复制到文档里。

实际效果及问题总结：
文档生成后并和系统里的用户故事同步更新耗费时间。目前为止，没有任何项目成员去看过这个文档。暂时没看出来这个文档存在的意义。如果项目不要求在某阶段必须产出这个文档，可以在每个sprint 结束时把sprint 里关闭的story 复制到文档里。一个Sprint 一个Sprint 地去做。这样可以节约更新文档的时间。因为关闭的Story 需求变动的可能性比较小。

开发方面

开发方面我们并没有严格按敏捷的定义做法。比如估算Story point, 我们并没有让几个开发坐在会议室大家亮出自己的估算，最高和最低的分别解释估算的理由，然后协商达成一致。Story point 估算基本都是team leader 在sprint 开始前自行决定。

测试方面

测试流程和之前一样，没什么影响。

如本文对您有用，请点下方的“推荐”哟。

附图：

Search / Browsing 功能点划分(TBD表示除Search 和Browsing 以外的功能点 )