企业官网建设流程全解析

简介：基于JIRA工具系统讲解Scrum敏捷开发的项目管理实践，面向正在使用JIRA进行迭代交付的项目经理、产品负责人与研发团队成员，尤其适合计划从传统瀑布流程转向敏捷模式的中小型团队。内容从Scrum的增量与迭代理念切入，梳理product owner、scrum master、scrum team三类角色职责，说明团队规模、决策归属与协作要点；按头脑风暴、需求筛选、工作量估算、Sprint冲刺、产品评估五步展开，并特别强调任务需拆解到不超过16小时的最小粒度，每日站会聚焦昨天完成、今日计划与遇到困难，时间燃尽图需如实记录时间变化。资源还结合JIRA具体操作，讲解如何建立Scrum Board、配置用户与项目、设置版本周期，将Scrum流程映射为可运行的JIRA管理方案。整个资源为单个docx文档，压缩包大小6.55MB，内容结构清晰，可在项目启动或团队培训时直接参考。目前已有3408人学习下载，适合需要快速建立JIRA敏捷流程、提升迭代管理效率的团队与个人。

1. 做敏捷开发项目管理，基于JIRA来搭建流程是我接触过的最常见也最容易被用偏的方案

多数团队建完项目就开始开卡片，Sprint照开、燃尽图照看，但两个迭代之后就发现节奏还是失控，最后只能得出“JIRA不好用”的结论。问题通常不在 JIRA 本身，而在于问题类型、工作流和看板这三件套从来没有被当成一套系统去设计。

JIRA 真正能解决的，是把“需求进来 → 任务被完成 → 缺陷被关闭”这件事变成团队每天看得到的协作信号。前提是：Story、Task、Bug 有明确边界，工作流状态少而准，看板列和状态一一对应。这篇文章会沿着这套最小可运行的搭建路径，把 JIRA 的敏捷配置讲清楚，并给出 Sprint 执行、燃尽图解读和实战避坑，适合产品、研发、测试，以及正在向团队解释为什么 JIRA 要这样配的项目负责人。

2. JIRA 的敏捷三件套：问题类型、工作流与看板如何决定迭代质量

很多人以为 JIRA 自带敏捷，打开 Scrum 模板就能跑。实际不是这样。JIRA 只是提供了问题类型、工作流、看板这三个可配置的模型，真正决定敏捷开发项目管理质量的，是你怎么把团队的真实流程映射到这三者上。映射对了，JIRA 是项目节奏的仪表盘；映射错了，JIRA 就是一张昂贵的电子表格。

2.1 问题类型不是字典，是团队分工和估算的锚点

JIRA 默认给了一堆问题类型：史诗、故事、任务、子任务、缺陷。常见的误用有两种：一是所有人都建 Task，把 Story 只当成标题；二是把 Story 拆得比 Task 还细。这样过两个 Sprint，燃尽图完全没法解释——问题类型没有统一口径，故事点也没法沉淀。

问题类型的本质，其实是一组“字段方案 + 界面方案 + 工作流”的组合。JIRA 里 Story 和 Task 不光是名字不同，它们可以带不同的字段、走不同的工作流，甚至在创建表单上显示的内容都不一样。可以把 Story 理解成“用户可感知的交付单元”，Task 是“技术执行单元”，两者不能互相替代。

下面这张表是我常用的设计方式，可以直接照抄：

实际操作里有两条约束要提前定死：第一，Sub-task 必须勾选“仅当父级存在时创建”，避免有人拿它当独立任务用，否则看板会炸；第二，不要把新特性这种类型留给团队自由选择，类型越多，团队在创建卡片时越容易选错。

提示：问题类型方案是全局资源，不要每个项目各建一套。JIRA 的层级关系是“字段方案 + 界面方案 → 问题类型方案 → 项目”，让所有项目共用同一套方案，跨项目报表才能汇总。

很多团队卡在第一步是因为界面层级绕。记住一句：字段存不存、界面上显不显示、必不必填，这三件事是分开配的。先定字段方案（哪些字段存在），再定界面方案（哪些字段在创建/编辑/查看界面出现），最后把问题类型方案绑到项目上。

