初次实践user story时遇到的实际问题，哪位高人进来指导下？

    打算在部门内部推行XP，也看了一些资料，根据我们部门的实际情况，打算从需求方面采用user story开始。但是在实践了两次之后，有些问题浮现了出来，因此，特地到此宝地求教一二。
    User story,从我的角度来理解，他的好处，显而易见，可以将用户的需求尽快、尽早、尽量详细的向开发团队、以及利益相关者来开放，可以发现需求中不合理的地方，并且可以挖掘出需求中一些真正对客户有价值的东西；也许客户刚开始认为重要的需求，由于某些新的，更加关键或者更加有business value的东西出现，而变得不重要了。此外，对user story的讨论，会对设计者产生潜移默化的影响，user story的INVEST特性中的I（independent)特性，自然的要求系统的各个模块和层次之间，尽量减少耦合。其余的几个特性，虽然说起来很简单，但是怎么做到，真的是挺难的。
    以我最近的实践，我们部门内部打算以xp的方式开发一个图书管理系统（BMS）。我要描述的后面三个user story涉及如下的角色：
     ☆初级读者：只能使用系统的一些基本功能，并且所能查阅到和借阅的书籍也受限制
     ☆资深读者：可以使用系统的一些深入功能，查阅到的书籍范围比初级读者多
     ☆系统管理员：系统的全部功能都对他开放，系统中的数据处理权限对他全部开放

     user story:
1、初级读者对现有全部图书的情况进行查询。
   接受条件：
○ 按照下列查询字段：书籍名称、所属类别、作者、出版社、ISBN；
○ 对查询结果的要求：可以按照书籍名称、所属类别、作者、出版社、价格进行排序；
○ 可以看到书籍当前的借阅状态（是否被借出，归还日期等）
○ 查到的书肯定都是可见的（系统中的书籍，有可能是不可见的，）
○ 不能看到资深级别的书
2、资深读者对现有全部图书的情况进行查询。
   接受条件：    ○ 按照下列查询字段：书籍名称、所属类别、作者、出版社、ISBN、读者级别、借阅人、借阅状态
○ 对查询结果的要求：可以按照书籍名称、所属类别、作者、出版社、借阅人、借阅读者级别、价格进行排序；
○ 可以看到书籍当前的借阅状态（是否被借出，归还日期等），并且可以看到借阅人是谁
○ 查到的书肯定都是可见
3、系统管理员对现有全部图书的情况进行查询。
   接受条件：    ○ 按照下列查询字段：书籍名称、所属类别、作者、出版社、ISBN、读者级别、借阅人、借阅状态、是否可见（包括全部的情况）
○ 对查询结果的要求：可以按照书籍名称、所属类别、作者、出版社、借阅人、借阅读者级别、价格、是否可见进行排序；
○ 可以看到书籍当前的借阅状态（是否被借出，是否处于续借状态，归还日期等），并且可以看到借阅人是谁
○ 可以看到系统中的全部书籍（也可以看到对读者不可见的书）

    就上述三个user story来讲，主干功能是相同的，但是有些细节：书籍的状态，借阅人的状态，能看到的书籍名录，书籍的明细字段等，这些细节不甚相同。当我写出这三个user story的时候，我对自己产生了怀疑，这些是合格的用户故事么？他们之间并不是互相完全独立的啊。是不是能够考虑拆分？如果考虑的话，又该如何拆分呢？这些疑问，哪位实践过user story的兄弟能给指导一下啊？

评论

5 楼 bryanzk 2007-02-08  

basicbest 写道

我做过馆际合作系统，比你这个要求会高一些，单纯从技术看，用工作流系统比较好些，里面可能会牵涉到大量的状态转换。

回到你的问题上来，US只是需求获取的一种方式，你不一定要严格按照UserStory的格式去做，你觉得能够描述清楚情况，就是可以的。从你所给出的详细地说明看，你捕捉到了需求的“形”，但没捕捉到
“神”。

由于我的经验不足，所以只能先是照着葫芦画瓢，先学样了。我想学“形”不易，学“神”更难。想跟basicbest请教一下，您对“神”怎么理解？

