第一部分 起步

第一章概览

用户故事：卡片card         一份书面的故事描述，用来做计划和作为提示

         对话conversation  有关故事的对话，用于具体化故事细节

         确认confirmation  测试，用于表达和编档故事细节且可用于确定故事何时完成

卡片包含故事的文字描述，然后需求细节要在“对话”中获得，并在“确认”部分得以记录。

小结

故事卡包含对用户或者客户有价值的功能的简短描述。

故事卡是对故事的可见部分，但客户团队和开发人员关于故事的对话更重要。

客户团队中包含确保软件满足用户需求的所有人。这意味着客户团队可以包括测试人员、产品经理、实际用户和交互设计师。

故事卡由客户团队编写，因为他们最了解如何表达需要实现的需求，也因为他们会在后期与开发共同确定故事细节并安排故事的优先级顺序。

按照故事对客户的价值来安排故事的优先级顺序。

将各个故事放入迭代，进行发布与迭代规划。

速率velocity是开发人员可以在一轮迭代中完成的工作量。

放入一轮迭代的故事估计总和不能超过事先开发人员预计的速率。

如果故事太大以至于无法在一轮迭代中完成，可以考虑把它分成两个或更多的小故事。

验收测试用于验证实现的故事是否开发成符合客户团队的设想。

用户故事是很有意义的，因为它们强调口头交流，你和开发人员都能理解，可以用于进行迭代计划，在迭代开发过程中能很好的工作，而且因为它们鼓励推迟细节。

第二章编写故事

好的故事应该具备以下特点：

独立的independent

可讨论的negotiable

对用户或客户有价值的valuable to purchasers or users

可估计的estimatable

小的small

可测试的testable

分解复合故事两种方法：

一、按照“创建”、“编辑”和“删除”这些动作来分解故事。

二、根据数据边界来分解。

如果一个故事因为不确定性而复杂，可以将它分成两个故事：一个做调研的故事（探针试验）和一个开发故事

考虑将探针试验的调研故事和开发故事放在不同的迭代里

小结：

理想情况下，故事之间是相互独立的。有时候很难做到这一点，但我们要尽量实现这一目标。故事之间的交付顺序应该是无关的，可以任意拿一个故事来实现。

故事细节由用户和开发人员讨论得出。

故事应该很清晰地体现对用户和客户的价值。最好的做法是让客户编写故事。

故事可以注释一些细节，但是过多的细节会使故事难以理解，也可能给人一种开发人员和客户无需交谈的错觉。

给故事加上注释的最好方法就是给它编写测试用例。

如果故事太大，复合故事和复杂故事可以分成几个小的故事。

如果故事太小，几个小故事可以合并成一个较大的故事。

故事应该是可以测试的。

开发人员职责：

负责帮助客户编写故事，这些故事要能提醒你们同客户交谈，而不是记录详细的需求定义，故事应该对用户或者客户有价值，它们是独立的、可测试的、大小合适的。

如果被问及实现故事所用的技术或者基础架构信息，应该使用对客户或者用户有价值的术语描述。

客户团队职责：

负责编写故事，这些故事要能提醒你们同开发人员交谈，而不是记录详细的需求定义，它们对用户或者你们自己是有价值的，它们是独立的、可测试的、大小合适的。

第三章用户角色建模

识别、选择有用的用户角色集合：

通过头脑风暴，列出初始的用户角色集合。（已确认的角色代表的是单一用户）

整理最初的角色集合。

整合角色。

提炼角色。

两个额外的技术：虚构人物、极端任务

小结：

大部分项目小组只考虑单一的用户类型。这会导致软件忽略原本需要的一些用户类型。

为了避免从单一用户的角度编写所有用户故事，要识别与软件交互的不同用户角色。

通过对每个用户角色定义相关特征，可以更清楚地看到不同角色间的不同点。

对于有些用户角色而言，用代表人物来描述会很有帮助。虚拟人物是假想出来的用户角色代表。他们有名字，有照片，还有足够的相关细节，因为对项目成员来说，很真实。

对于有些应用程序，极端人物可能有助于搜集原本被遗漏的故事。

开发人员职责：

负责参与确认用户角色和虚构人物的过程。

负责理解每个用户角色或虚构人物，以及它们之间的异同。

开发软件时，负责考虑不同的用户角色对于软件如何运行的不同偏好。

负责确保在识别和描述用户角色时，它们只是这个过程中的工具，不应超越作为工具之外的任何用途。

客户职责：

负责寻找用户（多多益善），并识别恰当的用户角色。

负责参与识别用户角色和虚构人物的过程。

负责确保软件没有关注不恰当的用户。

