什么是Epic？
Epic是史诗故事，通常需要花费多个Sprint来开发和测试，才能完成最终的交付。它通常范围比较大而细节描述较少，Epic的粒度比较大，在团队开发前通常需要拆分成多个更小的用户故事。
假如构造月度销售报表科目时，可能有这样的史诗故事：“作为销售经理，我希望能分区域看销售数据”。
什么是Theme？
Theme是指主题故事，是一组相关的用户故事的集合。Epic通常比较大，会分解出很多个小的用户故事，我们可以根据这些故事的相关性，通过Theme主题故事对其进行分组。
什么是Story？
Story是User Story的简称，用户故事是从用户的角度来描述用户渴望得到的功能。
用户故事通常按照如下的格式来表达：
英文：
As a <Role>, I want to <Activity>, so that <Business Value>.
中文：
作为一个<角色>, 我想要<活动>, 以便于<商业价值>
举例：
作为一个“网站管理员”，我想要“统计每天有多少人访问了我的网站”，以便于“我的赞助商了解我的网站会给他们带来什么收益。”
需要注意的是用户故事不能够使用技术语言来描述，要使用用户可以理解的业务语言来描述。
一个好的Story遵循INVEST原则：
独立性（Independent）— 要尽可能的让一个用户故事独立于其他的用户故事。
可协商性（Negotiable）— 一个用户故事的内容要是可以协商的，用户故事不是合同。
有价值（Valuable）— 每个故事必须对客户具有价值（无论是用户还是购买方）。
可以估算性（Estimable）—开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。
短小（Small）— 一个好的故事在工作量上要尽量短小
可测试性（Testable）—一个用户故事要是可以测试的，以便于确认它是可以完成的。
Epic／ Theme ／Story 管理示例：

一、什么是用户故事
    用户故事描述了对用户、系统或软件购买者有价值的功能。一个好的用户故事包括三个要素：
    1.角色：谁要使用这个功能。
    2.功能：需要完成什么样的功能。
    3.价值：为什么需要这个功能，这个功能带来什么样的价值。

    用户故事通常按照如下的格式来表达：

　 英文：As a <Role>, I want to <Activity>, so that <Business Value>.
　 中文：作为一个<角色>, 我想要<功能>, 以便于<商业价值>
    举例：“作为招聘网站注册用户，我想要查看最近3天发布的招聘信息，以便于我看到最新的招聘信息”。
    由于用户故事的描述信息以传统的手写方式写在纸质卡片上，所以Ron Jeffries(2001)对这三个方面称为3C：卡片(Card)、对话(Conversation)和确认(Confirmation)。
    卡片（Card）：用户故事一般在小卡片上写着故事的简短描述，工作量估算等。
　 交谈（Conversation）：用户故事背后的细节来源于和客户或者产品负责人的交流沟通。
    确认（Confirmation）：通过验收测试确认用户故事被正确完成。
二、如何编写用户故事
    故事应该很清晰地体现对用户或客户的价值，最好的做法是让客户团队来编写故事。客户团队应包括能确定软件最终用户需求的人，可能包括测试者，产品管理者，真实用户和交互设计师。因为他们处于描述需求的最佳位置，也因为随后他们需要和开发者一同设计出故事细节并确定故事优先级。
    为了构造好的用户故事，我们关注六个特征。一个优秀的故事应该具备以下特点：
    独立的（Independent）— 我们要尽量避免故事间的相互依赖。在对故事排列优先级时，或者使用故事做计划时，故事间的相互依赖会导致工作量估算变得更加困难。通常我们可以通过两种方法来减少依赖性：1.将相互依赖的故事合并成一个大的、独立的故事；2.用一个不同的方式去分割故事。
    可讨论的（Negotiable）— 故事卡是功能的简短描述，细节将在客户团队和开发团队的讨论中产生。故事卡的作用是提醒开发人员和客户进行关于需求的对话，它并不是具体的需求本事。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。
    对用户或客户有价值的（Valuable）— 用户故事应该很清晰地体现对用户或客户的价值，最好的做法是让客户编写故事。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。
    可估算的（Estimable）—开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：1.开发人员缺少领域知识；2.开发人员缺少技术知识；3.故事太大了。
    小的（Small）— 一个好的故事在工作量上要尽量小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。
    可测试的（Testable）— 故事必须是可测试的。成功通过测试可以证明开发人员正确地实现了故事。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：用户必须觉得软件很好用。 