2.2 工作流是状态机，不是流程图：先想清楚四个状态

JIRA 工作流是一张“状态 + 流转”构成的有向图：状态是节点，流转是边。很多团队第一次搭工作流，参考研发流程画了十几个状态——待需求确认、待设计、设计完成、开发中、开发完成、联调中、联调完成……结果看板变成流水账，每个人每天要花五分钟移动卡片。

我常用的原则是状态数控制在 3 到 5 个，正好对应看板列。每个状态要能直接回答“这事现在是什么情况”，不能出现有歧义的中间态。默认的四状态方案足够覆盖绝大多数研发场景：

工作流的另一个关键点是流转的自动动作。JIRA 支持在流转上配置“后置功能”，比如“待处理 → 处理中”时自动把经办人设为当前用户；“处理中 → 待验收”时自动把经办人转给测试角色。这些自动动作能省掉大量手工维护成本，也让看板上的卡片始终指向“下一步该谁动”。

这里有一个 JIRA 特有的概念容易忽视：每个状态除了名字，还有一个状态类型（category）。JIRA 只认三档：待办（to-do）、进行中（in-progress）、已完成（done）。这个类型直接决定燃尽图怎么统计“完成”，后面的搭建章节会专门展开。现在你只需要记住：给状态起名字是给人看的，给状态标类型是给 JIRA 算数用的。

2.3 Team-managed 和 Company-managed 项目怎么选

JIRA 现在有两种项目形态：团队管理型项目（Team-managed）和公司管理型项目（Company-managed）。两者的核心差异不在界面，而在配置的作用域。

Team-managed 项目：每个项目自带一套独立配置，项目管理员可以直接改状态、加字段，自由度大，改起来快，适合 15 人以下的独立小团队快速试错。代价是方案不能跨项目复用，A 项目配的工作流，B 项目组不到，报表口径也各算各的。

Company-managed 项目：所有工作流方案、问题类型方案、字段方案都是全局资源，权限由全局管理员控制。配置改动要走管理员流程，慢一些，但换来的是整个组织统一流程、统一字段、统一报表口径。

我一般会建议从第一天就建 Company-managed，哪怕团队只有五个人。因为从 Team-managed 迁移到 Company-managed 非常痛苦，几乎等于重建项目。而敏捷管理最怕的不是配置慢，是每个团队用自己的语言各说各话。

3. 从零搭建 JIRA 敏捷项目：问题方案、工作流与看板的三个关键配置

这一章给一条不依赖任何插件的最小搭建路径。按顺序做完，整个项目就能支撑两个以上的 Sprint 稳定运转。耗时预计半天，其中大部分时间花在工作流配置上。

3.1 创建项目与问题类型方案：先统一 Story 的字段约束

第一步是创建项目。在 JIRA 顶部进入“创建项目”，选择软件开发类型，模板选 Scrum。如果创建界面让你选项目形态，选经典版（Company-managed），它的工作流和看板可控性比新版更强。

项目创建后，进入项目设置 → 问题类型方案，新建一个方案。从默认方案复制一份，只留下：Epic、Story、Task、Sub-task、Bug。其余的可以先摘掉，减少团队的选择负担。

第二步是给 Story 补齐字段。Story 在 JIRA 里默认就有故事点字段，但它还缺一个关键信息：验收标准。创建一个多行文本字段叫“验收标准”，把它加到 Story 的创建界面和编辑界面里。在界面方案里，把创建界面上故事点设为必填，把验收标准设为可见必填。这样每张 Story 在创建时就必须回答“什么才算做完”。

这一步做完，JIRA 里实际形成的关系链是：

注意：改完问题类型方案后，项目里已经存在的旧卡片不受影响。所以这个动作务必在项目还没建大量卡片之前完成。半路再加字段，旧卡片只能一张张手动补，非常消耗耐心。

这套配置的收益在两周后才会显现：当产品经理创建 Story 时必须填验收标准，开发看到的故事天然就是可验收的；当创建 Task 时没有故事点字段可填，团队就不会拿任务去充个数。