在编写故事时，负责确保每个故事都能和至少一个用户角色或虚构人物联系起来。

开发软件时，负责考虑不同的用户角色对于软件如何运行的不同偏好。

负责确保在识别和描述用户角色时，它们只是这个过程中的工具，不应超越作为工具之外的任何用途。

第四章搜集故事

引出和捕捉是不合用的

拖网收集需求

一、大网眼的渔网捞一遍需求池，以此得到所有的大需求

二、需求会像鱼一样，会成长，也可能死亡。

三、正如在某区域拖网捕鱼不可能捕获所有的鱼，我们也不可能捕捉到所有需求。捞到的废弃的货物或者漂浮的残骸也会使需求膨胀。

收集需求方法：

用户访谈  访谈成功的关键之一是选择正确的受访者。  要想获取用户的本质需求，最好的技巧是提问（开放式问题和背景无关问题）。

问卷调查

观察

故事编写工作坊（良好的故事编写工作坊结合了头脑风暴的最佳要素和简单原型法）

小结：

能够引出及捕捉需求这一想法是错误的。它有两个有问题的假设：用户知道所有需求；需求一旦被捕捉，就锁定，不再改变。

拖网捕鱼的比喻是非常有用的：它说明了需求有不同的大小，需求会随着时间的推移变化，需要一些技巧来发现需求。

即使敏捷流程支持需求的后期涌现，依然需要对预期的发布进行展望并开始写下容易发现的故事。

使用多种方法比过度使用一种方法更能获得好的效果。

通过开放式、与背景无关的提问更容易获得有用的答案。

开发人员职责：

负责理解并使用多种技巧来捕捞用户故事。

负责指导怎么使用开放式和背景无关的提问。

客户职责：

负责理解并使用多种技巧来捕捞用户故事。

负责尽早写更多的用户故事。

作为软件用户的主要代表，负责和他们多沟通。

了解怎么使用开放式和背景无关的提问。

如果需要关于编写故事的帮助，负责安排并举办一次或多次故事编写工作坊。

负责确保在捕捞故事过程中考虑所有用户角色。

第五章与用户代理合作

用户的经理：有时候，用户的经理会从中干预，并且出于自负，想在项目中充当用户的角色。

开发经理：让开发经理担任用户代理，是最坏的选择之一，除非软件就是给开发经理用的。

销售人员：让销售人员充当用户代理是危险的，这会让大家对正在开发的产品没有一个全面的蓝图。

领域专家：也称主题专家，是非常重要的资源，他们对软件应用领域的了解程度对软件的成败有直接的影响。

市场营销团队

以前的用户

客户

培训师和技术支持

业务分析师和系统分析师

小结：

编写用户故事时，有各种不同类型的用户代理，但用户代理不如实际用户。

除非用户的经理也是用户，否则他就不是合适的用户代理。

开发经理会试图担任用户代理，因为他们已经参与到项目每天的细节中。然而，开发经理大多不是正在开发的软件的用户，所以他们不是理想的用户代理。

在产品公司里，客户经常来自市场团队。来自市场团队的人经常是不错的用户代理，但他们通常关注于软件的功能数目，而不是其质量，这点必须克服。

与很多不同的客户（而这些客户也是用户）联系的销售人员可以是很好的开发项目客户。销售人员必须避免把重点放在那些可以重新赢得已失去订单的故事上。在所有情况下，销售人员是与用户沟通的有效渠道。

领域专家可以成为优秀的用户代理，但是必须避免一点：在为产品编写故事时，将产品开发成只适合那些与他们有相同水平的人使用。

客户，那些做出购买决定的人，如果他们能与用户密切交流，那么他们能成为非常好的用户代理。显然，如果客户自己也是用户，那就是完美组合。

为了成为好的用户代理，培训师和技术支持人员必须避免仅仅关注产品中那些他们每天关心的方面。

与用户代理合作时：

用用户顾问团队

使用多个用户代理

分析竞争产品

尽早发布软件来获取用户反馈

开发人员职责：

负责帮助组织机构为项目物色合适的客户

负责了解不同类型的用户代理怎么考虑你们正在开发的系统，他们的背景如何影响交互。

客户团队职责：

如果你不是软件的用户，则要负责了解自己属于哪类用户代理。

负责理解自己会将哪些偏见带入到项目中，如何克服这个问题，无论是依靠别人还是其他方法。

第六章用户故事验收测试

在写代码之前写测试

一般在以下时候写测试：

开发人员和客户讨论故事且需要记录明确的细节时。

在迭代开始时，在写代码前作为一项专门的任务。

在开发中或之后的任何时候发现新的测试时。

客户定义测试

测试是过程的一部分