拆分方法
1，可以考虑从软件--功能（feature)--子功能（sub-feature)--故事（user story)--任务（task)的拆分方法。好处是feature是传统软件范围定义的方法，比较好入手。
2，头脑风暴项目中存在哪些角色(role)。比如不同的用户，系统维护者等。并对role进行行为分析后，合并产生最终用户画像。
3，在feature层面，考虑不同role产生的user story。一般考虑系统的逻辑或流程进行分解。近期的可以细化到增、删、改、查的颗粒度。如：作为商品维护者，可以增加/删除/修改/查看一个商品的信息。

那么应该怎么拆呢？
我这里提供一个思路，大家可以揣摩一下。
大的User Story：
作为一个用户，我希望可以找到满足条件的书籍信息，以便我可以在书架上找到它。
第一个 User Story：
作为一个用户，我希望可以通过图书名称找到图书的书名、作者、馆藏状态以及索书号信息，以便我可以在书架上找到它。
第二个 User Story：
作为一个用户，我希望可以通过图书作者找到图书的书名、作者、馆藏状态以及索书号信息，以便我可以在书架上找到它。
或者这么拆：
大的User Story：
作为一个用户，我希望可以找到满足条件的书籍信息，以便我可以在书架上找到它。
第一个 User Story：
作为一个用户，我希望可以通过图书名称找到图书的书名以及索书号信息，以便我可以在书架上找到它。
第二个 User Story：
作为一个用户，我希望可以通过图书作者找到图书的书名、作者、馆藏状态以及索书号信息，以便我可以在书架上找到它。

拆分故事类型？
按工作流程：比如请假流程，可以把简单的首尾故事先切分出来，创建请假单，审批请假单，然后中间各个环节的审批流转作为独立的故事。
按功能操作：比如一般的后台报表都有增删改查的功能，可以按增删改查来切分。
按功能类型：比如接在线支付，微信、支付宝、银联可以拆分为3个故事来完成，当然每个下面还可以再切。
按内容范围：比如酒店详情页，先支持查看酒店基本信息和价格，再支持查看周边交通，地图位置等。
按用户需求层次：把性能和稳定性方面的考虑拆分成独立的新故事；

三、用户角色建模

    在很多项目中，需求分析人员只是从一个角度编写用户故事，这样往往容易忽略一下需求(故事)。所以在编写用户故事前识别用户角色和虚拟人物(Persona)有很多好处。
    以下是招聘网站可能出现的用户角色列表：
  
    角色建模的步骤：
    1.通过头脑风暴列出初始的用户角色集合：每个人要做的只是尽量在卡片上写出自己想到的角色。
    2.整理最初的角色集合：对于有重叠的角色，把它们相应的卡片重叠在一起。
    3.整合角色：在角色分组完成后，试着整合及浓缩角色。
    4.提炼角色：一旦我们整合好角色，并且对角色之间的关系有了一个基本的了解，就有可能通过给每个角色定义一些特征来建立角色的模型。
 
    虚拟人物，可以考虑一两个主要的用户角色写下虚拟人物定义，从虚拟人物的角度描述会使故事变得更加生动。 
