关于用户故事这件事

两个问题，第一个，用户故事的复杂度：

partech兄你认为用户故事要驱动计划、度量、设计、测试等等这么多方面吗？那我可就觉得有问题了。
这四个方面都相当复杂，如果想用统一的工件来驱动他们，那这个工件得有多复杂？它又得有多重要？用户故事如果真的驱动这么多东西，那我们估计需要在用户故事上下大力气了，以避免无谓迭代造成的浪费。

但是如果真的在用户故事上下大力气，岂不是又回到了传统软件工程的需求分析阶段。这也是我的疑惑，XP中把用户故事的地位抬的这么高这种做法，是不是有先天不足。


第二个：用户故事真的能描述复杂的需求吗？
partech兄的Boss在研究NGOSS，SID 真是太好了，有共同语言，呵呵。我的困惑：像NGOSS面临的这种领域，其中的需求用用户故事真的能描述清楚吗？不要说描述清楚，连描述出来都很困难。起码我们在这方面的实践是以失败告终的，最后还是要用传统的方式来描述和记录需求。
我还是昨天的看法，“在企业软件这个领域，很少有需求可以独立于领域模型（或者叫数据库模型、ER图，类似的东西）而单独存在。甚至可以有一个断言，脱离了领域模型的需求，必然在细节上有所缺失，而且离领域模型越远，细节的缺失就越严重。 ”
在这方面，用户故事因为脱离了领域模型，所以我认为它是先天不足的，只能作为一个收集需求的前期动作，而不像您说的它能驱动其后如此之多的软件开发行为。


我目前的认识：用户故事可以用来划定系统的粗线条功能范围，仅此而已。所以这种东西最好在谈合同的时候用，开发的时候就算了，呵呵。

在电信领域（包括其他复杂的领域）是可以使用用户故事的，但是对提炼这个故事的人要求很高。

用户故事的名称我觉得有点误导，容易理解成“用户”讲的才是故事。
事实上在很多大型软件的开发过程中，很多用户都不理解要做什么。

因此要“正确”的描述一个用户故事就比较困难

两个问题，第一个，用户故事的复杂度：

partech兄你认为用户故事要驱动计划、度量、设计、测试等等这么多方面吗？那我可就觉得有问题了。
这四个方面都相当复杂，如果想用统一的工件来驱动他们，那这个工件得有多复杂？它又得有多重要？用户故事如果真的驱动这么多东西，那我们估计需要在用户故事上下大力气了，以避免无谓迭代造成的浪费。

但是如果真的在用户故事上下大力气，岂不是又回到了传统软件工程的需求分析阶段。这也是我的疑惑，XP中把用户故事的地位抬的这么高这种做法，是不是有先天不足。

第二个：用户故事真的能描述复杂的需求吗？
partech兄的Boss在研究NGOSS，SID 真是太好了，有共同语言，呵呵。我的困惑：像NGOSS面临的这种领域，其中的需求用用户故事真的能描述清楚吗？不要说描述清楚，连描述出来都很困难。起码我们在这方面的实践是以失败告终的，最后还是要用传统的方式来描述和记录需求。
我还是昨天的看法，“在企业软件这个领域，很少有需求可以独立于领域模型（或者叫数据库模型、ER图，类似的东西）而单独存在。甚至可以有一个断言，脱离了领域模型的需求，必然在细节上有所缺失，而且离领域模型越远，细节的缺失就越严重。 ”
在这方面，用户故事因为脱离了领域模型，所以我认为它是先天不足的，只能作为一个收集需求的前期动作，而不像您说的它能驱动其后如此之多的软件开发行为。

我目前的认识：用户故事可以用来划定系统的粗线条功能范围，仅此而已。所以这种东西最好在谈合同的时候用，开发的时候就算了，呵呵。

不是吧。用户故事，确实应该理解为“用户的故事”，理解为“客户/用户故事”更合适。故事当然要客户/用户能理解，否则，客户如何化分优先级，如何计划发布和迭代呢？
开发人员可以帮助完成用户故事，但是客户团队才是直接的干系人。

对于成熟的项目，假如客户基本参与新版本的开发过程，那么这里的客户就是指客户团队，而不是真实的客户。

难道你说的是针对开发人员的“任务”？

你用的词是“客户团队”，这个概念其实是比较模糊的。
我说的用户指的是“最终用户”，也就是实际操作/使用系统的人。

那我作下澄清。
这里的客户团队包括客户、实际用户、测试员、产品经理、交互设计员等。
他们的特征是把系统当“黑箱”来看待。

恩，这么说就差不多了。
但你不觉得把这么多角色简单的冠于“客户团队“合适吗？
他们的责权利都有很大的差异

对于开发人员来说是方便了很多，但是对于整个项目/产品来说却不解决根本问题
这也是我一直对xp的”用户故事“、”现场客户“不怎么满意的原因

是的，他们之间的职责确实存在较大的区别，但共同之处就在于他们都多少同指定需求，验证需求的职责相关。实际上概括来看，开发角色主要就只有两方客户团队、实现团队，是比较清晰的。

你说的根本问题，是指...？

说到“现场客户”，我认为不能等同于真实的用户。除了对领域有透彻的了解外，他还要对项目的目标，很清楚，别人可都得追随他引导哦；另外，他至少对开发过程要有所了解，也要对于自己在过程当中充当的角色，怎样同其它角色交互，有充分理解，否则，不可能胜任。

不错，“现场客户”的要求很高，这正是我不满意的原因，因为很多情况下，根本找不到符合条件的“现场客户”。
在很多项目上，业务方面的问题才是项目的主要矛盾，XP是把项目的主要矛盾从开发团队转移到“客户团队”或者“现场客户”上，但是这个“客户团队”或者“现场客户”在哪里呢？
所以我说仍然不解决根本问题