只要这些测试还在继续为故事增加价值和使它更加清晰，客户就应该继续写测试。

集成测试框架  （开发团队应该自动化部分或全部验收测试）FitNesse FIT

测试类型：

用户交互测试，确保所有用户交互组件如期工作。

可用性测试，确保程序好用。

性能测试，测量应用程序在各种负荷下的工作状况。

压力测试，使应用程序在用户和事务的极限值情况或其他任何让应用程序处在压力下的情况运行。

小结：

验收测试可以用来记录客户和开发人员讨论的很多细节。

验收测试记录了有关故事的一些假设，这些假设可能还没有和开发人员讨论过。

验收测试提供了检查故事是否被完整实现的基本标准。

验收测试应由客户来写而不是开发人员。

验收测试应在程序员写代码之前写好。

如果新的测试对阐明故事的细节或者意图没有任何帮助，就不用再写。

FitNesse FIT是写验收测试的优秀工具，用的是表格或者电子表格格式。

开发人员职责：

若团队觉得有需要，则负责实现自动化验收测试。

开始开发一个新的故事时，负责考虑更多的验收测试。

负责为代码做单元测试，使验收测试就不必顾及故事的每个细节。

客户职责：

负责编写验收测试

负责执行验收测试

第七章　优秀用户故事准则

从目标故事开始

切蛋糕

编写封闭的故事

卡片约束

根据实现时间来确定故事规模

不要过早涉及用户界面

有些需求并不是故事

在故事里包括用户角色　　我作为（角色），想要（功能），以此（商业价值）

只为一个用户编写

以主动语态编写

由客户编写

向故事卡编号说“不”

不要忘记意图

小结：

为了确定故事，从每个用户角色使用系统的目标开始考虑。

分割故事时，试着将他分割成贯穿应用程序所有层面的故事。

试着让故事的大小能够在使用后让用户感到可以去休息一下。

如果有项目领域和环境的需要，可以用其他需求搜集或者文档技术来补充故事。

创建约束卡，将他们贴在公共的墙上，或者编写测试来确保系统没有违反约束。

为团队即将实现的功能编写小的故事，针对未来实现的功能编写宽泛的，高层次的故事。

不要让故事过早涉及用户界面。

实际编写故事时，要包括用户角色。

只为一个用户编写

以主动语态编写

由客户编写

用户故事要简短，目的是提醒开发人员和客户进行对话。

不要给卡片编号

第二部分估算和计划

第八章估算用户故事

故事点：代表时间的模糊单位，或叫NUT（Nebulous Units of Time）可以是一个理想日的工作，也可以是一个理想周的工作。

以团队估算

故事估算应该由整个团队集体完成。一个故事包含多个任务，任务估算属于执行这个任务的人。

估算（扑克牌）

使用迭代方法进行估算

估算一个故事时，应该考虑完成这个故事需做的所有事情。全盘考虑开发，测试代码，和客户讨论，可能帮助客户计划或自动化验收测试等。

三角测量

在做了几个估算之后，我们可以（而且必要）对估算做三角测量。

具体做法是在估算一个故事时，根据这个故事与其他一个或者多个故事的关系来估算。

使用故事点

一轮迭代结束时，团队计算已完成的故事点数，这个点数可以作为下轮迭代将完成的故事点数的预报。

中央极限定理告诉我们，任意分布的独立样本数量之和是符合正态分布的。

团队用不用结对编程，对故事点估算没有任何影响。

团队可以商定约束估算只用一些预定的值。

tips：

你的团队的故事点和我的团队的故事点是不一样的。

一个故事（可能是史诗故事）分解成小故事以后，这些小的故事估算的总和不需要与开始那个故事或史诗故事的估算相等。

一个故事分解成一些任务。这些任务估算的总和不需要与故事的估算相等。

小结：

用故事点估算故事，故事点是故事复杂度、工作量或工期的相对估算。

应由团队估算故事，估算属于团队而不是个人。

通过和其他估算进行比较来进行三角测量。

团队是否使用结对编程对故事点估算没有影响。结对编程影响的是团队的速率，不是他们的估算。

开发人员职责：

负责用一个方式定义故事点，并且对团队可用和相关的。努力保证这个定义的一致性。

负责给出诚实的估算。不屈服于诱惑或者压力而给出低的估算。

负责以团队估算。

负责估算应与其他估算一致。即所有2点的故事都应差不多。

客户职责：

负责参加估算会议，但是你的任务是回答问题并澄清故事细节。你不必参与故事估算。

第九章  发布计划

产品的开发路线图可以很简单，它可以是未来几个发布要关注的重点列表，或者是“主题”（Theme）。

如果一个团队做发布计划时能以一个可接受的日期范围为起点，那么他们的发布时间将更灵活。

