user story2

但是在Story的使用过程中，也暴露很多问题。一是完全抛弃需求分析记录（Use Case或IPO方式）的做法使产品或项目组的知识不能得到有效传承，我参与多个项目组的模块架构优化都只能从代码中了解模块需求，因为没有其他记录；二是Story的使用有扩大化的危险。现在不但有项目级Story，还有版本级Story，甚至最近又提出了Solution级Story概念。如果Story的使用范围如此扩大后，则知识传承的问题也将随之扩大，而真正进行需求分析和记录的Use Case却无人关注了。这是一个很大的问题。



我认为最好的做法是推行公司关于需求新架构2.0的要求，用System Feature、System Requirements、Allocated Requirements来表示系统特性、系统需求和模块分配需求，使用Use Case进行SR/AR的描述。在制订项目组级别或个人的迭代开发计划时，才有必要使用Story的概念，而且这个Story也仅仅是对AR的分解；在制订版本级别的迭代计划时，使用SF/SR的概念足够了。



很多时候我们是在玩弄名词，而非真正理解名词的含义。



如下是一个项目组模块需求Use Case的依赖关系定义，和三轮迭代交付计划Story的定义，一般是在模块设计完成后再进行Story划分，因为只有架构设计完成后，才能确切知道一个Story到底有多大的工作量。