JIRA中的史诗、故事、版本与冲刺

史诗, 故事, 版本与冲刺

这四辆马车能够优雅地管理敏捷过程的范围和时间表。并构建您的工作。

一旦软件团队熟悉瀑布或其他传统项目管理风格，他们常常感到“如何构建我的工作”的痛苦。 幸运的是，敏捷开发使用四个明确的交付工具，将结构带入任何敏捷项目：史诗，用户故事，版本和冲刺：

· Epic 史诗 大量的工作，包含故事

· Story 故事 最小的工作单位，也被称为任务

· Version 版本 向客户发布的软件

· Sprint 冲刺 团队事务处理的迭代

通过使用这四大工具，软件团队能够组织工作并将其分解成可以实现的部件，因此可以优先考虑客户的反馈意见，并从项目的原始计划中进行改变，而不会觉得像被各种墙围绕一样而感到奔溃。

根据当前见解改变和适应未来计划的能力是敏捷性的标志。在这篇文章中，我们将定义这四种交付工具，并展示它们如何组合在一起构建您的工作。 但首先，我们来讨论每个工具之间的区别。

史诗 v.s. 故事

史诗是更大的工作，涉及到很多的故事。 史诗可以跨越多个冲刺和版本。 版本与史诗不同，因为它们是软件发布给客户的时间点。 版本可能包含多个史诗。 史诗帮助团队创建层次结构和架构。 故事帮助团队跟踪手头任务的具体细节，并将其细分为子任务。

上图中显示的工作可以选择为，在一个或多个冲刺期间完成的版本。

举措(Initiative)发生在组合层。 重要的是将问题在该层面指出，以便发现史诗通常是更具战略性的目标或举措。 当进行长期规划时，可以制定这些举措，并通过JIRA工具来捕获这些工作。

什么是史诗？

史诗是一大堆的工作，可以分解成许多较小的故事。例如，版本发布中与性能有关的工作。如果史诗所属的面板中包含多个项目，史诗可以跨越多个项目。

与冲刺不同，史诗经常随着时间的推移变化，作为敏捷开发的一个自然方面。史诗几乎总是通过一系列冲刺传递。随着团队通过开发和客户反馈了解有关史诗的更多信息，将添加和删除用户故事，以优化团队的发布时间。

史诗的例子

根据使用的敏捷框架（Scrum、看板或自己独特的风格），敏捷史诗可以不同方式使用。

对于看板(kanban)，史诗可以用作泳道来分割不同的工作流。如果您正在使用scrum，史诗可以帮助您标记冲刺中的工作，如下面的示例。火星任务(Mission to Mars)在这个冲刺中是史诗。 TIS 1，TIS 2等都是冲刺中的用户故事（TIS Sprint 1）。你可以看到，冲刺中有多个用户故事和史诗。

 

衡量史诗

燃尽图(Burndown)也可用于可视化史诗，从而保持团队的积极性与执行利益相关者的关注。 好的史诗燃烧图显示了敏捷的发展性质。 清楚展示团队的进度以及产品所有者添加和删除用户故事的地方。将这些数据清楚地显示出来，每个人都可以对项目状态保持一致认识，并促进关于产品演进和完成预测的开放交流。更不用说公开透明能够建立的信任了！

 

什么是用户故事？

故事或用户故事是敏捷框架中最小的工作单元。这是个软件系统要求，用几句短语表达，理想地使用非技术语言。

用户故事的目标是将特定价值提供给客户。请注意，“客户”不必是传统意义上的外部最终用户，也可以是依赖您团队的组织内部客户或同事。

用户故事是简单语言中的几句话，概述了所需的结果。他们没有详细的要求。

用户故事示例

用户故事由产品所有者(product owner)勾画出来，然后整个产品团队共同决定更详细的要求。这些细粒度工作，有助于定义故事和即将到来的冲刺的执行。

在一个故事中，需要一系列任务，这些任务在用户故事的估计过程中应该被补充，并在团队的问题跟踪器中进行链接。

使用与上述相同的例子，这个冲刺中的故事显示了预估、优先级、处理人、史诗和描述，所以每个人都可以快速了解正在完成的工作。

 

什么是版本?

版本是向客户发布软件的实际版本。请记住，在每个冲刺结束时，团队应该能够将软件提交给客户。版本是产品所有者实际提交的策划变更。

版本经常贯穿于一系列冲刺中开发，就像史诗一样。精明的产品所有者可能会选择在几个版本上提供史诗。一个史诗不必完全包含在一个版本中。通过几个版本交付某个史诗，产品所有者可以了解市场如何响应史诗，并对其未来发展方向做出评估决策，而不是做一个巨大的发布。

版本的例子

产品所有者可以按如下方式构建发布策略：

· 版本1：登录，注销，密码管理

· 版本2：购买历史

· 版本3：保存偏好

· 等等

版本范围变化也是敏捷开发的自然部分。 Burndown图表让整个团队了解版本随着时间的推移。应与整个团队讨论对版本的更改，以将每个人都放在同一页面(整体认识)上。

什么是冲刺？

冲刺是一个很短的周期，开发团队实施并提供离散和潜在可交付的应用程序增量，例如工作的里程碑版本。如果您以前没有运行冲刺，我们建议您为每个冲刺使用固定的两周持续时间。时长已经足够完成任务，但也不会长到团队无法获得任何正常反馈。

注意：Sprint只是Scrum框架的一部分。相比之下，看板团队在吞吐量允许的情况下就可以着手积压下一个项目上的工作。不需要预测。

在Scrum中，团队承诺在固定时间段内完成一组用户故事。一般来说，冲刺是一，二，四周。由队伍决定冲刺的长度。一旦确定了冲刺节奏，团队将永远按照这种节奏运作。只要拥有几个完成的冲刺的数据，固定长度的冲刺能增强评估技能，并且能够预测团队的未来速度。

冲刺的例子

与上述相同的例子，下图中的冲刺TIS Sprint 1是用户故事的集合。

 

关于冲刺你应该知道一些事:

一旦团队承担了一连串冲刺的用户故事，并且Sprint已经开始，Scrum主管将负责防范用户故事的更改。 这使得团队集中精力，并且抗击“范围蠕变”（在冲刺开始之后，将工作量添加到冲刺中）。 加入中期冲刺可以帮助团队准确预测和估计团队的能力。

在每个冲刺结束时，团队需要提供一个工作的软件。 在scrum中，这称为潜在的可交付增量（PSI）。 产品所有者最终决定PSI何时发布给客户，但是工作应该足够完整，以适应在冲刺结束时的发布。

衡量你的冲刺

任何Scrum团队的好工具是燃尽图表。 他们清楚地跟踪Y轴上的“剩余工作”和X轴上的“时间”在整个冲刺中的进度。 Burndown图表是团队的强大动力，他们在冲刺中保持每个人的注意力。 最重要的是，这些图表提供了有关冲刺进度的讨论中的支持数据。

 

扩大

较大的组织通常会有几个敏捷团队在一个共同的计划上工作，而组合计划是规模运行敏捷的关键。 史诗和版本为团队层面的敏捷投资组合管理奠定了基础。 敏捷投资组合管理包括跨多个团队的跟踪计划，同时在组织的较高层面保持同样水平的敏捷性。 在敏捷组合部分，详细了解敏捷规模。

如想学习更多IT技术，请前往51Testing软件测试网-中国软件测试人的精神家园哈~