希望发布中包含哪些功能？

DSDM方法，它是另一种敏捷过程。

DSDM包括一个排列优先级的方法，称为莫斯科（MoSCow）规则。

必须有（Must have）

应该有（Should have）

可以由（Could have）

这次不会有（Won't have this time ）

排列故事优先级

通过多维度为故事排列优先级：

故事不能如期完成的风险

推迟实现一个故事时对其他故事的影响

客户和用户对故事进行优先级排序时，也有自己的要素：

故事对于广泛用户或客户的重要性

故事对于少部分重要用户或客户的重要性

故事与其他故事的内聚性（如故事“缩小”本身可能并不是高优先级的，但可以将它看成是高优先级的，因为它是高优先级故事“放大”对应的功能）

混合优先级

如果客户在确定一个故事的优先级时遇到问题，可能需要分割这个故事。分割故事能使客户对独立的故事排列出不同的优先级。

高风险故事

软件开发争议，对项目来说最先做有风险的部分，还是最先做有价值的部分

敏捷方法旗帜鲜明地支持先做最有价值的部分。

即使以价值优先为导向，我们在排列故事优先级时仍然需要考虑风险。

根据架构需要安排优先级

高风险故事经常与基础性或非功能性需求有关，如性能需求。

开发人员应该帮助客户识别那些可以推迟实现，但越晚实现开发成本可能会非常高的故事。但开发人员不能滥用这种影响力，引导客户同意尽早实现他们喜欢的技术性功能。

选择迭代长度

开发人员和客户共同选择适合他们的迭代长度。通常一至四周。

从故事点到预计工期

使用速率将故事点转换成项目的预计工期

初始速率

如下三种方法获得初始速率：

使用历史值

执行一轮初始迭代，使用那轮迭代的速率

猜测

猜测速率

因为各种干扰，把一轮迭代三分之一到一半的开发日作为预计速率是很常见的。

创建发布计划

利用发布计划可以设立初始期望，但之后如果获得新的信息，应该不断重新调整期望。

小结：

在计划发布时，有必要知道客户预期的大致发布日期和故事的相对优先级。

故事应该以明确的顺序排列（第一个、第二个、第三个等等），而不是利用诸如“非常高、高、中等”模糊顺序的分组。

故事的优先级有客户确定，但也要考虑开发人员的想法。

使用速率将以理想日为单位的估算转换成日历日。

估算团队的初始速率是很有必要的。

开发人员职责：

负责提供信息（有时包括基本假设和可能的替代方法）给客户，以帮助他排列故事优先级。

负责在基础性需求或者架构性需求与其他客户需求之间取得权衡，避免不切实际地提高基础性需求或者架构性需求的优先级。

建立发布计划时，负责在实际估算的基础上，适当包括一定长短的时间用以项目缓冲。

客户职责：

负责以自己对故事价值的估计来确切排列用户故事的优先级。把故事排列为高、中、低这三个优先级是不够的。

负责诚实地表达发布期限。如果在7月15日需要，请不要为了保险起见告诉开发人员6月15日就需要。

负责理解理想日和日历日的不同。

在想对故事的不同组件排列不同的优先级时，负责分割故事。

负责了解为何不应该谴责或批评一位个人速率为0.6的程序员，只因为他的速率小于1.0。

第十章  迭代计划

迭代计划概览

整个团队通过举行迭代计划会议来为下一轮迭代做计划。客户以及团队中的所有开发人员（程序员，测试人员和其他人）都要出席这个会议。

迭代计划会议的一般内容如下：

1.讨论故事

2.从故事中分解出任务

3.开发人员承担每个任务的职责

4.讨论过所有故事，并且接受所有任务后，开发人员单独估计他们承担的任务，以确保他们不会做出过于乐观的承诺。

讨论故事

迭代计划会议是客户为团队调整故事优先级的最佳时机。

分解任务

为何要做分解呢？（故事到此阶段已经比较小了，一般只占用项目普通程序员1-5个理想日）

首先，对于很多团队来说，实现故事的开发人员不止一个（或者是一对开发人员）；

其次，故事是对用户或客户有价值的功能描述，它们并不是开发人员的待办事项（to-do list）；

敏捷过程的特点是做频繁的短期设计。一个故事的任务分解其实是即时设计（just in time design）中的一次短脉冲，而这些短脉冲的集合取代了瀑布过程的前期设计阶段。

准则

故事一半已经足够小了，所以没有必要围绕任务的期望大小设定非常精确的准则。

分解任务时使用如下准则：

1.如果故事的某个任务特别难估算，就把那个任务从故事的其余任务中分离出来。