四、如何搜集故事
用户需求并不容易得到，因为用户并不知道所有的需求，所有不能单靠用户给我们解释需求。Robertson 和 Robertson(1999)引入了拖网(trawling)这个词来描述收集需求的过程，要像“拖网渔船捕捞鱼”那样来收集需求。
首先，不同大小的网用来捕获不同大小的需求。第一遍，我们可以用大网眼的渔网捞一遍需求池，以此得到所有的大需求。通过这些大需求，形成对软件的整体感觉。接下来，用网眼稍微小一些的渔网得到中等大小的需求。
其次，需求会像鱼一样，会成长，也可能会死亡。今天渔网可能会漏掉一个需求，因为这个需求对于系统来说不重要。但是，根据每轮迭代的反馈，系统会朝着事先不可预知的方向发展，有些需求会变得越来越重要。
第三，在某一区域拖网捕鱼不可能捕获到所有的鱼，我们也不可能捕获所有需求，也可能捞到一些废弃的货物或漂浮的残，这会使需求膨胀。
最后，技能也是发现需求的一个要素，一个熟练的需求分析人员知道要到哪里去找需求。
故事会随着项目的进展而演进，所以我们可以通过用户访谈、观察用户、问卷调查和举办故事编写工作坊来发现用户故事。另外通过开放式、与背景无关的提问更容易获得有用的答案，例如：“告诉我你想怎么搜索工作？”就胜于“你要通过职位名称来搜索工作吗？”
 
五、与用户代理合作
对于一个项目来说，客户团队里包括一个或多个真实用户是极其重要的。但是但我们无法接触到他们时，我们就需要求助于用户代理(User Proxy)，选择合适的用户代理对于项目的成功至关重要。
    用户的经理：如果用户的经理不是软件的实际用户，并从中干预产品功能的开发。这种情况下，务必小心，不要得罪该用户经理，在部分围绕她的同时，想办法接触终端用户。
    开发经理：让开发经理担任用户代理，是最坏的选择之一，除非你们开发的软件就是给开发经理用的。
    销售人员：让销售人员充当用户代理是危险的，这会让大家对正在开发的产品没有一个全面的蓝图。然而，销售人员是非常好的中转站，应该让他们通过电话或销售拜访把你介绍给客户。
    领域专家：领域专家很适合做用户代理，但要避免最终开发出来的软件仅仅针对那些与领域专家有类似水平的用户。
    市场营销团队：他们可能更关注软件特性的数量而不是质量。他们可以为相关故事的优先级提供高层次的指导意见，但他们往往不具备很好的洞察力，无法给提供故事的具体细节。
    以前的用户：应谨慎考虑她的目标和动机是否与实际用户的完全一致。
    客户：考虑客户的期望是很重要的，因为开支票买软件的人是他们，而不是用户。
    培训师和技术支持：由培训师和技术支持人员来充当用户代理看似是合乎逻辑的，不幸的是，他们做用户代理，你的系统最终将只成为一个易于培训系统或只是使得技术支持工作变得较为容易，而不是功能最大化服务于最终用户。
    业务分析师或系统分析师：许多业务和系统分析师是很好的用户代理。他们唯一缺点是遇到问题喜欢空想，偶尔会在项目前期花太多时间做产品计划。
    与用户代理合作时，做些什么？
    1.能接触到用户但访问受限时：最好可以申请由部分用户组成一个用户顾问团队。
    2.实在不能接触到用户时：必须求助于用户代理；如果有竞争产品，也可以用其做一些故事的来源。
    3.避免陷入思维的误区：知道用户的想法，所以不需要或可以忽略用户代理。
六、用户故事验收测试
    编写验收测试有很多好处，其一就是很多客户和开发人员讨论的细节可以通过验收测试记录下来。测试的要点记录了客户提出的一些假设，也提供了确认故事是否被完整实现的基本标准。