3.2 用一份状态机 JSON 定规范，再在界面里照着建

JIRA 不支持直接导入 JSON 来建工作流，但我会用一份 JSON 作为团队统一规范。它有两个作用：一是评审时大家看文字比点界面快；二是防止每个人在界面上按自己的理解加状态，最后五个团队五种流程。下面是我常用的一份参考片段：

{ "workflowName": "敏捷研发标准流", "statuses": [ { "name": "待处理", "category": "todo" }, { "name": "处理中", "category": "inprogress" }, { "name": "待验收", "category": "inprogress" }, { "name": "已关闭", "category": "done" } ], "transitions": [ { "from": "待处理", "to": "处理中", "autoAssign": "当前用户" }, { "from": "处理中", "to": "待验收", "autoAssign": "测试角色" }, { "from": "待验收", "to": "已关闭", "condition": "测试角色可执行" }, { "from": "已关闭", "to": "待处理", "condition": "打回并清空解决结果" } ] }

这段 JSON 我在团队里当工作流评审的输入来用。讨论通过后，在 JIRA 界面里的操作路径是：项目管理 → 工作流 → 添加工作流 → 复制默认工作流。在编辑器中把多余状态删掉，保留或新建四个状态，然后按 JSON 里的四组流转把它们连起来。

这里最需要盯紧的字段是 category。category 为 done 的状态，JIRA 才会在燃尽图里把这张卡记为“已完成”；inprogress 状态始终算未完成。如果把“待验收”标成 done，Sprint 还没结束、测试根本没验收，卡片也会被燃尽图算作完成，曲线提前触底。等 Sprint 过完你才发现线上还有一堆没验完的功能，这就是 JIRA 里的经典误判来源。

建好工作流后，到项目管理 → 工作流方案里，把这份工作流分别绑定给 Story 和 Task。Bug 可以单独绑一个更短的流程：待处理 → 修复中 → 已关闭，不经过验收状态，因为缺陷的验收通常就是回归测试通过。

3.3 看板列映射与泳道：列数不等于状态数

看板是把工作流状态“可视化”出来的面板。很多人以为建了工作流看板就自动正确，实际上看板有一个独立的配置项：列设置。

在 Board → 配置 → 列设置里，把列与工作流状态做映射。推荐四列对应四个状态：待处理、处理中、待验收、已关闭。这里有一条 JIRA 的铁律：一列可以挂多个状态，但一个状态不能挂在多个列里。如果团队流程简单，就不要做“待验收合并进处理中列”这种压缩操作——否则卡片到了待验收还停在“处理中”列，燃尽图和看板口径就分叉了。

泳道建议按 Epic 划分。每张 Story 关联一个 Epic，看板自动按 Epic 分组，一条泳道就是一个交付主题。这样 Sprint 计划会上扫一眼泳道，就能看出哪些能力的进度落后。少数按个人分工的团队也可以按经办人分泳道，但它会让每行人数不均，空行占屏幕，我实际用下来体验一般。

排序列用 rank 字段。JIRA 里 Backlog 的拖拽顺序最终都落在 rank 上，看板默认按它排序。不要手动编辑 rank 数字，在 Backlog 里拖拽才是正路。

注意：列映射做完后，如果某张卡片在看板里消失了，第一反应去查“未映射状态”。这个问题在真实团队里出现的频率极高，后面避坑清单会专门展开。

4. 让 Sprint 真正滚动：估算刻度、JQL 边界与燃尽图的三种信号

Sprint 计划不是拍脑袋排期。JIRA 提供故事点、容量、速率、燃尽图这些数据，是为了让团队能在开工前用历史数据验证“这次承诺是否靠谱”。这一章讲怎么把数据用起来。

4.1 估算刻度：故事点给 Story，工时给 Task，速率算容量

故事点和工时是两个不同维度，混用是敏捷估算最常见的错误之一。

