敏捷教练----敏捷项目管理-史诗、故事、主题

https://www.atlassian.com/agile  

5.4 史诗、故事、主题
       假设你和你的团队想做一些雄心勃勃的事情，比如发射一枚火箭进入太空。要做到这一点，你需要组织你的工作:从最大的目标到最细微的细节。你会希望能够对变化做出反应，汇报你的进展，并坚持一个计划。史诗、故事、主题和计划正是您需要的工具。
       通过了解这些流行的敏捷方法如何帮助组织工作，您的团队可以在结构、灵活性和向太空发射火箭之间取得健康的平衡。
什么是故事，史诗，方案和主题？

• 故事，也称为“用户故事”，是从最终用户的角度编写的简短需求或请求。
• 史诗是可以分解成许多小任务(称为故事)的大量工作。
• 方案是为了一个共同的目标而努力的史诗的集合。
• 主题是跨组织的大型焦点领域。

                                      
 5.4.1 敏捷史诗vs故事
       从某种意义上说，敏捷中的故事和史诗类似于电影或文学中的故事和史诗。故事是一种简单的叙述;一系列相互关联、相互依存的故事构成了一部史诗。你的工作管理也是如此，相关故事的完成会导致史诗的完成。这些故事讲述了完成工作的过程，而史诗分享了统一目标的高层次观点。
       在敏捷团队中，故事是团队可以承诺在一个或两个星期的sprint内完成的事情。通常情况下，开发人员一个月要处理几十个故事。而史诗则相反，数量少，完成时间长。每个季度，团队通常有两到三部史诗要完成。
       如果你的公司正在向太空发射火箭，并且想要为你的发射改进流媒体服务，你可以像下面这样组织你的故事。
敏捷故事的例子:
       iPhone用户在使用移动应用程序时，需要访问live feed的垂直视图。
       桌面用户需要在视频播放器的右下角有一个“全屏查看”按钮。
       安卓用户需要连接到苹果商店。
       以上故事都是相关的，可以看作是完成较大工作量（史诗）的独立任务。在这种情况下，史诗可能是“为第一季度发布改进了流服务”。
       将工作组织成故事和史诗还可以帮助您和您的团队在组织内进行有效的沟通。如果你把团队的进展报告给工程主管，那你就是在讲史诗。如果您与开发团队中的同事交谈，您会在故事级别进行交谈。
 5.4.2 敏捷史诗vs方案
       就像史诗是由故事组成的一样，方案也是由史诗组成的。方案提供了史诗之上的另一个层次的组织。在许多情况下，一个方案从多个团队中编译史诗，以实现比任何史诗本身更广泛、更大的目标。史诗是你可能在一个月或一个季度内完成的事情，而方案通常是在多个季度或一年之内完成的。
                                       
史诗在一个方案的例子:
       假设你的火箭船公司今年想把每次发射的成本降低5%。这对于一个项目来说是非常合适的，因为没有一个史诗级的项目能够实现这么大的目标。在这一方案中，将会有诸如“将发射阶段的燃料消耗降低1%”、“将每季度的发射次数从3次增加到4次”以及“将所有恒温器的温度从71度调低到69度#Dadmode”这样的史诗。
 5.4.3 方案与主题
       在许多组织中，创始人和管理团队会鼓励人们去追求一些理想的目标。这些是每年或每个季度宣布的目标(有时是非常老套的)，主题是你如何跟踪它们。

• 方案是史诗的集合
• 主题是跟踪高级组织目标的标签

       方案有一个结构设计。他们拥有史诗，而这些史诗的完成将导致方案的完成。主题是一种组织工具，允许您标记待定项、史诗和方案，以了解哪些工作有助于实现组织的目标。主题应该激发史诗和方案的创作，但不要与它们之间存在单调乏味的一对一关系。火箭船公司的主题应该是“安全第一”。
 5.4.4 构建你的工作
       敏捷性和包含性结构并不是相互排斥的，这里列出的结构并不是一种适合所有人的结构。成功是当你和你的团队理解这些概念并使它们适应你的需求。对我们来说，那就是故事、史诗、方案和主题。您可以从学习如何在Jira软件中设置Epics开始。