在写代码之前写测试
    考虑每个故事，然后问类似下面的一些问题：
    1.关于这个故事，程序员还需要知道什么？
    2.对怎么实现这个故事，我的想法是什么？
    3.有没有一些特殊情况会使这个故事有不一样的行为？
    4.这个故事在什么情况会出错？
    客户定义测试
    客户可以和程序员与测试人员合作创建测试，但客户至少应该给我们详细指出一些测试，用以验证故事的实现是正确的。
    测试是过程的一部分
    测试时开发过程中的一部分，这点对使用用户故事非常重要。一般情况下，产品经理和测试人员共同负责列出详细的测试。产品经理带来驱动项目的公司目标的知识；测试人员则带来怀疑的心态。
    多少测试才算多？
    只要这些测试还在继续为故事增加价值和使它更加清晰，客户就应该继续写测试。同时，一个优秀的开发团队会为很多详细的用例编写单元测试。
    集成测试框架
    客户负责引领系统的开发。同时，在每轮迭代时都执行以往迭代的所有测试时非常重要的，开发团队应该自动化部分或全部验收测试。FIT和FitNesse是写验收测试的优秀工具。
    测试类型
    测试类型有很多，故事测试主要是功能性的测试，用来确定应用程序是如期运行的。
七、优秀的用户故事准则
    优秀用户故事的一些准则：
    1.试着让故事的大小能够在使用后让用户感到可以去喝杯咖啡休息一下；
    2.不要让故事过早涉及用户界面；
    3.实际编写故事时，要包括用户角色；
    4.用主动语态编写故事；
    5.为单个用户编写故事；
    6.让客户编写故事，而不是开发人员；
    7.用户故事要简短，它们只是提醒开发人员和客户进行对话；
    8.不要给故事卡添加编号。
八、用户故事的估算
    以故事点估算
    用户故事通常用故事点来估算，故事点表明一个故事相对于其他故事的大小和复杂度。通常以理想工作日作为故事点的单位：相较于用连续时间估算，它更简单；相较于用完全模糊单位，它可使我们的估算拥有更好的依据。
    以团队估算
    故事估算应该由整个团队集体完成，团队大部分成员都参加估算是非常重要的。客户也可以参加，但是他不能提出他个人的估算或者在听到自己不赞成的估算时发表意见。
    Wideband Delphi估算方法
    与采用迭代方式进行开发软件的极限编程类似。最终目的是要为故事得到一个统一的估算值，这个迭代过程很少超过3轮。
    三角测量
    三角测试是帮助团队验证他们没有逐渐改变一个故事点含义的有效方法。

故事点估算
如果成熟团队，故事点估算不是问题。新团队建议用理想人天作为一个故事点的基准。这个方法同样适用于多团队并行要统一故事点基准的情况。
1、理想人天就是无干扰的情况下工作一天的工作量。定为1故事点。
2，定义一个1故事点的用户故事作为基准，其他的使用斐波纳切函数来做相对估算即可。
3，如果小于1故事点，统一为0.5故事点。
4，如果有一个用户故事很快能做完，但是担心会忘记，写下来定为0故事点。
5，开始估算团队能力的时候，可以根据团队人数、迭代时长、可用率（工作时间中的有效工作时间比率，建议50%-80%），来估计初始能力（velocity)。如：5个全职团队人员，四周（20工作日）迭代，70%的可用率，可算出初始能力为每个迭代70个故事点。
6，二到三个迭代后，团队可以按真实velocity来调整项目进度。

九、团队的速率
    速率是每一轮迭代开发中能完成的工作量。一旦知道团队速率，就可以用它将理想日转换变成日历日。总故事点 / 团队的速率 = 需要的迭代次数。
    初始速率
    可以通过三种方法获得初始速率：
    1.使用历史值
    2.执行一轮初始迭代，使用那轮迭代的速率
    3.猜测
    测试速率
    团队在在一轮迭代完成的故事点数的总和就是团队速率，不能将部分完成的故事也计算在速率中。用集中全部力量完成一个故事的方法会提高团队的意识：大家一起先完成一些故事比所有故事都只能完成一部分更有价值。

     计划速率和实际速率
    计算速率是用迭代开始前分配的故事点数，实际速率是迭代中实际完成的故事点书。计划速率与实际速率可能会出现偏差。

2.完成了页头页尾的STOY的