故事点描述“相对大小”，不是绝对时间。常见刻度是 1、2、3、5、8 五档，小团队建议砍掉 8，只用 1、2、3、5 四档。刻度越少，估算讨论越快，也更难通过把 3 改成 3.5 来回避分歧。工时则给 Task 用，一个明确的技术动作，比如“升级数据库驱动”“写迁移脚本”，以小时为单位，通常不做团队速度汇总。

排期的关键是速率：过去 3 到 5 个 Sprint 平均完成的故事点。下一个 Sprint 的容量建议取速率的 80%，留出缓冲处理计划外 Bug。JIRA 的速率图小工具会把这个值直接画出来，Sprint 计划会开始时打开它，比盯着待办列表更稳。

提示：Sprint 周期固定为两周。不要这轮两周、下轮三周，速率是在稳定周期下才有意义的统计量。

4.2 用 JQL 锁定范围：Backlog 候选、个人工作台与 Sprint 边界

JQL 是 JIRA 的查询语言，是排查和管理范围最重要的工具。下面四条是我基本每个 Sprint 都会用到的查询：

# 查询所有未进入当前 Sprint、还没关闭的 Story，作为排期候选 project = "某项目" AND issuetype = Story AND status != "已关闭" AND sprint not in openSprints() ORDER BY rank ASC # 当前 Sprint 中分配给当前用户的所有未完成卡片 sprint in openSprints() AND assignee = currentUser() AND status not in ("已关闭", "待验收") ORDER BY rank ASC # 上一个 Sprint 里产生的全部缺陷，用于复盘质量 sprint in completedSprints() AND issuetype = Bug # 当前 Sprint 里被测试打回过、当前是待处理的卡片 sprint in openSprints() AND status = "待处理" AND status changed to ("待处理") during (sprint)

说明几个关键函数：openSprints() 是 JIRA 的动态函数，自动解析所有未关闭的 Sprint，不用硬编码 Sprint ID；currentUser() 自动解析当前登录人，保存成筛选器后，任何人打开筛选器只能看到自己的卡片；rank 是 Backlog 排序专用字段，ORDER BY rank ASC 得到的顺序就是产品经理在 Backlog 里的拖拽顺序。

第四条 JQL 是排查“被打回的卡”用的。它统计的是：当前状态为待处理，并且在这个 Sprint 周期内曾经从其他状态迁回过待处理的卡片。数值越大，说明验收前移的需求越多，Sprint 初期的需求质量就在下降。

把这些 JQL 保存为筛选器后，分别加到看板的快捷视图和个人工作台。JIRA 的筛选器是共享资源，保存时选择“所有用户可见”，团队就能直接用你写好的这些查询，不用自己从头拼语法。

4.3 燃尽图不是画图目标：三种偏离节奏对应的团队状态

燃尽图只有两条线：理想线和实际线。多数团队只会看“今天是在理想线上面还是下面”，其实更该看的是曲线的形态。三种典型形态分别对应三类问题：

形态一：前平后陡。Sprint 前半段实际线几乎水平，后半段直线下降。这个信号说明团队没有及时更新卡片状态，开发可能早就在动手，但卡片一直停在“待处理”；另一个原因是 Sprint 前段需求还在讨论，开发根本没法进场。处理方式是约定每天下班前把处理中的卡移列，同时把 Story 拆到一两天能完成的大小，强迫自己在 Sprint 第一天就交付一点东西。

形态二：整条线高于理想线，收敛很慢。这说明承诺的故事点超过了团队实际速率。不要靠加班解决，而是下一个 Sprint 的容量按速率 × 80% 来排。连续两个 Sprint 都在高位收敛，就要回头检查估算时是不是被产品经理的“优先级”带着走。

形态三：前陡后平。Sprint 刚开始卡片就被大量关闭，但测试并没有真的验完。这是“完成定义”被稀释了：开发把代码提交当成了完成，测试验收动作被省略。处理方式是约定已关闭必须包含测试验收记录，并利用 JIRA 的已完成列审查功能，核对每张已关闭卡片是否有关联的测试备注。