5.5 史诗
       敏捷史诗是可以根据客户或最终用户的需求/请求分解为特定任务(称为“故事”或“用户故事”)的工作体。
       史诗是组织工作和创建层次结构的有效方法。其理念是将工作分解为可交付的部分，这样大的项目就可以实际完成，并且可以继续定期向客户交付价值。史诗帮助团队分解他们的工作，同时继续朝着更大的目标工作。
       在组织大型任务(如史诗)时保持敏捷性不是一项简单的任务(双关语)。无论您的组织规模大小，了解史诗如何与健康的敏捷项目相关联都是一项基本技能。
 5.5.1 什么史诗？
       史诗是一个庞大的作品，可以分解为许多较小的故事，有时在jira中也称为“问题”。史诗通常包含多个团队，多个项目，甚至可以在多个板上进行跟踪。
       史诗几乎总是通过一组sprint交付的。当团队通过开发和客户反馈了解有关史诗的更多信息时，将根据需要添加和删除用户故事。这就是敏捷史诗的关键：范围是灵活的，基于客户反馈和团队节奏。 
 5.5.2 敏捷史诗的例子
       假设现在是2050年，我们在一个娱乐太空旅行组织工作。我们一年大约发射12次，所以每一次发射都不是我们一年里做的最大的一件事，但它仍然离常规很远，需要很多人的时间来完成。这种大小正好适合史诗。
       以史诗为例，“2050年3月太空旅游发射”包括日常工作的故事，以及旨在改进航天飞机发射的关键方面的故事，从客户购买太空旅行票到火箭发射本身。因此，多个团队将通过处理广泛的故事来为这个史诗做出贡献。
支持购买2050年3月发行门票的软件团队可能会这样构建他们的史诗:

史诗:2050年3月推出
故事:更新日期范围以包括2050年3月发布日期。	故事:将所要求的航班列表的装载时间缩短至<0.45秒	故事：在头等舱预订的确认页面上推广土星夏季促销。

同时，推进团队可能会通过以下故事为同一部史诗做出贡献：

史诗：2050年3月发布
故事：发射时保持油箱PSI> 250 PPM	故事：将整体油耗降低1％。	故事：雇用新的推进工程师取代加里。＃garygate2050

5.5.3 在完整的敏捷计划中了解史诗
       史诗应该为开发团队提供成功所需的一切。从实际的角度来看，它是他们工作层次结构的顶层。但是，了解史诗与其他敏捷结构之间的关系为日常开发工作提供了重要的背景。

• 产品路线图是产品或解决方案如何随时间发展的行动计划。
• 一个主题是一个组织的目标，推动史诗和行动的创建。
• 产品路线图被表达并可视化为沿着时间轴绘制的一组计划。
• 将计划分解为史诗有助于将团队的日常工作（以较小的故事形式表示）与总体业务目标保持联系。

       一组完整的史诗驱动特定的计划，从而使整个产品根据组织主题以及市场和客户需求进行开发和发展。
       从我们上面的例子来看，一个主题是增加航天飞机的发射，路线图将会从每季度3次发射增加到4次，计划将会降低成本，增加门票销售，每个史诗都将增加到计划中。
                                       
 5.5.4 创建敏捷史诗
       在创建一个新的史诗时，考虑您的团队可能已经拥有的其他计划和组织工具。围绕球队的季度目标(okr)创造传奇是一个很好的开始。在创建史诗时，考虑以下几点:

• 报告——为经理和执行人员希望关注的项目创建史诗。
• 讲故事——使用史诗，以及与之相关的故事，作为一种机制来讲述你是如何达到某个特性或产品的当前状态的。
• 文化——让组织文化来决定史诗的大小和粒度。
• 时间——大多数开发团队依赖于评估框架，而不是时间，但是有必要检查一下你的史诗，确保它会花上几周的时间来完成。不要太长也不要太短。

 5.5.5 分解敏捷史诗
       将一个宏大的故事分解成更实际的故事有助于理解一个项目并保持动力，但是这对于新手来说可能是一项艰巨的任务。从史诗中创建故事并没有一种适合所有人的解决方案，但是有很多好的选择可以考虑:

