初次实践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的兄弟能给指导一下啊？

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


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

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

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

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

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

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

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

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

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

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

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

很荣幸，gigix先生能够来指导我，像您说的“真的有人会按照出版社或者ISBN来查询吗？或者只是你认为这样列举出来就‘完备’了？” 我以前还真的没有认真想过这个问题，现在想来，应该是为了能够早点应对这样的需求？那么，按照XP的理念的话，是不是先不用管这些“可能”出现的需求？而是到真正发生的时候再做考虑呢？那么类似这样的，查询字段的增加，以什么样的方式处理能够比较优雅呢？具体来说，就是怎么样能够不违背OCP原则？
管理员的查询，是这样，管理员对图书的现状的查询，深入的想的话，可能会总结出来几种特定的不同类型，特定的不同具体业务目的的查询，但是这些类型的查询需求的优先级没有那么高，而且通过对读者使用的图书查询功能的一些简单修改，就可以暂时实现这些查询，分析投入和产出，我个人觉得还是值得的。不知道您怎么想？

XP的一个核心思想就是沟通，尤其对我这个刚入门的XP新人来说，能够与大家讨论，是非常难得的机会。感谢大家的指点！！

从你的回答来看，我觉得你还没有真正进入“现场客户”这个角色。
现场客户应当是一个熟悉自己业务的图书馆管理员。

如果我是现场客户，早期的四个US草稿可能是这样的。
1、书籍新增登记。一本新的书来了，必须将其主要信息记录下来。
2、书籍报废。一本书不能用了，退出图书馆。
3、借书。有人来向我借书，我登记相关信息，把书给他。
4、还书。借书的人来还书，我应当找的到上次借书的信息，并将书取回。

排一下优先级，1最优先，3/4是一对，优先级其次，2放在后面。

我和开发人员讨论的时候，发现借书的时候应当让借书的人可以看到目前可借书籍的清单。因此将书籍查询/检索的内容加入到3中。

又过了两小时，我想到我应当时刻掌握目前书的情况，某本书是否已借出，在谁的手里，因此增加了一个US。5:管理员查询。关注书的目前状态。并且我把它的优先级排在3/4之后，2之前。

随后开发人员觉得3中的书籍查询/检索 和 5的管理员查询有很多类似，要求进一步的细化，于是你们仔细讨论了从一般用户角度和管理员角度所需要的不同查询条件/查询结果……

clamp这里就很明确的表达出来每个动作的目的,而且,用词也很少见到咋们开发人员的影子. 所谓的神,可以认为你是否能够把自己开发人员的角色忘记，切换到客户这个角色上.

gigix对其中ISBN及出版社查询的疑问,据我了解，这一点在实际中确实是需要用到的.

gigix有提到value,在我理解其实就是我前面提到的目的,这两个应该是一样的.

其实我觉得,从我以及gigix的疑问，到clamp的举例，最重要是clamp概括的这句话：
真正进入“现场客户”这个角色。

你们都会有一个好的平台给你们练习或者有一个好的领导。唉，我们就惨。因为提升公司的企业文化，公司买了很多的图书，很多的杂志，很多的影碟，，，，现在准备提供给员工，那么公司就要开发一套图书管理系统。公司根本没有考虑到我们（开发部），索性买了一套系统。巨郁闷！
XP，AMMD这些只能自己慢慢的体会，先学会形。