另外还有一个容易被忽略的信号：范围线。JIRA 燃尽图会显示 Sprint 中途增加或移除的需求。范围线陡增说明计划外需求大量侵入，Sprint 目标在漂移。这个信号出现时，第一反应不是怪开发慢，而是检查产品经理是否绕过了排期流程直接加需求。

5. JIRA 敏捷项目管理避坑清单：五条反复踩的坑与解法

这一章是我在多个团队里看到的高频问题，每条都按“现象 → 原因 → 解决”拆开。读过之后，至少能帮你省下一个 Sprint 的排查时间。

5.1 看板列和工作流状态不一致，卡片悄悄消失

现象：某张卡明明被开发点成了“处理中”，看板上翻不到，Sprint 统计里的数字和卡片对不上。

原因：新增了工作流状态但没有同步到看板列映射。JIRA 会把这个状态放在“未映射的其他状态”里，不报错、不提醒，像 Excel 单元格里看不见的空格一样安静。

解决：打开 Board → 配置 → 列设置，检查页面底部有没有“未映射状态”分区。每次加状态时，顺手把列映射一起改。也可以用一条 JQL 把所有落出标准状态范围的卡片捞出来：

sprint in openSprints() AND status not in ("待处理", "处理中", "待验收", "已关闭")

这条查询的结果如果非空，说明有卡片掉在视野之外。把对应状态补进列映射，卡片立刻回来看板。

5.2 每个 Sprint 都遗留卡片：Sprint 漂移毁掉速率数据

现象：每个 Sprint 收尾时总有几张 Story 没完成，团队习惯把它们直接拖到下个 Sprint 继续。燃尽图看起来很平顺，实际交付却持续延期。

原因：未完成卡片平移到下个 Sprint，等于下个 Sprint 默认承担了“上个欠账 + 新承诺”，速率被虚高。这种承诺漂移会让团队逐步失去对容量的真实感知，最后所有估计都变成安慰剂。

解决：Sprint 结束时，未完成的卡片全部拖回 Backlog，从当前 Sprint 移除。回到 Backlog 后重新估算，等下个 Sprint 计划时再决定是否拉入。这样做的直接效果是：速率的计算只包含真正完成的 Story，每个未交付承诺都会在数据里留一个缺口。团队看到缺口，才会在下个 Sprint 主动把卡片拆小。

5.3 用故事点做跨团队横向对比，结果一团糟

现象：某公司管理层让各个项目组把故事点相加，折算成“产出量”横向排名。然后各团队开始抢着把大号拆分冲量，估算体系直接失效。

原因：每个团队对“1 点”的定义完全不同，JIRA 不会校验跨团队口径。故事点是团队内部的相对刻度，不是产值计量单位。

解决：跨团队只对比比率，不比绝对值。两个指标够用：预估准确率（实际完成故事点除以计划故事点，0.8 到 1.2 之间算健康）和完工率（Sprint 关闭状态 Story 占计划 Story 的比例）。给管理层汇报时，明确说明这两项的统计口径，避免大家拿速率图当 KPI。

5.4 权限配置与角色不一致，透明性变成黑匣子

现象：测试看不到“待验收”列；产品只能看自己创建的 Epic，看不到 Sprint 整体进度；新同事看不到历史卡片，只能盯自己的任务。

原因：Company-managed 项目默认按全局权限模型控制，如果没有专门按项目角色调整，会出现要么全员可见、要么啥都不可见的极端情况。

解决：在项目设置里建项目角色，至少区分：产品、开发、测试、项目管理。按角色分配权限，核心原则是“查看和评论全员开放，编辑和流转按角色收口”。具体到操作：所有项目成员可查看 Sprint 和 Backlog；创建 Story 仅产品和项目管理；创建 Task 和 Sub-task 开发可执行；流转到已关闭仅测试和产品可操作。

5.5 自动化规则变成“踢皮球机器人”，通知爆炸

现象：团队建了一条自动化规则：状态变成待验收时自动把经办人改给测试。结果某天一张卡被自动来回踢了三轮，群里通知刷屏，大家都不知道下一步该谁动。

