敏捷项目需求拆解&发现用户故事

需求文档和敏捷中的Epic，User Story， Task之间是什么关系以及如何将需求文档转换成敏捷方式的描述，指导开发人员。

一直是很多公司团队比较困扰的问题，那么最近笔者为了解决这些问题，上了一些课程，

现将核心内容，总结如下，希望对大家有帮助，一起探讨~~

在项目开发过程中，由于历史或者出于方便和规范的原因项目经理一般还是喜欢使用word文档来描述需求。

举个电商的例子，一般文档结构会如下所示

-------------------------------------------------------------------------

• 前言
• 功能性需求
  • 　　商铺管理场景
    • 　　建店申请
      • 提交申请
      • 查询所有申请
      • 查看单个申请
      • 。。。。。。
    • 店铺
      • 。。。。。。

------------------------------------------------------------------------

 一、如何将需求文档的内容转化成敏捷中的术语

上面这种格式文档对于敏捷开发团队来说可能是比较生疏的，因为开发团队一般常见的都是敏捷中的常用术语，如User Story， Task...

那么需求改如何变成敏捷术语中的Business Epic，Feature，User Story和Task呢？

下面举个栗子，需求如何对应到 SAFe（Scaled Agile Framework）框架 --常规的敏捷框架适用于中小型项目团队，而且不具有扩展性。基于常规的敏捷框架，SAFe 定义了一个可扩展的敏捷框架模型，它适用于大型团队的合作开发，可以帮助提高团队之间的协作性，降低团队管理的复杂性。

对于SAFe想做更多了解请看官网 https://www.scaledagileframework.com/

或者 https://www.ibm.com/developerworks/cn/rational/1606_wanghy_saf/index.html

从上图可知，拿到需求文档，

第一步，我们需要找到需求描述中的名词，名词一般是用来表述某项业务，所有将会对应到Business Epic或者是大的Feature。（描述偏业务性）

第二步，我们需要找到名词所对应的动词，动词主语是用户或者是外部系统的一般可以转化成User Story，也就是用户故事。（描述偏业务性）

第三步，还是要找动词，动词主语是开发者的，一般会转化为Task，也就是具体工作。（描述偏技术性）

敏捷术语和代码的对应关系

• Business Epic -->库/包
• Feature -->类
• User Story -->方法

一、如何防止需求遗漏

找到了所有的名字之后我们可以拿出每一个Feature建立以下表来捕捉用户故事。

第一行，参考上面第二步，列出所有的主语是用户或外部系统的名词

第一列，总是写上CIDED（增查查改删），第一个查为查询所有信息，理解为列表，第二个查为查询单个详细信息

然后在对应的格子中填写是否有相应的动词对个某个实体的某个特定的操作。

上面的列表可产生自粗略的需求说明，用来捕捉遗漏的需求，也可用来将需求用这个表来过渡，然后用As...I want...so that...格式描述成用户故事。

用户故事变成Task这个一般技术人员都会，这里就不再赘述。

一些参考数据：

• 自动化测试用例/功能点 = 1.2
• 一天大概能编写15~18个测试用例
• 名字平均6.5个动词 （3~9个动词）
• 一个名词35个功能点
• 一个功能点约等于1人天
• 一个功能点价格约等于1k
• 调整因子1.3根号人天数