传统软件开发（或者说瀑布式软件开发）方法，对于需求的看法是 – 尽可能详细的了解需求、分析需求以形成详尽的需求文档，然后就把文档交付给开发部门。敏捷软件开发中则是完全不一样的做法。首先敏捷需求是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