2.  倘若有些任务可以很容易安排给多名开发人员共同完成，就分割他们。

3.  若有必要让客户了解故事某一部分的完成情况，可以把那部分拿出来作为一个任务。

承担职责

确定所有任务后，开发人员在任务上写上自己的名字认领任务。

即使采用结对编程，每个任务通常也最好只关联一个人的名字。此人将承担完成任务的责任。

估算并确认

最好的方法仍是以理想时间估算。

每个开发人员必须能够放心地承诺完成自己将要承担的工作，而且，由于整个团队必须同舟共济，所以每个人都必须对整个团队做出的承诺有把握。

小结：

迭代计划是发布计划的进一步计划，但只在迭代即将开始时才开始做迭代计划。

迭代计划中，团队讨论每个故事，然后从故事中分解出任务。

任务的大小没有强制的范围。相反，从故事中分解出任务，用来帮助估算或鼓励多个开发人员合作完成一个故事。

每个任务都有开发人员承担。

开发人员通过估算他们承担的任务，评估他们是否承诺过度。

开发人员职责：

负责参加迭代计划会议。

负责帮助把所有故事划分为任务，而不只是自己想做的故事。

负责为认领的任务承担责任。

负责确保承担适当工作量的工作。

在整轮迭代中，负责监控自己剩余的工作，同时也要监控队友剩余的工作。如果很快就能完成自己的工作，就有责任帮助队友承担部分工作。

客户职责：

负责对迭代中包含的故事排列优先级。

负责指导开发人员交付他们能提供的最大商业价值。这意味着，从发布计划设定之后，若有更高价值的故事，要负责调整优先级以交付最大的商业价值。

负责参加迭代计划会议。

第十一章测量并监控速率

一轮迭代完成的故事点就是项目的速率。

测量速率

 注意不要过早地调整发布计划。不仅仅因为是最初的速率往往不准确，而且速率在初期的迭代中也很不稳定。可能需要两三轮迭代之后，才能获得一个长期的、比较稳定的速率。

大家一起先完成一些故事比所有故事都只完成一部分更有价值。

计划速率和实际速率

为每轮迭代画出计划速率和实际速率

迭代燃尽图（burn down chart）

迭代燃尽图展示了以故事点表示的在每轮迭代末剩余的工作量

迭代中燃尽图

在迭代中，每日燃尽图可以展现在迭代内剩余的估算小时。

小结：

计算速率时只考虑那些已完成的故事，即通过验收测试的故事。不要计算迭代中团队未全部完成的故事。

为每轮迭代计划和实际完成的故事点数画图是监测实际和计划速率区别的好方法。

不要在一两轮迭代后就忙着预测速率趋势。

完成一个任务或故事所花费的实际小时数对速率没有影响。

在大家都能看到的公共区域贴一些大而可见的图。

累计故事点图很有用，可以从中看出每轮迭代中完成的故事点。

迭代燃尽图展示了用完成的故事点表示的进度和剩余故事的改变。

每日燃尽图在迭代中十分有用，他展示了迭代中每天剩余的小时数。

设计及检测一个平均每个故事点出现缺陷数目的图表可以帮助我们发现团队速率的提高是不是以牺牲质量为代价。

开发人员职责：

尽量在完成一个故事后再去做下一个故事。更希望看到少量已完成的故事，而不是较多未完成的故事。

清楚所做的任何决定对项目速率的影响。

理解本章所讲的所有图（计划速率和实际速率图、计划故事点和实际故事点图、迭代燃尽图、迭代中燃尽图）

经理或者极限编程项目中的追踪者，应知道怎样以及在什么时候画本章的这些图

客户职责：

理解本章所讲的所有图

知道团队的速率

知道实际速率和计划速率的差别和是否需要调整计划

为发布添加或删除故事，以确保团队在种种限制条件下尽量多实现项目目标。

第三部分经常讨论的话题

第十二章故事不是什么

故事区别于其他三种常见的需求方法：用例（user case）、IEEE830软件需求规格（software requirements specifications）和交互设计场景（interaction

design scenario）

用户故事不是IEEE830

电气与电子工程师协会下面的计算机学会出版过一本关于如何编写软件需求规格的指南（IEEE830）。

IEEE830样式的需求侧重于关注需求的检查清单（checklist），而不是用户的目标。IEEE830文档其实是需求列表，故事则描述用户目标。另一个不同是IEEE830会有冗长的需求编写时间，这期间开发人员完全无法开始开发，且IEEE830在写下所有需求前，每个需求的成本是不可见的。

用户故事不是用例

用例是对系统之间以及一个或多个用户之间交互的一般性描述，使用者要么是用户，要么是系统。主要成功场景是用例成功路径的描述。扩展部分定义了用例的其他路径。

