提示：本文共有 6882 个字，阅读大概需要 14 分钟。
第1部分起步第 1 章概览。1.1 什么是用户故事？41.2 细节在哪里？1.3 “必须多长时间完成？1.4 客户团队1.5 使用故事的过程是怎么样的？1.6 规划发布和迭代1.7 什么是验收测试？…1.8 为什么要变 21.9 小结 131.10 问题 14第 2 章编写故事。152.1 独立的 152.2 可讨论的2.3 对用户或客户有价值的 182.4 可估计的2.5 小的。0202.5.1 分割故事。212.5.2 合并故事2.6 可测试的 232.7 小结 242.8 开发人员职责。252.9 客户团队职责 252.10 问题 25第 3 章用户角色建模 273.1 用户角色 273.2 角色建模的步骤 28通过头脑风暴，列出初始的用户角色集合整理最初的角色集合整合角色提炼角色，323.3 两个额外的技术虚构人物 3极端人物。343.4 如果有现场用户该如何？.353.5 小结3.6 开发人员职责。353.7 客户职责。353.8 问题。36第 4 章搜集故事74.1 引出和捕捉是不合用的 374.2 够用就行，不是吗？.384.3 方法 38用户访谈 39问卷调查 41观察。41故事编写工作坊，,424.4 小结。.454.5 开发人员职责。.454.6 客户职责。,454.7 问题。,46第 5 章与用户代理合作5.1 用户的经理。475.2 开发经理 485.3 销售人员 495.4 领域专家。495.5 市场营销团队。505.6 以前的用户。.505.7 客户5.8 培训师和技术支持 525.9 业务分析师或系统分析师 525.10 与用户代理合作时，做些什么？..52能接触到用户但访问受限时。52实在不能接触到用户时 535.11 可以自己来吗？.545.12 设立客户团队。545.13 小结 555.14 开发人员职责 555.15 客户团队职责 565.16 问题。56第 6 章用户故事验收测试 576.1 在写代码之前写测试。586.2 客户定义测试。596.3 测试是过程的一部分。.596.4 多少测试才算多？6.5 集成测试框架，606.6 测试类型 616.7 小结6.8 开发人员职责。626.9 客户职责 626.10 问题 62第 7 章优秀用户故事准则 637.1 从目标故事开始。637.2 切蛋糕。637.3 编写封闭的故事。.647.4 卡片约束 657.5 根据实现时间来确定故事规模。.657.6 不要过早涉及用户界面。,667.7 有些需求并不是故事。677.8 在故事里包括用户角色。677.9 只为一个用户编写。.687.10 以主动语态编写。.1687.11 由客户编写 687.12 向故事卡编号说“不”。687.13 不要忘记意图 697.14 小结。697.15 问题 70第二部分 估算和计划第 8 章估算用户故事。.38.1 故事点 738.2 以团队估算。748.3 估算 748.4 三角测量 758.5 使用故事点8.6 如果用结对编程呢？778.7 一些提醒 788.8 小结 798.9 开发人员职责8.10 客户职责8.11 问题第 9 章发布计划9.1 我们想在什么时候发布 89.2 希望在发布中包含哪些功能？..829.3 排列故事优先级 829.4 混合优先级 849.5 高风险故事。849.6 根据架构需要安排优先级。859.7 选择迭代长度。.869.8 从故事点到预计工期，869.9 初始速率 879.10 猜测速率。.879.11 创建发布计划 889.12 小结。889.13 开发人员职责 899.14 客户职责 899.15 问题 89第 10 章迭代计划10.1 迭代计划概览。9110.2 讨论故事。9110.3 分解任务 9210.4 准则 9310.5 承担职责 9410.6 估算并确认。9410.7 小结 9510.8 开发人员职责。.9610.9 客户职责。9610.10 问题 096第1部分起步第 1 章概览。1.1 什么是用户故事？4
用户故事描述了对用户、系统或软件购买者有价值的功能。用户故事由以下三方面组成
一份书面的故事描述，用来做计划和作为提示。有关故事的对话，用于具体化故事细节测试，用于表达和编档故事细节且可用于确定故事何时完成卡片（Card）、对话Conversation）和确认（Confirmation
1.2 细节在哪里？1.3 “必须多长时间完成？1.4 客户团队1.5 使用故事的过程是怎么样的？1.6 规划发布和迭代1.7 什么是验收测试？…1.8 为什么要变 21.9 小结 131.10 问题 14第 2 章编写故事。15故事特点：
独立的（Independent）
可讨论的（Negotiable
对用户或客户有价值的（Valuable to Purchasers or Users）
可估计的（Estimatable）
小的（Small）
可测试的（Testable
INVEST
2.1 独立的 152.2 可讨论的有着合理细节的。
一两句短语，用来提醒开发人员和客户进行对话。
一些注释，用以表明在对话中亟待解决的问题
///////////
方便讨论和工作中的沟通。
2.3 对用户或客户有价值的 182.4 可估计的？估算项目时间吗？
2.5 小的。020通常，较好的做法是像下面这样对较小的故事进行整合。
用户可以创建简历，包含教育情况、工作经历、薪资历史、出版物、演讲情况、社区服务和求职目标。
用户可以修改简历
用户可以删除简历
用户可以有多份简历。
用户可以激活简历，也可以让简历失效。
2.5.1 分割故事。212.5.2 合并故事2.6 可测试的 23成功通过测试可以证明开发人员正确地实现了故事。
应该类似可证伪性，可测试，应该有明确的指标能确定最后测试成功，有某种可以衡量的性质。
不可测试的案例：
用户必须觉得软件很好用。
用户绝不需要花很长时间等待窗口出现。
2.7 小结 242.8 开发人员职责。252.9 客户团队职责 252.10 问题 25第 3 章用户角色建模 27persona。
3.1 用户角色 273.2 角色建模的步骤 28通过头脑风暴，列出初始的用户角色集合整理最初的角色集合整合角色提炼角色，323.3 两个额外的技术虚构人物 3极端人物。34考虑极端人物很可能会让你编写出原本可能遗漏的故事。例如，很容易想象毒贩和有多个男友的女子都想要维护多份单独的时间表，以防被警察或男友看见。教皇可能没那么多保密需求，但可能想要有更大号的字。
3.4 如果有现场用户该如何？.353.5 小结3.6 开发人员职责。353.7 客户职责。353.8 问题。36第 4 章搜集故事74.1 引出和捕捉是不合用的 374.2 够用就行，不是吗？.384.3 方法 38用户访谈
问卷调査
观察
故事编写工作坊
用户访谈 39问卷调查 41观察。41故事编写工作坊，,42想象用户可能要做的事情。
在画图 4.1 的过程中，我们得到以下故事。
求职者可以发布他的简历
雇主可以发布工作
雇主可以查看提交的简历。
求职者可以搜索工作。
求职者可以看到符合搜索条件的工作。
求职者可以看到指定工作的详细信息。
但这样不是很方便。我觉得可以先从用户旅程图开始，然后确定每一个步骤需要什么样的界面和交互。这里是倒过来了，更像是对网站做分析。
在画原型的过程中，问一些有助于找到遗漏故事的问题，示例如下。
用户接下来最有可能做什么？
用户会在这里犯什么错误？
在这里，用户会有什么困惑？
用户需要什么额外的信息？
4.4 小结。.454.5 开发人员职责。.454.6 客户职责。,454.7 问题。,46第 5 章与用户代理合作有时候不能直接与用户合作，有可能开发阶段不能接触用户。
用户代理（user proxy），他们自己可能不是用户，但他们在项目里代表着用户。
5.1 用户的经理。475.2 开发经理 485.3 销售人员 495.4 领域专家。495.5 市场营销团队。505.6 以前的用户。.505.7 客户5.8 培训师和技术支持 525.9 业务分析师或系统分析师 525.10 与用户代理合作时，做些什么？..52能接触到用户但访问受限时。52请求求准许启动一个用户顾问团队（user task force）。
用户委员会？
旦建立起用户顾问团队，并且配备实际用户，它就可以用来指导每天越来越多的关于项目的决策。
实在不能接触到用户时 53使用用户代理，多个。
尽早发布产品，迭代。
5.11 可以自己来吗？.54不能。
5.12 设立客户团队。545.13 小结 555.14 开发人员职责 555.15 客户团队职责 565.16 问题。56第 6 章用户故事验收测试 57以下是一个记录在故事卡背面的测试要点的例子，“公司可以用信用卡支付发布工作的费用”这个故事卡的背面可能有以下这些测试要点
用 visa 信用卡、万事达信用卡（Master Card）和美国运通卡，America Experss测试。（通过）
用大来卡（Diner s Club）测试。（失败）
用正确的、错误的和空的卡号测试。
用过期的信用卡测试
测试不同的交易金额（包括超过信用卡额度限制）
6.1 在写代码之前写测试。586.2 客户定义测试。596.3 测试是过程的一部分。.596.4 多少测试才算多？只要这些测试还在继续为故事增加价值和使它更加清晰，客户就应该继续写测试。
6.5 集成测试框架，606.6 测试类型 61用户交互测试，确保所有用户交互组件如期工作。
可用性测试，确保程序好用。
性能测试，测量应用程序在各种负荷下的工作状况况
压力测试，使应用程序在用户和事务的极限值情况或其他任何让应用程序处在压力下的情况运行。
6.7 小结6.8 开发人员职责。626.9 客户职责 626.10 问题 62第 7 章优秀用户故事准则 637.1 从目标故事开始。63搜索她感兴趣的工作（基于她的技能、期望薪资、工作地点等）
自动搜索，以便不用每次都手动搜索
让她的简历可见，以便招聘公司能搜索到她
很容易申请她喜欢的任何工作
7.2 切蛋糕。63分解故事。
求职者可以填写简历表。
简历表上的信息被写入数据库
/////////
另一个更好的办法是换一种方式编写故事，每个故事都提供某种程度的完整（end to end）的功能。Bill Wake 2003 a）将其称之为“切蛋糕”（slicing the cake）。根据这个原则，我们可以把故事“求职者可以发布简历”像下面这样分
求职者可以提交简历，简历上只包括诸如名字、地址和教育背景这样的基本信息。
求职者可以提交简历，简历上包括雇主想看的所有信息。
7.3 编写封闭的故事。.64一个封闭的故事是指那种随着一个有意义的目标的实现而结束的故事，能让用户使用后觉得她完成了某个任务。
招聘者可以审核针对他发布的招聘广告发的简历。
招聘者可以更改招聘广告的过期日期。
招聘者可以删除不适合的申请。
7.4 卡片约束 65是对于任何必须要遵守而不需要直接实现的故事，在其故事卡上标注“约束”（constraint）。
设计的软件要便于今后实现国际化。
新系统必须使用我们现有的订单数据库
该软件必须能在所有版本的 Windows 系统上运行
该系统的无故障运行时间要求达到 99.999%
该软件要很好用。
7.5 根据实现时间来确定故事规模。.65假设我们已经决定，Bigmoney, Jobs 网站最高层次的故事有以下 4 个。
求职者可以发布简历。
求职者可以搜索职位空缺
招聘者可以发布职位空缺
招聘者可以搜索简历。
//////////////
求职者可以添加一份新简历到网站上。
求职者可以修改已经在网站上的简历。
求职者可以从网站上删除她自己的简历。
求职者可以把简历标识为激活状态。
求职者可以对特定的雇主隐藏自己的简历。
求职者可以查看她的简历被浏览过多少次。
关于发布简历的故事…
求职者可以搜索职位空缺。
招聘者可以发布职位空缺。
招聘者可以搜索简历。
7.6 不要过早涉及用户界面。,667.7 有些需求并不是故事。677.8 在故事里包括用户角色。67每个故事使用下面的格式编写：
我作为（角色），想要（功能），以此（商业价值）
7.9 只为一个用户编写。.687.10 以主动语态编写。.168例如，不要写成“简历可以被求职者发布”，而要写成“求职者可以发布简历”。
7.11 由客户编写 687.12 向故事卡编号说“不”。68如果觉得必须要给故事卡编号，那么试着给卡片加上一个简短的标题，并在其余的故事描述文本中使用这个标题作为缩写。
7.13 不要忘记意图 69故事卡的主要目的是用来提醒开发人员和客户团队对功能进行讨论的。
既然仅仅是一个提醒，就要保持它的简洁性。加入需要的细节，以便联想到继续对话的切入点，但不要在故事卡上加入太多细节并以此取代对话。
7.14 小结。697.15 问题 70第二部分 估算和计划第 8 章估算用户故事。.3无论什么时候获得有关故事的新信息，都允许我们改变之前的想法。
适用于史诗故事和小故事
不需要花很多时间。
提供进度和剩余工作的有用信息。
不太精确的估算也不会有太大问题。
可以用来制定发布计划。
8.1 故事点 738.2 以团队估算。748.3 估算 748.4 三角测量 75在估算个故事时，根据这个故事与其他一个或多个故事的关系来估算。
8.5 使用故事点8.6 如果用结对编程呢？77团队用不用结对编程，对故事点估算并没有影响。
8.7 一些提醒 788.8 小结 798.9 开发人员职责8.10 客户职责8.11 问题第 9 章发布计划大部分软件项目以每 2 到 6 个月为一个新发布周期，这是最好的。
9.1 我们想在什么时候发布 89.2 希望在发布中包含哪些功能？..82DSDM 包括一个排列优先级的方法，称之为莫斯科（Moscow）规则。Moscow 是以下短语的缩写：
必须有（Must have
应该有（Should have
可以有（Could have
这次不会有（Won t have this time
9.3 排列故事优先级 82故事不能如期完成的风险（例如，需要有预期的性能特点或全新算法时）。
推退实现一个故事时对其他故事的影响（我们不想等到最后一轮迭代才知道，应用程序是三层结构，并且是多线程的）。
此外，客户和用户对故事进行优先级排序时，也会有他们自己的要素，如下所示
故事对于广泛用户或客户的重要性。
故事对于少部分重要用户或客户的重要性。
故事与其他故事的内聚性
9.4 混合优先级 849.5 高风险故事。84应该先做最有风险的部分，还是先做最有价值的部分。
....他提倡先做“油水最多”（“juicy bits
9.6 根据架构需要安排优先级。859.7 选择迭代长度。.869.8 从故事点到预计工期，86使用速率。
例如，假设估算项目需要100个理想日,如果速率是25,我们就可以估算出完成项目需要100/25 4 轮迭代。
速率是如何算出来？以往工期是25天完成一轮吗？
9.9 初始速率 87可以通过下面三种方法获得初始速率。
使用历史值执行一轮初始迭代，使用那轮迭代的速率 猜测9.10 猜测速率。.87.....大约 1 个理想工作日为 1 个故事点。
9.11 创建发布计划 88对于工作在一起的团队，我把故事卡钉在墙上，用列来表示迭代。
对于记录在电子表格中的故事，我根据它们的迭代进行排序，然后在每轮迭代的最后一个故事后画一条厚重的粗线。
对于有兴趣的远程利益相关者，我复印记录卡给他们（三张为一页，或者减小尺寸，6 张为一页）。
对于有兴趣的，比较讲究形式的远程利益相关者，我给他们创建简单的甘特图（Gantt chart）。创建诸如“迭代 1”的入口，然后在下方列出那轮迭代中所有故事的名字。
9.12 小结。889.13 开发人员职责 899.14 客户职责 899.15 问题 89第 10 章迭代计划10.1 迭代计划概览。91迭代计划会议的一般内容如下。
讨论故事。从故事中分解出任务。开发人员承担每个任务的职责。讨论过所有故事，并且接受所有任务后，开发人员单独估计他们承担的任务以确保他们不会做出过于乐观的承诺。10.2 讨论故事。9110.3 分解任务 9210.4 准则 93如果故事的某个任务特别难于估算（例如，系统支持的数据格式列表，需要得到远程副总裁的批准），就把那个任务从故事的其余任务中分离出来。
倘若有些任务可以很容易安排给多名开发人员共同完成，就分割它们。
若有必要让客户了解故事某一部分的完成情况，可以把那部分拿出来作为ー个任务。
10.5 承担职责 9410.6 估算并确认。9410.7 小结 9510.8 开发人员职责。.9610.9 客户职责。9610.10 问题 096看到此处说明本文对你还是有帮助的，关于“用户故事与敏捷方法 豆瓣”留言是大家的经验之谈相信也会对你有益，推荐继续阅读下面的相关内容，与本文相关度极高！
