敏捷需求之分层管理
传统软件开发（或者说瀑布式软件开发）方法，对于需求的看法是 – 尽可能详细的了解需求、分析需求以形成详尽的需求文档，然后就把文档交付给开发部门。敏捷软件开发中则是完全不一样的做法。首先敏捷需求是ODDE的，其中有一个点很重要就是Detailed Rightly (Appropriated) – 详略得当。
什么是详略得当
介绍详略得当之前，我们先看一张图
在上图的产品列表（Product Backlog）中，最左边分为几个部分：已完成，细粒度，粗粒度，下一版本。已完成无需介绍，下面分别介绍一下细粒度，粗粒度，下一版本。
细粒度
细粒度的意思是这些产品列表条目是相对比较明确的，详细的。团队对于这些条目的认知是达成一致的。经常有学员问我，那这些条目到底多大合适？这里有一个经验值供参考（根据行业不同会有很大不同） – 一般来说，一个团队在一个迭代内完成6-12个条目为宜。细粒度一般也意味着马上要做的条目。
粗粒度
粗粒度指的是这些条目的细节还不清楚，团队有可能没有达成共识。粗粒度一般是接下来2-3个迭代要做的条目，并且会在产品列表梳理会上，对粗粒度的条目进行拆分、澄清，从而有可能变成细粒度的条目。
下一版本
有一些条目是近期不会考虑的，但从产品规划上需要有考虑的。比如正在做一个安卓APP，从长远来看是需要做iOS版本的，不过可能要3个月后才会考虑。这样的条目就是下一版本的。
为什么详略得当很重要
敏捷需求是有分层的，正如上一节讨论的，分为：已完成，细粒度，粗粒度，下一版本。
如本文的题图（感谢Alistair Cockburn博士），产品列表中的条目也是可以分为鱼虾级别（故事）、大海级别（Epic）和风筝级别（Theme）。
那么为什么详略得当如此重要呢？
这是因为产品列表条目，我们（作为人类）不可能一次获得所有信息。在产品开发的早期，获得的信息尤其少，那这个时候做出的需求分析（或决策）怎么可能包含所有的条目呢？因此条目就不可避免的有大海和风筝，只有少量的鱼虾可以完成。随着完成的鱼虾越来越多，我们获得的信息也越来越多，对产品的认知也越来越清楚，从而能够做出更加可信的决策。
写在最后
本篇文章起源于“敏捷之旅北京众筹群”中，和火星人陈勇之间的一次讨论。我的观点和陈勇老师略有不同。用户故事，顾名思义，是从用户的角度来讲故事。那么它的核心是产品负责人和开发团队之间都了解这个用户故事是解决什么问题的。而不是一定要从Theme拆分成多少个Epic，从而再拆分成多少个Story这样的一个过程。
讨论原文如下：
火星人 18:20
我在开发中摸索出一个新体系，能在战术层面融合uml fpa story scrum mvc这几个东西
火星人 18:21
以前都是战略层面上融合，“兼容”但是没有具体做饭法
火星人 18:26
最近做项目的时候发现了一种很多人本能会用但稍加改良就能统一所有方法的东西
火星人 18:43
涉及到jira中theme epic story三层需求的定义
火星人 18:44
用这种方法可以让两个人分解出来的三层内容几乎相同
火星人 18:46
就是因为头疼分解问题，我观察了项目前期的需求，发现了一些规律。等我到笔记本上打字吧
火星人 18:50
我们发现有一种故事比较“舒服”，就是可以放在“作为一个……，可以（故事）……，以便……”，这种故事都是动宾词组，比如“上传简历”，“查看商品”等等，从文学的角度正好放在“可以”后面。
火星人 18:50
另外一种故事则有点问题，比如“货物管理”“配置子系统”，完全不可能“可以货物管理”，或者“可以配置子系统”
JinKenny 18:51
这就是As a…I want….So that…结构
火星人 18:51
后来我们就把洞宾词组的放在第三层（Jira和TFS都叫Story），名词的放在第二层，并将其分解为相应的动宾词组
火星人 18:52
比如货物管理在第二层，第三层则是增删改查货物（多数时候不是增删改查这几个字，但其实跳不出去的，只是变形了而已）。这一层在Jira里边是Epic，TFS是Feature
火星人 18:53
第一层最大的比较麻烦，就是Jira里边的Theme和TFS里边的Epic
火星人 18:54
但这一层又是最大、最高层、最早应该定下来的。后来我们大致使用了反推法，就是先发现第二层，再根据关系远近分组。比如“购物子系统”，“收发货子系统”
火星人 18:54
虽然第一层也是名词，但无法“增删改查”购物子系统，因为购物子系统里边包含若干个第二层的词汇，比如商品，订单，结算记录。这三个才是可以被增删改查的。
火星人 18:56
后来又发现了一些量化关系，比如（下面用Jira的定义）1×Theme=2～15×Epic=6×Story，另外每个Epic=35人天，每个Story=4.3人天
火星人 18:56
这些数字是因为这样定义Epic和Story后，就兼容FPA中的定义了，而FPA是有大量数据统计结果的（全球50万个以上项目），这样就给早期估算带来了可能。
火星人 18:57
此外还发现，一个Epic=1Controller，1个Story=1Action，只需要翻译一下文字就行。
火星人 18:57
我们的项目几乎完全如此，只要完成需求分析（拿到Jira中三层需求），编码结构就是确定的了。
火星人 18:58
后来又发现了一种VCMD分层结构，来解决单个Action编码中的封装层数和规则，这样无论谁来编码，看上去差别都不大。
火星人 18:59
此外如果废止UML中关于用例的扩展关系，那么UML中用例=刚才的Story
姜信宝Agile Bob～京东敏捷教练 18:59
@火星人 陈老师研究的深入，细致。可以详细交流。在敏捷中也有需求分层的概念。和你的方法不谋而合
火星人 19:00
恩，我本来想做一个工具来支撑的，后来发现TFS和JIra不约而同都出现了三层结构（最初我们四层，后来发现有两层很难定义，后来取消了一层），就没继续做
火星人 19:00
他们肯定有一个背后的理论支撑，虽然我没看到。
火星人 19:01
此前关于Epic-Story的结构由来已久，但是定义非常模糊，10个人会得到10个不同结果
火星人 19:01
用这种方法几乎只有一种。
火星人 19:02
我在课堂上做过每层大约200次的练习了，重复性很好。
火星人 19:02
他们得到的结果和我的结果很接近，或者如果我觉得不对修改了他们的练习结果，他们会很认同（毕竟每层只有15～20分钟学习时间，不可能马上把握）
JinKenny 19:03
陈老师用法新颖[强]
JinKenny 19:03
JinKenny 19:03
这是JIRA的需求层级，这里不包含Story，因为太细了
火星人 19:06
这个其实是借鉴FPA的分层方法
火星人 19:06
FPA只分两层，就是名词和动词
火星人 19:07
哈差不多，你看你第三层（在4下面有），会不由自主地使用动词，而其他层则是名词。
火星人 19:08
所以我说这是一个很多人都本能用过，但没太注意的方法。
火星人 19:08
后来我们找到了一种一两分钟内穷举一个Epic所有Story的方法，有两个模板，CIDED和CIDRA
火星人 19:09
CIDED=Create, Index, Details, Edit, Delete，注意这个不是说只有这5个故事，而是要从这五个层面入手。比如Create可能=Create Batch Create Inport，但总之都是Create（后台调用SQL INSERT的）
火星人 19:10
INDEX可能=LIST CHART1 CHART２，但都是多个Item相关的（后台调用SQL SELECT的）
火星人 19:11
CIDRA＝Create Index Details Reject Approve
火星人 19:11
呵呵，我也觉得有点诧异。Jira文化还是很好的，应该不会吧。 
火星人 19:13
西山发的图已经很好了，几乎已经符合要求了。我看过很多名词动词位于同一层的（实际开发工作量相差3～9倍，平均6.5）
JinKenny 19:16
atlassian所有产品在release之前，就是4周的dogfooding
火星人 19:37
你们再用Jira？
JinKenny 19:37
我们做atlassian产品的咨询服务
火星人 19:37
难怪
火星人 19:37
我经常被课后拉着去开发现场，帮他们看Jira呢呵呵。
火星人 19:37
多数企业拿到3层结构的Jira并不会用
火星人 19:37
你们刚才的图片是Jira官方的？
JinKenny 19:37
哈哈，其实还有一层task
JinKenny 19:37
inititive，epic，story，task
JinKenny 19:37
大多数客户觉得不是太多就是太少
JinKenny 19:37
对，那是portfolio的截图。不过国内很少公司用
火星人 19:37
不叫theme改成initive了？
JinKenny 19:37
theme是inititive的一种分类，类似label
火星人 19:37
在我的体系里边，Theme承载着Initive，其分析工具叫做Role-Business图，就是何人为何要此物的图。我们之前不叫Theme，而是叫SubSystem
火星人 19:37
还有几种？
JinKenny 19:37
通常也是一一对应的
JinKenny 19:37
由于是label，完全可以理解为theme包含了init
JinKenny 19:37
然后再下来才是epic
JinKenny 19:37
至此大po的工作就结束了
JinKenny 19:37
小po去做story
火星人 19:37
我们只分了一种，但是感觉有三大类，其中一种是业务（包括用户和比如银行人员用的，以及后台自动响应和处理的）；第二种是配置功能（客户可用的配置功能）；第三种是内部架构（开发人员为了开发方便用的架构类功能，属于架构而非需求）
火星人 19:37
对差不多，我们也这么分。
JinKenny 19:37
然后sprint planning的时候团队再拆分成technical task
火星人 19:37
我这边也有Task，但是有两种情况。第一种情况是这个Story如果可以由一个程序员完成，则不再分Task。因为用上面方法得到的Story平均工作量4.3，已经很小了。
火星人 19:37
第二种，如果必须交给两个人，才分Task，这是分与不分的界限。
JinKenny 19:37
能独立交付当然最好，这几乎代表着跨职能
火星人 19:37
我怀疑Jira没有清晰规定Story的定义，导致某些Story太大，不得不辅助以Task来完成。我说的第二种Task是你说的TEchinal Task，只是由于人的技能问题、技术差异导致无法单人完成的。
JinKenny 19:37
jira其实就是个软件
JinKenny 19:37
由于比较灵活易于定制，因此比较容易适应不同的管理思想和体系
火星人 19:37
对
JinKenny 19:37
核心目标是尊重每个团队的不同
火星人 19:37
不过我们观察到越灵活，越难用。因此想找到一种最佳方法，其他方法再从最佳方法上向上或向下变化，至少有个参照标准了。
JinKenny 19:37
做的适应性强就好了
火星人 19:38
其实你看Jira限制了3层结构，其实就是否定了WORD式的无限灵活。
火星人 19:38
WORD写出来的结构更是五花八门，新手完全不知道怎么弄。
JinKenny 19:39
所以推荐用confluence写需求
火星人 19:39
对了，Con里边有没有这些层级？
火星人 19:40
我是说提前定义好的，
JinKenny 19:40
客户差异太大了，38%的jira客户将jira用于非研发领域
火星人 19:40
比如，在C里边就建一个Theme
JinKenny 19:40
有，叫blue print
火星人 19:42
倒，为什么不叫一个名字……
JinKenny 19:42
这是一个重要的功能名字
JinKenny 19:42
内置于confluence
JinKenny 19:43
类似于word模版，但功能强大得多
火星人 19:43
恩。
火星人 19:43
对，提前内置比自由定义好很多的，尤其是研发管理。其他的不提了。
JinKenny 19:44
嗯，没错
JinKenny 19:44
自由定义一人一个样
姜信宝Agile Bob～京东敏捷教练 21:39
@火星人 在Alistair Cockburn博士的writing effective use cases中也提到需求分层的概念，
姜信宝Agile Bob～京东敏捷教练 21:40
分了3层：风筝，大海，鱼。风筝就是Theme, 大海就是Epic, 鱼就是Story
姜信宝Agile Bob～京东敏捷教练 21:42
Jeff Patton的故事地图中，也有3层，Backbone, walking skeleton, task(未列出)
