关于用户故事这件事

*在考虑发布时，通常通过"必须、应该、可以、不需要"来划分故事的优先级

*划分故事，技术层面的因素有：1.故事不能按照预期的方式完成（例如：性能问题或算法问题）。2.某些故事的延迟会影响其他故事。（例如：完整的分层结构或多线程的考虑）

*客户和用户方面的因素是：1.故事使用的广度。2.重要客户或用户的故事。3.故事间的内聚程度

*该发布那些故事，总是客户来把握，但故事实现需要的代价会影响发布的决策，客户需要在开发人员对故事评估的帮助下，作好一次发布的决定。从而实现给目标组织提供最大价值

*如果客户对于某个故事该划分到那个优先级感到困惑，那么这个故事可能包含了不同优先级的小故事，需要分解

*是将技术风险高的故事优先考虑，还是将客户认为最有价值的故事优先考虑？这是一个问题，敏捷方法选择后者。不过客户在做决策时，也会考虑开发人员提供的风险信息。

*涉及到基础构件的风险故事，如果优先级给得太低，会使得将来的重构很困难，开发人员需要帮助客户找出这些对构架有重大影响的故事，但是这不能作为开发人员喜欢某个技术特性，而提高涉及的故事优先级的借口

*坚持每个迭代周期的长度固定，如果发布与迭代周期冲突，那么在最后一个迭代去匹配它们

*为了得到迭代计划,需要召开一个全体队员参加的迭代计划会议.客户、测试员、开发人员等都要参与。
因为团队需要考察迭代故事的细节，他们肯定会对此有些问题，他们需要客户来回答这些问题

*迭代计划会议工作流程如下：
1.讨论故事。
2.把故事分解为候选任务。
3.每个开发人员认领每一个任务。
4.当所有的故事讨论完毕，所有的任务都被认领后，开发人员自己评估所分配的任务，确认没有超过自己的能力。

*讨论故事。在迭代计划会议以前，团队已经设置了故事的优先级。就像开发人员可以改变实现一个故事的难度的观点一样，客户也可以改变故事的优先级。迭代计划会议是客户表达这种改变的最佳时间。会议开始时，客户从高优先级的故事开始，逐个读出。在读故事的间隙，开发人员依次就每个故事进行讯问，直到有足够的信息分解为候选的任务。

*在迭代期间，客户对于故事优先级的改变，可能会导致正在进行的故事中断，但是对于实现更好解决方案来说，放弃一个可工作版本，打破迭代本身的稳定性，是不值得。

*分解为任务。把用户故事分解为任务确实没有什么技巧。因为故事本来就足够小（典型需要花费开发人员1到5个理想天）,没有分解的必要。然而事实上，为什么还要进行分解，而不把故事作为一个离散的工作单元呢？

*虽然作为一个工作单元故事足够的小，但还是要进行分解。首先，许多团队不仅仅只有一个开发人员或者一组结对的开发人员。故事可能需要分解到不同的开发人员的身上，不管是因为开发人员特殊的技术背景，还是能够更快的完成故事。

*另外，故事是面向客户、用户价值的功能描述，它不是开发人员的任务列表。团队共同把故事转化为任务还有助于得到可能遗忘的任务。

*敏捷过程没有前期设计饱受争议。敏捷过程的重要特征之一，是及时简短的突发设计。分解任务正是具体体现。

*分解任务指南：
如果故事的一个任务特别难以评估，那么把这个任务从故事中剥离出来
如果任务能够很容易的分别被开发人员完成，那么分解这些任务
如果完成故事的一部分，能够带来价值，那么把这部分独立出来作为任务

*认领。即使团队采用结对编程，也最好让每个任务都有一个负责人。负责人确认任务是否完成。事实上，团队中的每个成员都有责任确认任务的完成情况，团队要有“同舟共济”的精神。在迭代末期如果有开发人员不能完成认领的任务，那么团队的其他成员会来帮助他，争取任务完成

*任务的负责人在迭代期间可以流动。在迭代中，对任务的认识加深，发现有些更加容易，有些更加困难，负责人需要变更。在一个迭代结束时，不能有人说“我的工作已完成，但某某某的还差一点点。”

*评估任务的最佳方法仍然是理想时间。为了得到可靠的评估结果，任务要足够的小。开发人员评估自己的任务，并把它们累加起来，然后作出现实的评估，这个迭代是否能完成？

*如果任务超过了个人预期，可以考虑下面的选择：
保留所有的任务，期望他们能完成
邀请团队中的其他成员，分担一部分任务
告知客户，需要削减故事或者通过分解故事来消减部分故事

*因为团队成员是一个整体，所以每个人都要对要完成的任务感到合适

8)有人给我写好故事，让我去做就好了......最头疼的就是写故事。

*度量速率。因为速率会关系到我们是否能按时的完成项目，所以度量它也就显得尤为重要。

*在计算已完成迭代的速率时，为完成的故事不能计算在内，因为估计故事完成的百分比是困难的；因为我们不想把迭代的速率精确的表示为43.25；因为部分完成的故事是不能提交给客户使用的；因为我们不想很多故事都被标记为完成了90%，只有少数的100%完成，特别难处理的部分就隐藏在那10%;所以在计算故事之前完成它就很重要。

*注意速率的计算是用迭代前评估它们的故事点来计算的。团队不能逆向的改变故事点，只可以调整任何将来故事的评估。

*可以使用四种图来监控迭代过程。
速率对比图
累计故事完成图
故事剩余图
时间剩余图

*故事的坏味道

*故事太小
征兆：经常修订评估
因为对太小的故事进行评估常常戏剧性的依赖于故事实现的顺序。

