敏捷需求之分层管理

传统软件开发（或者说瀑布式软件开发）方法，对于需求的看法是 – 尽可能详细的了解需求、分析需求以形成详尽的需求文档，然后就把文档交付给开发部门。敏捷软件开发中则是完全不一样的做法。首先敏捷需求是ODDE的，其中有一个点很重要就是Detailed Rightly (Appropriated) – 详略得当。

什么是详略得当

介绍详略得当之前，我们先看一张图

在上图的产品列表（Product Backlog）中，最左边分为几个部分：已完成，细粒度，粗粒度，下一版本。已完成无需介绍，下面分别介绍一下细粒度，粗粒度，下一版本。

细粒度

细粒度的意思是这些产品列表条目是相对比较明确的，详细的。团队对于这些条目的认知是达成一致的。经常有学员问我，那这些条目到底多大合适？这里有一个经验值供参考（根据行业不同会有很大不同） – 一般来说，一个团队在一个迭代内完成6-12个条目为宜。细粒度一般也意味着马上要做的条目。

粗粒度

粗粒度指的是这些条目的细节还不清楚，团队有可能没有达成共识。粗粒度一般是接下来2-3个迭代要做的条目，并且会在产品列表梳理会上，对粗粒度的条目进行拆分、澄清，从而有可能变成细粒度的条目。

下一版本

有一些条目是近期不会考虑的，但从产品规划上需要有考虑的。比如正在做一个安卓APP，从长远来看是需要做iOS版本的，不过可能要3个月后才会考虑。这样的条目就是下一版本的。

为什么详略得当很重要

敏捷需求是有分层的，正如上一节讨论的，分为：已完成，细粒度，粗粒度，下一版本。

如本文的题图（感谢Alistair Cockburn博士），产品列表中的条目也是可以分为鱼虾级别（故事）、大海级别（Epic）和风筝级别（Theme）。

那么为什么详略得当如此重要呢？

这是因为产品列表条目，我们（作为人类）不可能一次获得所有信息。在产品开发的早期，获得的信息尤其少，那这个时候做出的需求分析（或决策）怎么可能包含所有的条目呢？因此条目就不可避免的有大海和风筝，只有少量的鱼虾可以完成。随着完成的鱼虾越来越多，我们获得的信息也越来越多，对产品的认知也越来越清楚，从而能够做出更加可信的决策。

写在最后

本篇文章起源于“敏捷之旅北京众筹群”中，和火星人陈勇之间的一次讨论。我的观点和陈勇老师略有不同。用户故事，顾名思义，是从用户的角度来讲故事。那么它的核心是产品负责人和开发团队之间都了解这个用户故事是解决什么问题的。而不是一定要从Theme拆分成多少个Epic，从而再拆分成多少个Story这样的一个过程。