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

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

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

现将核心内容，总结以下，但愿对你们有帮助，一块儿探讨~~

 

在项目开发过程当中，因为历史或者出于方便和规范的缘由项目经理通常仍是喜欢使用word文档来描述需求。

举个电商的例子，通常文档结构会以下所示

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

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

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

 

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

上面这种格式文档对于敏捷开发团队来讲多是比较生疏的，由于开发团队通常常见的都是敏捷中的经常使用术语，如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 -->方法

 

1、如何防止需求遗漏

 找到了全部的名字以后咱们能够拿出每个Feature创建如下表来捕捉用户故事。

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

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

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

 

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

 

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

 

一些参考数据：

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

 

 

个人博客即将搬运同步至腾讯云+社区，邀请你们一同入驻：https://cloud.tencent.com/developer/support-plan?invite_code=16mfkucn8havj