basicbest 写道

比如，你们把角色作了划分，给出了职责，但是我没有理解这样划分的目的是什么？特别是在这里做的非常详细，包括字段你们都想好了。当然，假如开始就能了解这些是很好的事情，但是了解了以后应该把它放在一边。

对角色划分的目的吗？我想这个目的是为系统中对后面的权限处理提供素材，并让开发人员在设计类的时候，能够保有相关的概念。

basicbest 写道

比如黑体字部分，首先“状态”这个字我个人认为是有些问题的，是软件系统中的词，应该不是图书管理人员使用的他们的专业词汇。类似于“状况”这样词可能更合理些。还有，为什么要可以看见状态呢？看见状态的用意是什么？这个在你的说明里是发现不了的。

“状态”一词，由于我本身将来将作为这个系统的用户，所以是我提出来的。我希望在查询书籍的时候，可以看到这本书是谁借阅走了，什么时候借的，是续借的，还是第一次借书操作。就是说我希望能够对书籍的当下状况有个追踪。那么读者需要这个书籍的“状况”（在这里使用您的用词），他会希望看到一本书籍什么时候会被归还，从而自己可以安排时间，能够及时借阅到自己想要的图书。这个想法，是我作为一个图书馆的读者，我希望图书馆的系统能够为我提供的服务。

4 楼 gigix 2007-02-08  

粗粗一看，感觉这个需求是有问题的

引用

按照下列查询字段：书籍名称、所属类别、作者、出版社、ISBN；

真的有人会按照出版社或者ISBN来查询吗？或者只是你认为这样列举出来就“完备”了？
管理员的查询也是一样。这个管理员每次登录以后会做什么事情？每件事情的频度是怎样？我相信他不会没事干就掉换着各种条件查询图书玩。
user story的“INVEST”就包括“valuable“。这些story的value是什么？至少在我看来是不清晰的。

3 楼 basicbest 2007-02-08  

我做过馆际合作系统，比你这个要求会高一些，单纯从技术看，用工作流系统比较好些，里面可能会牵涉到大量的状态转换。

回到你的问题上来，US只是需求获取的一种方式，你不一定要严格按照UserStory的格式去做，你觉得能够描述清楚情况，就是可以的。从你所给出的详细地说明看，你捕捉到了需求的“形”，但没捕捉到
“神”。
比如，你们把角色作了划分，给出了职责，但是我没有理解这样划分的目的是什么？特别是在这里做的非常详细，包括字段你们都想好了。当然，假如开始就能了解这些是很好的事情，但是了解了以后应该把它放在一边。

1、初级读者对现有全部图书的情况进行查询。
接受条件：
○ 按照下列查询字段：书籍名称、所属类别、作者、出版社、ISBN；
○ 对查询结果的要求：可以按照书籍名称、所属类别、作者、出版社、价格进行排序；
○ 可以看到书籍当前的借阅状态（是否被借出，归还日期等）
○ 查到的书肯定都是可见的（系统中的书籍，有可能是不可见的，）
○ 不能看到资深级别的书

比如黑体字部分，首先“状态”这个字我个人认为是有些问题的，是软件系统中的词，应该不是图书管理人员使用的他们的专业词汇。类似于“状况”这样词可能更合理些。还有，为什么要可以看见状态呢？看见状态的用意是什么？这个在你的说明里是发现不了的。

2 楼 bryanzk 2007-02-08  

现场客户就是我，因为这个系统本身就是要为我们部门内部的图书管理来服务的，另外，这个系统的框架将可能作为我们后续的业务系统的主要框架存在。bms这个系统，也将作为整个部门的开发方式逐渐向oo和xp方面转变的练习系统，包括新人的培训，都有可能是对这个系统的业务补充和完善。

1 楼 clamp 2007-02-08  

谁是“现场客户”？
我觉得你进展的太快了，一开始还是算一个故事比较好。


另外，对于内部系统而言，有必要搞这么复杂嘛？自己玩自己？