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

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

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

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

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

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

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

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

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

其实这个系统的“图书馆管理员”的角色，目前就是我，对于我来说，书籍的新增和报废，目前不是最重要的需求，最要紧的是，先把图书的借阅情况记录下来;而书籍的信息，我可以直接从后台先导入。
我理解您说的这个过程，是不是对一个系统进行敏捷需求的通常情况下，可能发生的情形？
但是我们部门的这个BMS系统有个前提，就是我们要用它来实验、改进我们的一个新的OO开发框架，框架涉及到权限验证、日志记录、业务逻辑与UI分离等目标。所以要尽可能考虑到将来它要服务和支撑的系统涉及的多个大的方面，当然每个方面不需要特别细节的实现。但是要考虑到这些方面对框架的要求。这也是我为什么要在一开始就分离出多个角色的原因

其实这个系统的“图书馆管理员”的角色，目前就是我，对于我来说，书籍的新增和报废，目前不是最重要的需求，最要紧的是，先把图书的借阅情况记录下来;而书籍的信息，我可以直接从后台先导入。
我理解您说的这个过程，是不是对一个系统进行敏捷需求的通常情况下，可能发生的情形？
但是我们部门的这个BMS系统有个前提，就是我们要用它来实验、改进我们的一个新的OO开发框架，框架涉及到权限验证、日志记录、业务逻辑与UI分离等目标。所以要尽可能考虑到将来它要服务和支撑的系统涉及的多个大的方面，当然每个方面不需要特别细节的实现。但是要考虑到这些方面对框架的要求。这也是我为什么要在一开始就分离出多个角色的原因

use story如果复杂到你写的那个地步，还能叫use story吗？
不要害怕他们简陋，因为他们只是一个开始。你需要的是在迭代中不断的去完善它们，而不是要你在一开始就搞一个大家伙出来吓人。

还是“过分追求完美”造成的，这似乎是技术人员的通病，需要慢慢的锻炼。我也一样

其实我早就发现，至少在中国推行敏捷实际上还是在推行迭代。这方面不仅仅是agile在做工作，up也在做工作，其他很多人也在做工作。但是人们的思维方式已经被瀑布控制了，因此迭代也仅仅是一种形式。
当然敏捷其实根本上来说只是一种态度，是一种方式，而方法论的部分并不是其真正的核心。因此如果大家不能用敏捷的思想来做事情，即使你的方法和形式再xp，你依然不是agile、