[项目管理] 基于JIRA的敏捷开发模式

0 序

  • 公司最近几个月从禅道迁移到JIRA，在此总结一下JIRA的一些关键功能与概念。

image

1 概述：JIRA

敏捷开发(Agile) vs JIRA

  • 敏捷开发(Agile)，是一种理念、过程模型，而 jira是目前支撑这一理念落地的最主流工具。

image

  • 将敏捷的核心概念与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

image

image

充分理解：Issue/议题

image

简单来说，在 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 敏捷实践中，它们通常呈现如下的父子嵌套关系：

  1. Level 1: Epic (史诗) —— “我要做一个电商 App”

  2. Level 2: Story / Task / Bug (标准级别) —— “作为用户，我想用支付宝结账（Story）”

  3. 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 推荐文献

image

X 参考文献

posted @ 2026-04-02 12:34  千千寰宇  阅读(91)  评论(0)    收藏  举报