原因：自动化规则作用在任意一次状态流转上，没有加触发条件，也没限制经办人字段。卡片在待处理和待验收之间来回切换时，规则被反复触发，形成循环。

解决：给每条自动化规则加条件守卫。比如“仅当经办人为空时才自动指派”“仅当发起人不是测试角色时才通知”。JIRA 的自动化规则里有日志功能，能看到每条规则每次被触发时为什么执行、为什么跳过。先从一个最小规则跑一个 Sprint，验证可靠后再加第二条，不要一次性堆五条规则上去。

6. 让 JIRA 真正成为团队节奏的一部分：批量校验、仪表盘与复盘验证

配置完成只是开始。JIRA 的价值要持续注入，靠的是每次迭代结束后的校验动作。这一章给三个具体技巧。

6.1 用 REST API 批量校验 Sprint 状态，别手工翻板

每次 Sprint 中后期，我都会跑一遍脚本确认没有卡片掉在异常状态。用 REST API 比手工翻看板快得多：

# -*- coding: utf-8 -*- import requests from requests.auth import HTTPBasicAuth # 替换为你的站点域名、登录邮箱和 API Token BASE_URL = "https://你的站点.atlassian.net" AUTH = HTTPBasicAuth("你的邮箱", "你的API令牌") # 查询当前所有未关闭的 Story jql = 'sprint in openSprints() AND issuetype = Story AND status != "已关闭"' resp = requests.get( f"{BASE_URL}/rest/api/2/search", params={"jql": jql, "maxResults": 100, "fields": "summary,status,assignee"}, auth=AUTH, timeout=15, ) resp.raise_for_status() for issue in resp.json().get("issues", []): print(issue["key"], issue["fields"]["summary"], issue["fields"]["status"]["name"])

这里用 /rest/api/2/search 这个传统端点，兼容性最好，新老实例基本都能跑。fields 参数只取 summary、status、assignee，能明显减轻服务端响应压力。maxResults 默认是 50，查询结果超过 50 条时要用 startAt 参数翻页，上面的脚本简化了翻页，适合卡片量少于 100 的团队。API 令牌在个人头像 → 安全设置里生成，不要用登录密码直接调接口。

6.2 把关键指标放上仪表盘：速率、缺陷、Backlog 健康度

我会在每个项目里建一个共享仪表盘，放三个小工具：速率图、未关闭缺陷列表、当前 Sprint 状态分布饼图。速率图排期时看，缺陷列表每天扫一眼，状态分布图在每日站会投屏用。

实现方式不复杂：把第 4 章的 JQL 保存为筛选器，然后在仪表盘添加小工具时选择按筛选器生成。饼图按状态分组，能直接看到“待验收堆积了多少张卡”——这个数字一旦超过 Sprint 卡片总量的一半，就要在站会上专门讨论验收瓶颈。

6.3 复盘时用 JQL 验证流程是否被遵守

迭代复盘不要只凭印象。用两条 JQL 检查流程执行情况：

# 复盘：上个 Sprint 里没有正常关闭的 Story project = "某项目" AND sprint in completedSprints() AND issuetype = Story AND status not in ("已关闭") # 复盘：没有关联 Epic 的 Story project = "某项目" AND sprint in completedSprints() AND issuetype = Story AND "Epic Link" is EMPTY

第一条查的是 Sprint 结束仍没关闭的卡片。如果数量多，说明“完成定义”没有被执行，团队在赶工时把验收环节压扁了。第二条查的是没关联 Epic 的 Story。产品经理如果没把 Story 挂进 Epic，Backlog 无法按交付主题汇总，Sprint 计划会变成零散任务的拼凑。

我过去带团队时最满意的一次调整，是把工作流状态从 11 个砍到 4 个。第一个 Sprint 大家觉得不习惯，第二个 Sprint 燃尽图第一次贴住了理想线。后来我养成的习惯是：每个 Sprint 结束花 15 分钟，用这三条 JQL 做一次流程体检。先怀疑工作流，再怀疑人。JIRA 不是黑匣子，它只是把团队的管理习惯忠实地放大给你看。希望帮到你。

本文还有配套的精品资源，点击获取