故事与用例之间最明显的区别是他们的范围。两者的大小都以交付商业价值为目标，但故事的范围更小，因为故事的大小有限制（不超过10个开发工作日）。用例覆盖的范围几乎总比故事大。

用户故事和用例的不同还在于它们的完整性。

用例和故事之间另一个更重要的区别是它们的寿命。只要产品在开发或维护，用例常常作为永久性的“工作”持续存在。而故事不会超过包含它们的迭代。

用例和用户故事还有一个区别是，它们的目的不同。用例编写成客户和开发人员都可以接受的格式，大家都可以读懂并达成一致，目的是记录客户和开发团队之间的协议。而编写用户故事是为了更方便发布计划和迭代计划，并且它充当着用户具体需求对话的占位符。

用例一般写成分析活动的结果。用户故事则写成注释，用以启动分析谈话。

用户故事不是场景

场景是用户与计算机交互的详细描述。

用户故事和场景的主要区别是范围和细节。场景包含更多细节，它们的范围通常涵盖多个故事。

尽管场景往往包含更多细节，它（像故事一样）也是鼓励通过讨论获得更多的细节。

小结：

用户故事有别于IEEE830软件需求规格、用例和交互设计场景。

不管预想的多么全面，我们都无法实现完全定义一个完整的具有相当规模的系统。

在定义需求和用户早期频繁接触软件之间，有一个有价值的反馈循环。

考虑用户的目标比列出方案的特性更重要。

用户故事与用例场景类似。但用例往往仍然比单个故事要大，更容易包含关于用户界面的嵌入式假设。

此外，用户故事与用例的完整度和寿命不同。用例比用户故事完整得多。用例存在于整个开发过程中。用户故事往往只是暂时的，它们的生命周期仅仅限于开发它们的迭代中。

用户故事和用例以不同的目的编写。用例被编写成方便开发人员和客户讨论并达成共识。用户故事编写成方便计划发布，并用于提醒需求细节的讨论。

不像IEEE830规格和用例，用户故事不是分析活动的产物。相反，用户故事是进行分析的支持工具。

交互式设计场景比用户故事具体得多，他们提供的细节类型也不同。

典型的交互式设计场景比用户故事大得多。一个场景可以由多个用例组成，相应地，他可以组成许多用户故事。

第13章用户故事的优势

用户故事强调口头沟通

人人都可以理解用户故事

用户故事的大小适合做计划

用户故事适合于迭代开发

用户故事鼓励延迟细节

用户故事支持随机应变的开发

用户故事鼓励参与性设计

用户故事传播隐性知识

用户故事的不足：

1. 拥有大量用户故事的大型项目中，故事之间的关系可能错综复杂，难以捉摸。可以使用角色淡化此问题。

2. 如果开发过程规定要有需求的可追溯性，必然离不开额外的文档。

3. 虽然故事在一个团队内部能大大促进隐性知识的积累，但是还不适用于特大规模多团队的结构。

第十四章用户故事不良症兆一览

故事太小

故事互相依赖

镀金

细节太多

过早考虑用户界面细节

想得太远

故事划分太过频繁

客户很难为故事安排优先级

客户不愿意写用户故事，也不愿意为故事安排优先级

第十五章 Scrum与用户故事

Scrum是迭代和递增的

一轮迭代的过程是一种持续改进的过程。

一个递增的软件过程是指团队按照功能点开发和发布软件。每个功能点，或者称为功能增量，代表一个完整的功能子集。

Scrum和极限编程都是基于递增和迭代方式的过程

Scrum基础

sprint backlog

product backlog

每日Scrum简会（Daily Scrum）

Scrum团队

一个Scrum团队通常由4-7个开发人员组成。

Scrum团队往往是自组织的。

产品负责人和ScrumMaster

产品负责人主要负责管理Product Backlog的内容以及排列优先级。

ScrumMaster的职能类似于项目经理，只不过他不是管理者的角色，更像一个领导者。主要负责为团队排除障碍，保证开发的顺利进行，确保整个团队按照Scrum的简单规则进行开发。

产品Backlog

产品Backlog是所有待开发产品功能的列表。

Sprint计划会议

在每个Sprint的开始是Sprint计划会议。这个会议通常持续一整天。

在Sprint计划会议的前半段，产品负责人会把待开发的高优先级的功能介绍给Scrum团队。

如果团队有信心完成某一功能，就把这个功能从产品Backlog移到Sprint Backlog。

在Sprint计划会议的下半段，团队会讨论这些用户故事，决定下一轮迭代能够完成的工作量。