• 用户角色或角色——为每个用户角色创建一个独特的故事。“新访问者更快的登录”，“回头客更快的登录”，等等。
• 有序步骤——分解过程并为每个步骤创建一个事例。
• 文化——让团队规范来规定一个故事是一个快速任务还是一个为期一周的项目。
• 时间-排除另一个商定的约定，设计可以在一次或更少的印刷中完成的故事。

       大故事和史诗之间并没有统一的定义。一般来说，团队估计完成“周”(或更长)的工作范围，而不是“小时”或“天”的工作范围，都应该被视为一个史诗，并分解为更小的故事。
 5.5.6 测量敏捷史诗
       燃尽图可用于使史诗化可视化，并有助于保持团队的积极性和执行干系人的情况。一个好的史诗燃尽图是组织的敏捷性真正闪耀的地方。
       Epic Burndown图表显示了冲刺或史诗中实际和估计要完成的工作量。 燃尽图中的水平x轴指示时间，垂直y轴指示故事或问题。
                                           
       使用Burndown图表来跟踪剩余的工作，并预测实现sprint目标的可能性。通过在整个迭代中跟踪剩余的工作，团队可以管理其进度并做出相应的响应。
       通过监视燃尽图，可以清楚地看到团队的进展情况以及阻碍因素在哪里。让这些数据点清晰可见可以让每个人都保持在同一页面上，并促进关于产品发展和完成预测的公开对话。更不用说透明能建立信任!
 5.5.7 了解敏捷史诗
       史诗并不是敏捷项目的绝对基础，但对于大多数敏捷团队来说，它们是实际的驱动因素。了解它们在健康敏捷项目中的位置可以为您的工作创建环境，将它们分解为故事可以创建动力。
5.6 用户故事
       简单地说，用户故事就是软件系统需求，但事实并非如此。
       敏捷软件开发的一个关键要素是把人放在第一位，而用户故事则把实际的最终用户放在了对话的中心。故事使用非技术语言为开发团队及其工作提供上下文。在阅读了用户故事之后，团队知道他们为什么要构建他们要构建的东西，以及它创造了什么价值。
       用户故事是敏捷程序的核心组件之一。它们为日常工作提供了一个以用户为中心的框架——这推动了协作、创造力和整体上更好的产品。
 什么是敏捷用户故事？
       用户故事是敏捷框架中最小的工作单元。它是从软件用户的角度来表达的一个最终目标，而不是一个功能。
       用户故事的目的是阐明一项工作将如何向客户带来特定的价值。请注意，“客户”不必是传统意义上的外部最终用户，他们也可以是内部客户或依赖于您团队的同事。
       用户故事是用简单的语言概括了的几句话，概括了期望的结果。他们不讲细节。一旦得到团队的同意，便会添加需求。
       故事非常适合敏捷框架，比如scrum和看板。在scrum中，用户故事被添加到sprint中，并在sprint的持续期间被“消耗掉”。看板团队将用户描述引入到他们的backlog中，并在工作流中运行它们。正是这种针对用户故事的工作，帮助scrum团队更好地进行评估和sprint计划，从而产生更准确的预测和更大的灵活性。多亏了故事，看板团队学会了如何管理正在进行的工作(WIP)，并且可以进一步细化他们的工作流。
       用户故事也是大型敏捷框架(如epics和initiative)的构建块。史诗是被分解成一组故事的大型工作项，多个史诗包含一个方案。这些更大的结构确保了开发团队的日常工作有助于实现构建在史诗和计划中的组织目标。
为什么要创建用户故事？
       对于新接触敏捷的开发团队来说，用户故事有时似乎是一个额外的步骤。为什么不把这个大项目(史诗)分成一系列的步骤，然后继续进行呢?但是故事为团队提供了重要的背景，并将任务与这些任务带来的价值相关联。
