基本概念
假设您和您的团队想做一件大事，比如发射火箭进入太空。要实现这一目标，您需要安排好每项工作：从最大的目标到最小的细节。您希望能够及时响应变化，报告进度，并照计划进行。要做一点，就要用到史诗故事(epic)、用户故事（story)、商业动机（initiative）和主题（theme）和这样的工具了。
通过了解这些流行的敏捷方法如何帮助组织工作，您的团队可以更好地在结构、灵活性和目标实现，这三项任务之间权衡利弊。
故事、史诗、动机和主题
- 用户故事，是从最终用户的角度编写的简短需求或请求。
- 史诗故事，是可以分解成若干较小任务（故事）的大型作品。
- 商业动机，是推动实现共同目标的史诗集合。
- 主题，是跨组织的重点领域。
敏捷史诗和故事
从某种意义上讲，敏捷团队中的故事和史诗类似于电影或文学中的故事和史诗。故事是一种简单的叙述；一系列相关和相互依赖的故事构成了一部史诗。工作管理也是如此，完成所有相关故事也即完成了史诗。故事显示了已完成工作的轨迹，而史诗则分享了统一目标的高级视图。
对于敏捷团队来说，故事就是团队承诺在一两周时间内完成的事情。通常情况下，开发者一个月要处理几十个故事。相比之下，史诗的数量并不多，但是需要更长时间才能完成。每个季度，团队通常要完成两到三个史诗。
如果您的公司要向太空发射火箭，并且希望改进每次发射的流媒体服务，可以像下面这样安排故事。
示例：敏捷故事
- iPhone用户在使用移动应用时需要访问即时动态垂直视图。
- 桌面用户需要在视频播放器右下角有一个“全屏观看”按钮。
- Android用户需要链接到苹果商店。
上述故事都是相关的，都可以被认为是推动完成更大工作主体（史诗）的个别任务。在此情况下，史诗可以是“改善Q1 Launch的流媒体服务”。
将工作组织成故事和史诗还可以帮助您和团队在公司内进行有效的交流。如果您要向工程负责人报告团队的进展情况，那么您要以史诗的形式进行汇报。如果您是和开发团队的同事交流，那么要在故事层面进行讨论。
敏捷史诗与动机
就像史诗是由故事组成的一样，动机是由史诗组成的。动机是史诗以上的组织层级。在许多情况下，动机汇编了多个团队的史诗，实现比其中任何一个史诗都更广泛、更宏大的目标。一个史诗可能只要一个月或一个季度内就能完成，但是动机通常需要几个季度甚至一年来完成。
示例：在动机中的史诗故事
假设火箭飞船公司希望今年每次发射的成本降低5％。这就很像动机，因为没有任何一个史诗能够实现这个目标。在这个动机中，可以有这样的史诗故事，例如：“降低发射阶段燃料消耗1％”，“每季度增加3到4次发射”，以及“将所有恒温器从71度降至69度”。
在Atlassian
我们在内部将动机称为“PC Tickets（Project Central Ticket）”（项目中心工单）。在Jira Software中，项目中心工单的配置就像史诗一样。每个团队都会在本年度实现四到五个最重要的目标，并各自确定一个PC工单。管理层利用这些PC工单了解公司正在处理的所有工作。
动机和主题
在许多组织中，管理团队鼓励团队追求理想。这些理想就是每年或每季度宣布的目标（有时是老生常谈），主题是如何跟踪这些目标。
- 动机是史诗的集合
- 主题是追踪高层组织目标的标签
动机具有结构化的设计。动机包含史诗，完成这些史诗也就完成了商业动机。主题是一种组织工具，可让您标记待办事项、史诗和动机，从而了解哪些工作有助于实现组织目标。主题应该能够引导史诗和动机的创建，但它们之间不存在严格意义上一一对应的关系。火箭飞船公司的主题也可以是“安全第一”。
就像 Portfolio for Jira中的主题一样：
善用敏捷思维运用工具
既然 Jira 和 Confluence 是基于敏捷原则和价值观设计的，只有以敏捷思维来做事，才能善用这些工具。千万不要把旧思维运用在这些新工具上。
我们公司过去是用 Word/Excel+SharePoint，很多同事在使用 Confluence时，只是把它当成了 SharePoint 的替代品，把一大堆 Word/Excel 文档以附件形式放在 Confluence 的页面上。
虽然 Confluence 可以管理附件文档，但这完全不是它的特长。
我们从RTC过渡到 Jira 时，也存在类似的情况。
那怎样使用 Jira 和 Confluence 才是正确的呢？我在这里总结了一些使用原则：
Jira 的使用原则
在 Jira 里面，所有的事项都统一叫做 Issue，而 Issue 可以定义 Issue 的类型，以映射我们真实工作工程的管理单元，比如它可以是 Story 代表用户故事，它可以是 Test 代表测试用例，它可以是 Incident 代表生产环境故障等。不同的 Issue 类型也可以对应不同的工作流，以反映真实的工作过程。
Jira 是原生支持敏捷开发的。在敏捷开发中，有下面几个层级
- Epic - 史诗故事：包含某个特性或子项目的相关用户故事，便于用户故事归组。
- Story - 用户故事：其中一种Issue的类型。这里强烈建议用户故事是具有一定业务价值、可单独交付、最小的需求。
- Sub-task - 用户故事下需要分配给不同人处理的子任务，不可单独交付，比如前端开发与后端开发，上、下游组件开发等。
由于一个 Epic 包含若干个用户故事（Story），在新建或编辑Story时，可以通过 Epic Link 的属性把该 Story 指向一个已有的 Epic，从而建立两者的隶属关系。
如果一个 Story 需要拆分成任干个任务交给不同人或团队完成，可以在 Story 中新建 Sub-task 并分配给相应的人或团队。Defect 也是一种 Sub-task。独立测试团队对某个 Story 进行测试时发现 Defect，应该在该 Story 下创建 Defect (Sub-task)，把两者关联起来。
在一个 Story 级别的 Issue 中，可以按“More”按钮，然后按“Create Sub-Task”按钮来新建 Sub-task。Sub-task 和 Story 级别的 Issue 是可以相互转换的。所以即使一开始关系建错了，也没有关系。另外，Issue 类型可以通过 Move 功能随时进行转换。这也体现了 Jira 强大的灵活性和对延后决策的完美支持。
小结三者关系是 Epic 包含若干个 Story，Story 包含若干个 Sub-task。
我们可以在JIRA中做发布计划。在管理界面中，管理员可以根据发布计划定义 Version，包含发布日期与发布提要。在每一个 Issue 中，我们可以在 Fix Version/s 属性中指定它将在哪个 Version 发布。可以通过Releases页面轻松发布Release Note。
通过代码版本控制软件如 SVN、Git等的插件，只要在提交代码时，提交备注（Comment）中包含JIRA Issue Key，相应的代码提交信息也会显示在Issue中，从而建立 Issue 与相应的代码的可视关系。实现敏捷与 DevOps 里倡导的可追踪性。
- Confluence 的使用原则
Confluence 是基于 Wiki 精神设计的，任何人都可以对内容进行修改和贡献。所以在建立 Confluence 文档时，不必拘泥于一次写对，持续地更新、修正恰恰符合“先完成、再完美”的敏捷原则。
**
我强烈建议大家在编写 Confluence 文档时，善用 Header 来对文档进行结构化处理。Confluence 支持5级 Header，便于建立不同的章节和层次结构，配合目录（Table of Content）功能，Confluence 会自动根据文档的 Header 生成相应的目录和书签，便于定位某个章节。
由于 Confluence 具有强大的灵活性，文档所处的位置可以通过 Move 功能随意移动，不建议花太多时间设计文档间的关系。
在去中心化的原则下，每个人都可以贡献内容，所以 Confluence 的文档体系建立一定是自底向上的，这不可避免地会带来文档的碎片化和内容的重复建设。但不必对此过于担心，其实互联网也是这样的，我们不还是活得好好的，能通过互联网获取到我们所需要的信息吗？强大的搜索功能可以帮助我们找到需要的内容。
如果可以善用标签，也就是在编写某类文档有加上相应的关键字做标签，然后通过标签把相应的文档聚合在某个地方，方便查阅。
**
只要把某个 Jira Issue 的链接地址贴到 Confluence 页面里，该 Issue 的标题和实时状态会自动显示在 Confluence 页面中。
如果某个 Issue 被 Confluence 引用，在 Jira 中也能看到相应的链接。
我们建议把项目中相对静态的信息，如项目的整体框架或者从项目拆分到特性等内容放在 Confluence 中。
然后把对应的比较动态的工件通过 Jira 来追踪，然后把 Jira Issue 的链接放在 Confluence 页面中，建立两者的对应关系，整个项目的脉络，一目了然。
而且在 Jira 中的状态更新在 Confluence 页面中也能实时反映。或者通过 Confluence 的表格功能建立用户故事地图，然后把生成的用户故事通过 Jira 记录，并把链接放在 Confluence 里的地图细节中。
简单来说，就是静态的内容放 Confluence，动态的内容放 Jira，并把两者链接起来。
我们不时需要给客户提交项目报告。过去，我们需要手动整理这些信息，费时费力。通过这两大利器，我们可以轻松构建实时的报告和仪表盘，只消一次搭建的功夫。
我们可以在 Confluence 中把整个 Jira 列表引入，列表的内容可以通过 JQL 灵活设定。也可以把列表转换为图表，建立可视化很强的仪表盘。
若有收获，就点个赞吧
0 人点赞