有的团队也会选择最高优先级的五个故事，然后又选了两个低优先级但与前五个故事有关的故事。一般情况下，团队会和产品负责人沟通，但是由团队决定一个Sprint能够完成多少。

Scrum的主要规则：

在Sprint开始的时候召开Sprint计划会议。

每个Sprint必须发布可以工作的、经过测试的代码，这些代码能够完成对最终客户有价值的一些功能。

产品负责人为产品Backlog排列优先级。

团队一起决定一轮迭代完成多少故事。

在任何时候都可以向产品Backlog中添加故事，或者重新排列优先级。

每天有一个Scrum短会。每个项目成员回答三个问题：我昨天做了什么？我今天打算要做什么？我有什么困难？

只有团队成员能在每日Scrum简会中发言，其他人包括对项目感兴趣的观察者或利益相关者都不能发言。

在Sprint结束时的Sprint评审会议中，团队会演示完成的成果。

团队演示的是可以工作的软件，而不是幻灯片。

准备Sprint评审会议的时间不得超过两小时。

一旦Sprint开始，只有团队成员才能向Sprint中添加工作。即使是CEO也不能让团队去做产品负责人没有提出的工作。

团队从产品Backlog中选择故事之后，会从故事中划分出任务，形成SprintBacklog。

Sprint评审会议

每个Sprint都要发布一个“潜在可以交付的产品功能增量”。

尽管商业软件分销商可能考虑到升级的困难，而不愿意每个月都给客户升级。但Scrum团队还是必须每个月发布可以上线的版本。

在每个Sprint结束时，都会有一个Sprint评审会议。团队演示在Sprint中完成的工作，经常是新功能演示。

Sprint评审会议是非正式会议性质，尽量不使用幻灯片，准备时间不超过两小时。

整个团队包括产品负责人和ScrumMaster都要参加Sprint评审会议。其他任何人如果感兴趣也可以参加。

在Sprint会议中，大家一起评估是否达到了在Sprint计划会议上设定的Sprint目标。

每日Scrum简会：

等所有项目组人员到齐后，每日Scrum简会安排得越早越好。一般安排在9：00或者9：30.所有项目人员（开发人员、测试人员、产品负责人和ScrumMaster）都必须参加。会议必须简短，一般在15分钟内结束，最多不超过30分钟。

每日Scrum简会：

1. 昨天做了什么

2. 你今天有什么打算

3.  有什么困难

会议不是像ScrumMaster汇报工作，会议的一个重要目的是让每个人在自己以及同事面前做出承诺。这个承诺是团队成员之间的承诺。

ScrumMaster需要保证会议的快节奏，确保所有人只回答这三个问题。产品负责人也需要向其他团队成员一样汇报进度。

会议的另一个好处是他可以作为一个随机的检查点（checkpoint），高层管理人员和其他人如果有兴趣了解项目状况，都可以参加。会议中只有项目组内部人员才能够提问。

在Scrum中使用用户故事

Scrum和产品backlog

产品Backlog中每一个故事必须对客户或者产品负责人有价值。

首先确定用户角色，然后根据角色来收集故事，在Scrum中应用十分有效。

在Sprint计划会议中使用用户故事

团队确定在下一个Sprint中需要完成的条目，然后向产品负责人作出承诺。然后把这些故事划分为小的任务，方便在Sprint中由程序员认领。

在Sprint评审会议中使用用户故事

在每日Scrum简会中使用用户故事

小结：

Scrum是一种迭代和递增的过程。

Scrum的一轮迭代称为Sprint。

ScrumMaster相当于传统的项目经理，但更像是领导者和组织者，而不是经理。

一般的Scrum团队包括4-7个开发人员。

产品Backlog是一个待开发的功能需求列表，里面的条目要么还没有实现到产品中，要么还没有计划在当前的Sprint中开发。

Sprint Backlog是一个团队承诺在当前Sprint完成的任务列表。

在极限编程里面的客户角色，在Scrum中称为产品负责人。

产品负责人负责给产品Backlog排列优先级。

在Sprint的开始，团队从产品Backlog中选择下一个Sprint要完成的任务。

每日Scrum简会：昨天做了什么；你今天有什么打算；有什么困难

每个Sprint都要完成一部分可以潜在交付的产品功能增量。

在Sprint结束时，团队在Sprint评审会议上演示完成的功能。

第六章其他话题

处理非功能性需求

大多数项目一般都会有一部分需求无法恰当的以故事形式来表达，这些往往是系统的非功能性需求。

常见的非功能性需求类型如下：

性能performance

准确性accuracy

可移植性portability

可重用性reusability

可维护性maintainability

互操作性interoperability

可用性availability

易用性usability

安全性security

容量capacity

