如何基于JIRA实现[项目管理]的敏捷开发模式？

0 序 公司最近几个月从禅道迁移到JIRA，在此总结一下JIRA的一些关键功能与概念。 1 概述：JIRA 敏捷开发(Agile) vs JIRA 敏捷开发(Agile)，是一种理念、过程模型，而 jira是目前支撑这一理念落地的最主流工具。 将敏捷的核心概念与jira的功能进行映射比对，可以帮助团队更加直观地理解如何从“理论”转向"实操"。 JIRA是敏捷模式的数字化载体。 敏捷模式提供了灵魂（价值观、节奏、沟通方式）；而JIRA提供了骨骼（结构化、流程自动化、数据可视化） 敏捷开发的概念 JIRA功能 功能描述 用户故事( User Story) Issue/议题(类型为 Story时) 描述用户需求。在JIRA中是最小的任务单元，包含描述、验收标准等。 可以在此视图中通过筛选器查看：我未完成的Issue、我的报告、所有Issue、打开Issue、已处理的Issue、最近查看、最近创建的、最近解决的、最近更新的 产品待办列表(Product Backlog) Backlog 视图（积压的待办项） 一个不断排序的需求池。通过拖拽可以调整任务的优先级。 冲刺/迭代(Sprint) Sprint(冲刺/迭代) 一个固定的迭代周期（通常为1-4周）。 JIRA允许创建、启动和关闭Sprint 团队可以在 Backlog 视图中进行 Spring Planning，你可以通过将 Story 从 Backlog 拖入当前或未来的Sprint 容器。 史诗(Epic) Epic(史诗) 跨越多个Sprint的大型需求集合。JIRA常用它来做项目目标的分类。 任务拆解(Task Breakdown) Sub-Task(子任务) 将 User Story 进一步拆分为具体的开发、测试等技术执行项级的任务 燃尽图(Burn-down Chart) Reports（报表） 实时监控 Sprint 剩余工作量，预测当前冲刺是否能按时完成。可用的报表有：燃尽图、累计流量图、版本报告、Sprint报告等。 子任务 Story / Bug 均可以：创建 Sub-Task（子任务）、转换为 Sub-Task（子任务） 测试概念 Test Plan / Test Set / Test Case / Test Execution 充分理解：Issue/议题 简单来说，在 Jira 的语境下，“Issue”并不等完全同于“需求”，它是一个更宽泛的通用对象（容器）。 你可以把 Issue 理解为一个“议题”。 引入国内时，被翻译为“问题”，笔者认为不太恰当。 任何需要被跟踪、处理或分配的工作，在 Jira 里都叫 Issue。 它可以是一个业务需求，也可以是一行代码改动，甚至可以是一次服务器运维操作。 Jira Issue 的常见类型 Issue/议题的各种类型中，除了提过的 Story（故事），Jira 默认和业界常用的类型主要分为以下四大类： 核心研发类 Epic (史诗)： 最大的层级。通常指一个巨大的功能模块或战略目标（如“开发移动端支付系统”），需要跨越多个 Sprint 才能完成。 Story（故事）：用户故事/用户需求。 Task (任务)： 通常指不需要拆分为用户故事的技术性工作。比如“搭建测试环境”、“重构数据层代码”。 Bug (缺陷)： 指现有功能与预期不符的问题。 细分执行类 Sub-task (子任务)： 这是 Story 或 Task 的从属。敏捷团队通常将一个 Story 拆解为多个 Sub-task（如：前端开发、后端接口、接口测试），分配给不同的成员同步进行。 业务管理类（需自定义） 很多企业会根据敏捷规模化框架（如 SAFe）自定义以下类型： Requirement (原始需求)： 有些团队用它承接产品经理的原始想法，评审通过后再转化为 Story。 Improvement / Enhancement (改进/增强)： 针对现有功能的微调，不属于新功能，也不是 Bug。 Research / Spike (预研)： 当团队不确定某个技术方案时，创建一个 Spike 进行调研，通常有时间盒限制。