如何基于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 进行调研，通常有时间盒限制。 Issue 类型的层级结构 在标准的 Jira 敏捷实践中，它们通常呈现如下的父子嵌套关系： Level 1: Epic (史诗) —— “我要做一个电商 App” Level 2: Story / Task / Bug (标准级别) —— “作为用户，我想用支付宝结账（Story）” Level 3: Sub-task (子任务级别) —— “编写支付宝 SDK 联调接口（Sub-task）” 总结：Issue 到底是什么？ Issue/议题 = [类型] + [状态] + [经办人] + [描述信息] 如果是 Story 类型的 Issue，它就是需求。 如果是 Bug 类型的 Issue，它就是缺陷。 如果是 Task 类型的 Issue，它就是事务。 为什么要分这么多类型？ 主要为了工作流（Workflow）隔离。 例如：Bug 的生命周期可能有“复现 -> 修复 -> 回归测试”，而 Task 可能只需要“待办 -> 处理中 -> 完成”。 通过区分 Issue 类型，你可以为不同性质的工作定制不同的审批流和统计报表。 充分理解：Backlog/产品的待办清单 https://www.yylab.tw/product-backlog-complete-guide/ 【推荐】 Backlog是什么？ 在敏捷开发里，Product Backlog 被翻成「产品的待办清单」。 但这种说法其實有點过于简化。实际上，它是产品团队对「接下来要做什么」的唯一真实来源（Single Source of Truth）。 只要是未来可能要做的事情，都应该先记录到这份清单中。 比较容易理解的方式是： Product Backlog 并不是一份规则文件，而是一套持续更新的产品决策系统。 它的重点不在记录，而在让所有人对方向保持一致。 Product Backlog 的角色：产品团队待办项的「唯一真实来源」 在有些團隊裡，需求散落在各種地方：主管的 LINE、業務的 Excel、設計師的 Figma、工程師的筆記、PM 的 Notion。結果就是： 會議上大家各說各話，各自解讀。 對於需求的優先順序不一致。 誰都覺得自己維護的那份才是最新版本 Product Backlog 的目的，就是把這些分散的資訊集中起來，變成： 所有需求的入口。 所有優先順序的依據。 它應該回答幾個關鍵問題： 我們有哪些事情需要做？ 哪些是目前最重要的？ 近期要專注在哪些項目？ 還有哪些想法在排隊等待？ 只要團隊在討論下一步時還需要到處翻不同文件，就表示這份 Product Backlog 還沒真的成為「唯一真實來源」。 一個健康的 Product Backlog 會： 持續新增。（新想法、Bug、技術需求） 持續更新。（補細節、拆分、合併） 持續排序。（優先順序調整） 持續清理。（過期不做的要刪掉） Y 推荐文献 JIRA 工具使用说明：从 “眼花缭乱” 到 “高效管项目”，新手也能快速上手 - Zhihu JIRA https://www.atlassian.com/zh/software/jira X 参考文献