许多非功能性需求可以视为系统行为的约束。处理约束最好的办法是在卡片上写下约束，并将卡片标注为“约束”卡。如果系统确定要有更多非功能性需求，可以用任何合适的或传统的形式来沟通。

纸质还是软件？

建议从卡片开始，看看是否适用于具体环境。然后，如果有令人信服的理由使用软件，则切换软件。

用户故事和用户界面

用户角色建模

捕捞高层次的用户故事

排列故事优先级

精炼高优先级和中等优先级的故事

对故事整理分组

建立书面的原型

精炼该原型

开始编程

保留故事

建议保留故事卡片，或者用软件来保存故事。

缺陷的用户故事

把每个缺陷报告当成自己的故事。如果修正缺陷很可能会花费完成典型故事所需的时间，就可以像任何其他故事那样对待那个缺陷。但是，对于那些团队期望能够快速修复的缺陷，应该把那些缺陷合并到一个或多个故事中。

小结：

非功能性需求（性能、准确性、可移植性、可重用性、可维护性、互操作性、可用性、易用性、安全性、容量等）都可以通过创建约束卡的方式处理。假如系统的需求比这些更复杂，但无论其他格式还是方法，只要它能充分表示那些需求，就可以用作用户故事的补充。

笔记卡和软件系统都不是适用于所有情况下编写故事的最佳方式。使用适合项目和团队的工具。

迭代过程会导致用户界面的反复变动。习惯于特定界面的用户，不会喜欢用户界面的变动，因为这会影响他们已经学会的操作软件的方法。可以考虑加入一些敏捷版已使用为中心的设计实践，以避免用户界面的反复变化。

一旦故事完成，撕毁故事卡会有一定的乐趣。但同样也有保留卡片的理由。宁可谨慎一些，保留故事。

把小的缺陷报告用一个封面故事卡装订在一起，并把他们当成一个单一的故事。

开发人员职责：

在适当的时候，建议并使用替代技术和方法来表示需求。

共同决定适用于项目的方式：笔记卡还是软件系统。

共同理解在项目开始时考虑所有用户界面的优点和缺点。

客户职责：

如果觉得用户故事无法准确地反映需求的一部分，应该要求使用替代技术和方法来表示。

共同决定适用于项目的方式：笔记卡还是软件系统。

共同理解在项目开始时考虑所有用户界面的优点和缺点。

一个案例：

用户角色：定义客户→定义一些角色雏形→整合与提炼→角色建模→添加虚构人物

一些故事：虚构人物的故事和各角色故事（别忘了管理员的一些故事）

估算故事：初始故事集合→第一个故事（每个人写下对故事的估算）→完成估算→完成所有估算

发布计划：

1.  确定迭代长度

2.  估算速率

3.  给故事安排优先级

4.  将故事分配到一轮或多轮迭代中

估算速率→给故事安排优先级→最终发布计划

验收测试

极限编程（Extreme Programming XP）概览

角色

XP

的客户角色负责编写故事、排列故事优先级以及编写和执行验收测试，并与开发团队坐在一起，已验证故事按照预期进行开发。XP客户可以是系统的用户，但也可以不是。如果不是用户，XP的客户往往是产品经理、项目经理或业务分析师。

XP项目中，程序员和测试人员之间的区别是模糊的。

XP的程序员角色拥有广泛的技术技能。XP项目往往不区分程序员、设计师、数据库管理员等角色。所有程序员以团队为单位一起工作，并一起承担责任，这些责任在非XP项目中可能会指派给特定的人。几乎所有过程都期望程序员对他们的代码进行单元测试，XP尤其重视这一点，并期望程序员对他们编写的所有代码开发自动化单元测试。

最后，许多XP团队都受益于使用XP教练和（可能的话）项目经理这两个角色。有时候，这些角色合为一体。教练负责监控团队应用XP实践的情况，在团队偏离时逐步调整进而将团队带回正确的轨道。项目经理更像是排头兵而不是经理，他负责防止团队的官僚作风，并千方百计地为团队移除障碍。

12个实践

短交付周期（small release）

计划游戏（the planning game）

重构（refactoring）

测试（testing）

结对编程（pair programming）

持续一致的速度（sustainable pace）

团队代码所有权（team code ownership）

编码标准（coding standard）

简单设计（simple design）

隐喻（metaphor）

持续集成（continuous integration）

现场客户（on-site customer）

极限编程的价值

沟通（communication）、简单（simplicity）、反馈（feedback）和勇气（courage）

极限编程的原则

快速反馈（rapid feedback）

假设简单（assuming simplicity）

增量变化（incremental change）

拥抱变化（embrace change）

高品质的产品（doing quality work）