*相互依赖的故事
征兆：因为故事相互关联，迭代计划变得困难
团队发现如果要把某个故事划给本次迭代，就要把另外一个故事也要划进来，但是另外一个故事有需要第三个故事，等等。导致这样的原因是故事太小或者不适当的分解。想想采用“采用切蛋糕”的方法，能不能有所帮助。

*镀金
征兆：开发人员增加了非计划的特性，或者超过了故事本身所要求的特性。
通过日会，迭代回顾会议或者单独的质量保证组织可以避免开发人员镀金。

*太多细节
征兆：花太多的时间在实现前收集故事的细节，或者太多的时间写故事，而不是谈故事
用小的卡片来写用户故事……:)

*太早的包含用户界面

*想得太远，通常由于较大的前期“需求工程”造成。

*分解太多的故事

*客户为划分优先级感到烦恼

*客户不给故事定优先级

partech兄真是勤劳啊 

我想说说我对用户故事的理解：

讨论用户故事，首先要检讨自己打算把用户故事用在什么样的开发流程中。如果用在传统的软件工程过程中，用户故事不是正式的需求，它应该是一种非正规的早期需求收集方式。通过用户故事收集来的需求都是零散的，但是很容易理解。

在传统的软件工程过程中，用户故事与需求或者用例最显著的差别就是用户故事的非正式性，用户故事很少关注以下几个方面：

1. 故事的完备性。（是否这些故事反映了所有的需求？）
2. 多个故事间的执行顺序和依赖关系。
3. 故事之间是否存在包含、扩展、继承等关系。

而在XP中，用户故事可能要复杂得多，因为它是一类公民了，是很重要的工件，那写用户故事就不得不考虑以上三个问题。所以就会引入很多的细节，就像partech兄上面列举的，种种“不要”或“务必”，结果反而把用户故事弄得很复杂。

因此我的个人感觉：用户故事的概念虽然是从XP里面出来的，但我觉得用在传统过程中更好，它很好的填补了需求分析之前的空白阶段。反之像XP里面，把用户故事弄得复杂了，反而让人觉得彷徨，不清楚用户故事到底是干什么的了。一句老话，它什么都是，也什么都不是。


一点看法，可能有些偏颇，因为曾经被XP弄得相当混乱，呵呵。请partech兄指正。

我也是没办法，大Boss要求我给大家做个培训，其实他是想让我说服他为什么要使用用户故事，以前的用例，用得不是好好的吗？同他介绍“用户故事”的一言半语，已经勾起了他的兴趣。

大家共同探讨，一起提高。

你上面的看法，我倒是有些出乎我的意料。在我看来，传统的软件工程同敏捷过程在所依赖的哲学信仰是不同的。我不会把他们组合起来使用。
“在卡车装适用于跑车的轮子”，这......

我倒认为从他们生存的土壤出发，理解XP等敏捷过程其实不难。
比如：
*实现客户价值，满足客户意图是核心
*高效率的交谈胜于低带宽的文档交流
*“推迟细化”的原则
*没有测试的代码，是“不存在”的代码
*即时反馈，不断修正
*简单就是美
*自我管理

赫赫，我理解，有些像人文主义+实证主义+道家思想哦

你们的大Boss真是技术人员心目中的理想Boss啊，呵呵，你只言片语就说服他，可真是厉害。

XP提倡的理念和价值都非常符合我的希望，我挺喜欢XP的，不过喜欢才会对它要求更高。你能大致说一下你感觉中用户故事在XP中的地位吗？
如果用户故事只是代替了传统软件工程中的“需求分析”阶段，并且实现对需求的迭代完善，那用户故事肯定比现在我们的理解要复杂得多。

我下面的理解都是针对复杂领域的软件开发，不适用于小系统：

现实生活中的需求分析工作可能是高度领域相关的，这些“领域”通常不仅包含问题空间，还会包括部分解空间的知识（例如电信计费领域的TMF运营图、SID模型等）。我很难想象，这些领域的问题能够通过几个用户故事描述清楚。事实上，我感觉任何复杂的领域需求都不大可能通过简单的用户故事来进行描述。在我贫乏的想象中，用户故事也只能用来描述类似药品陈列管理或者便利店结算这类简单的需求。

因此我才会有前面的理解：用户故事可以作为传统软件工程中需求分析之前的一个良好补充，它远远代替不了对复杂需求的分析。

另外我有一点对需求分析的理解：在企业软件这个领域，很少有需求可以独立于领域模型（或者叫数据库模型、ER图，类似的东西）而单独存在。甚至可以有一个断言，脱离了领域模型的需求，必然在细节上有所缺失，而且离领域模型越远，细节的缺失就越严重。

在XP中，使用重构来解决这些细节缺失造成的问题，传统软件工程使用大量的前期需求分析和实体建模工作来解决细节问题。各有所长吧。
XP似乎是不适用于解决大规模的软件开发问题，但它可以对传统软件工程形成良好的补充。只是这时是敏捷思想对传统的补充，而不是XP对传统的补充了。

赫赫，是喔，俺的建议多半都会被采纳......

用户故事我认为是掌握agile过程，非常关键的技术，因为它涉及到了开发过程的
方方面面，从评估到计划、到度量，从意图到测试等等。

如果没有用户故事，你会缺少很多“测试先行”编程风格的动力，有了用户故事，你就不得不这样做。同时通过用户故事也能帮助你做到，交谈胜于文档，推迟细化。

我认为比较传统的需求工程，用户故事不是复杂，而是简明了很多。

实话告诉你，俺的大BOSS,自己也正在研究NGOSS,SID业务模型的问题，
我负责其他构架设计和开发过程的问题，目前有太多的东西需要穿刺了.....

有时间可以深入交流一下

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

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

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


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


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