用户故事提供了许多关键的好处:
       故事将重点放在用户身上。待办事项列表使团队专注于需要检查的任务，但故事的集合使团队专注于为实际用户解决问题。
       故事使协作成为可能。定义最终目标后，团队可以共同决定如何最好地为用户服务并达到该目标。
       故事推动了创造性的解决方案。故事鼓励团队认真思考和创造性思考如何最好地解决最终目标。
       故事创造动力。随着故事的发展，开发团队将面临一个小挑战和一个小胜利，从而推动了发展。  
处理用户故事
       一旦编写了一个故事，就该将其集成到您的工作流中了。通常情况下，故事是由产品负责人、产品经理或项目经理编写并提交审查的。
       在sprint或迭代计划会议中，团队决定他们将处理哪些故事。团队现在讨论每个用户描述所需的需求和功能。这是一个在团队实现故事中获得技术和创造性的机会。一旦达成一致，这些需求就被添加到故事中。
       会议中另一个常见的步骤是根据故事的复杂性或完成的时间给故事打分。团队使用t-shirt sizes、斐波那契数列或planning poker来进行正确的估计。故事的大小应该在一个sprint中完成，因此当团队描述每个故事时，他们确保将超过完成期限的故事分开。
如何编写用户故事
编写用户故事时，请考虑以下事项：

• “完成”的定义——当用户能够完成概述的任务时，故事通常是“完成”的，但请确保定义它是什么。
• 概述子任务或任务——确定需要完成哪些具体步骤以及谁对每个步骤负责。
• 用户角色-为谁?如果有多个最终用户，可以考虑创建多个故事。
• 有序步骤——为更大流程中的每个步骤编写一个故事。 
• 倾听反馈——与你的用户交谈，从他们的话中捕捉问题或需求。当你可以从你的客户那里获得这些故事时，就没有必要去猜测了。
• 时间是一个敏感的话题。许多开发团队完全避免讨论时间，而是依赖于他们的评估框架。由于故事应该在一个sprint中完成，所以可能需要几周或几个月才能完成的故事应该分解成更小的故事，或者应该将其视为自己的史诗。

明确定义用户故事后，请确保它们对于整个团队都是可见的。
用户故事模板和示例
用户故事通常用简单的句子表达，结构如下:
“作为一个[角色]，我[想][这样做]。”
分解如下：

• “作为一个角色”:我们为谁构建这个?我们不仅追求职位，还追求人物的个性。Max。我们的团队应该对Max有共同的理解。希望我们采访了很多Max。我们理解那个人的工作方式，他们的想法和感受。我们对Max有同感。
• “想要”:这里我们描述的是他们的意图——而不是他们使用的功能。他们真正想要达到的目标是什么?该语句应该是无实现的——如果你描述的是UI的任何部分，而不是用户的目标，你就错过了重点。
• “那么”:他们做这件事的直接愿望是如何与他们更大的愿景相适应的?他们试图实现的总体利益是什么?需要解决的大问题是什么?

例如，用户故事可能看起来像：

• 作为Max，我想邀请我的朋友一起享受这项服务。
• 作为Sascha，我想要组织我的工作，这样我可以更有控制力。
• 作为一个管理者，我希望能够了解我的同事的进步，这样我可以更好的汇报我们的成功和失败。

       这个结构不是必需的，但是它有助于定义done。当角色能够获得他们想要的价值时，故事就完成了。我们鼓励团队定义自己的结构，然后坚持下去。

 敏捷用户故事入门
       用户故事描述了开发团队成员日常工作背后的原因和内容，通常表示为角色+需求+目的。理解他们作为团队交付内容的真相来源的角色，以及为什么要这样做，是一个顺利的过程的关键。
从评估下一个，或最紧迫的，大型项目(例如，史诗)开始。将其分解为更小的用户场景，并与开发团队一起进行优化。一旦你的故事被公之于众，整个团队都可以看到，你就可以开始工作了。