简介围绕“基于JIRA的敏捷开发项目管理”这一主题面向产品负责人、Scrum Master及研发测试成员梳理Scrum角色分工、迭代流程与JIRA工具配置的对应关系适合初、中级团队导入敏捷管理时参考。压缩包共1个docx文件大小约6.55MB内容集中便于按章节查阅和团队内部分享目前已有3424人学习。文档覆盖product owner、scrum master与scrum team的职责边界并展开头脑风暴、需求筛选、工作量估算、Sprint拆分和评估复盘五个环节同时说明时间燃尽图、每日站会、bugs sprint等实践。还结合项目计划表、JIRA用户准备、Scrum项目与Boards搭建呈现从任务拆分到进度跟踪的落地思路帮助读者理解如何借助JIRA提升敏捷项目的协作与交付效率。1. 白板上的 Scrum 搬进 JIRA第一个 Sprint 最容易翻车的地方「JIRA 敏捷」这套组合在小团队里几乎成了默认选项但我见过太多团队第一个 Sprint 就翻车白板上 to do / in progress / done 三列跑得挺顺一进 JIRA 就变成一堆没有估时、没有子任务的 Story燃尽图从第一天就是一条平线。问题不在工具在于白板时代那套「口头拆分 口头估时」没有落成字段和状态机。这份资料把 Scrum 的五个步骤——头脑风暴、需求减法与 PRD、工作量估算、Sprint 循环、评估——和 JIRA 的建项目、建 Board、版本周期设置串成了一条线。它适合 10 人以内、正准备从白板迁移到系统化管理的开发测试团队也适合 Scrum Master 拿去对照自查你手上的 Sprint到底是真在迭代还是只是把任务换了个地方存。2. 角色与工作项建模把三个角色落成 JIRA 权限和三层任务2.1 Product Owner、Scrum Master、Scrum Team 在 JIRA 里的权限边界原文对三个角色的定义很干脆Product Owner 是能对功能流程、业务流程拍板的人Scrum Master 是解决团队各类问题、领导项目的人Scrum Team 是具体开发和测试的人。这三句话在白板上靠人盯在 JIRA 里必须翻译成权限否则「拍板」和「改需求」会混成一件事。我一般的分法是Scrum Master 给项目的 Administrators因为他要管 Board 配置、Sprint 启停、字段方案和版本设置这些动作开发人员不需要开发和测试给 Developers能改状态、能填估时、能拆子任务、能被分配 issue但不能动 Sprint 范围和 Board 配置Product Owner 给 Users 或者单独建一个「需求评审」组能建 Story、能排优先级、能在验收时改状态但不给「管理 Sprint」的权限。最后这条边界最容易被妥协。很多团队觉得 PO 是需求方给管理员省事结果就是 Sprint 进行到第三天PO 直接往当前 Sprint 里塞了五个 Story燃尽图当场往上翘。这不是 PO 的问题是权限设计把「变更」变成了零成本动作。需求变更本身没错错的是它没有留下痕迹。角色JIRA 项目角色该给的能力不该给的能力Product OwnerUsers / 需求评审组建 Story、排优先级、验收改状态改 Sprint 范围、改 Board 配置Scrum MasterAdministrators管 Board、启停 Sprint、管字段与版本代替 PO 对需求拍板Scrum TeamDevelopers改状态、填估时、拆子任务管理 Sprint、修改版本还有一层是「拍板」怎么在系统里体现。我的做法是给 Story 加一个简单的选择字段值只有「待确认 / 已确认 / 变更中」PO 确认后才允许拉进 Sprint。这个字段不复杂但它把口头承诺变成了可查的记录周会上不用再翻聊天记录对质。2.2 先建用户和组再建项目顺序反了就是一堆空的下拉框原文的准备工作第二条写得很明确团队中所有成员必须已经在 JIRA 中建立用户并可以正常登陆。这个顺序不能反。JIRA 的项目角色绑定的是用户或组人没建、组没进后面分配 issue 时 Assignee 下拉框就是空的很多人第一反应是「权限出 bug 了」其实是用户根本没进这个项目角色。常见做法是三层全局建用户 → 建组比如 dev-team、qa-team、po-group→ 项目角色绑组而不是逐个用户绑。人员流动时只改组成员不动项目配置这是运维习惯能省掉大量重复劳动。下面这段是 Cloud 版的建用户和入组调用Server 版的路径和字段名略有差异按自己实例的 API 文档调。# 建用户emailAddress 必须是唯一登录名products 决定能访问哪些应用 curl -s -u $JIRA_USER:$JIRA_TOKEN \ -X POST $JIRA_BASE/rest/api/3/user \ -H Content-Type: application/json \ -d {emailAddress:dev1example.com,displayName:dev1,products:[jira-software]} # 把用户加入开发组groupId 或 groupname 二选一按实例返回的字段来 curl -s -u $JIRA_USER:$JIRA_TOKEN \ -X POST $JIRA_BASE/rest/api/3/group/user?groupnamedev-team \ -H Content-Type: application/json \ -d {accountId:上一步返回的 accountId}参数说明JIRA_USER用管理员账号JIRA_TOKEN用 API token 而不是登录密码JIRA_BASE是实例地址且末尾不要带斜杠。products字段决定这个账号有没有 JIRA Software 的许可漏了这一步用户能登录但进不了 Board现象很像权限故障。执行完别急着往下走先做一次验证用新账号登录打开目标项目看能不能被分配 issue、能不能看到 Board。这一步花两分钟比后面排查半小时划算。2.3 Epic、Story、Sub-task 三层拆分与那条 16 小时线原文给了一条很硬的标准最小任务量的工作小时不能超过 16 小时。这条线在 JIRA 里就是拆分的触发器不是建议值。我一般这样映射三层工作项Epic 对应一个功能域或者一个 Sprint 目标下的大块Story 对应可独立验收的功能点Sub-task 对应 16 小时以内的工作包原型、logo、UI、前端、接口、测试各成一条。这里有个 JIRA 的硬约束要提前知道Sub-task 不能跨 Sprint也不能单独拖进 Backlog 排序它永远挂在父 Story 下面。所以拆分要拆在 Story 内部而不是把一堆零散任务直接建成 Story 再指望 Board 帮你归类。父 Story 的估时可以是子任务之和也可以留空但子任务必须逐条填 Original Estimate否则燃尽图算不出来。Issue TypeSummaryOriginal Estimate说明Story登录模块空父级按功能验收Sub-task登录页原型8h未超过 16hSub-task登录页 UI 设计6h未超过 16hSub-task登录接口开发12h未超过 16hSub-task登录前端联调14h未超过 16hSub-task登录用例与回归8h未超过 16h拆分完成后跑一遍校验比人眼扫表格可靠。这段脚本读计划 CSV把所有超过 16 小时的行打出来导入前先修一遍。import csv LIMIT 16 # 单个最小任务的小时上限来自 Scrum 的工作量估算标准 with open(plan.csv, encodingutf-8) as f: for row in csv.DictReader(f): raw (row.get(estimate_hours) or ).strip() if not raw: print(f[缺估时] {row[summary]}) continue hours float(raw) if hours LIMIT: print(f[需拆分] {row[summary]} 估时 {hours}h超出 {hours - LIMIT}h)逻辑很直白先判空再比大小空估时和超估时是两类问题分开报。参数只有LIMIT一个团队如果约定 12 小时或者 2 天改这个常量就行但改完要同步到 Board 的统计口径否则脚本按 16 小时校验、燃尽图按别的口径算两边对不上。2.4 项目计划表怎么变成 JIRA 字段映射定死再导入原文第三步会输出一张项目计划表JIRA 的 Scrum 管理就是基于这张表。我的习惯是先把列定死再谈导入列不定死后面每加一个字段就要重导一次。常用映射如下计划表列JIRA 字段填写要点模块Component一个 issue 只挂一个主模块别当标签用标题Summary动词开头写完能判断是否可验收估时Original Estimate表格里写小时REST 接口传秒优先级Priority只留三档多了等于没有负责人Assignee必须是已进项目角色的用户目标版本Fix Version和 Sprint 不是一回事后面单独讲验收标准Description至少写一条可执行的判断条件这里有个非常容易翻车的参数JIRA 的 Original Estimate 字段内部按秒存储。CSV 导入时写8h通常能被解析但走 REST API 时必须传28800传 8 会被当成 8 秒燃尽图直接失真到没法看。我见过有人排查了一下午「为什么估时显示 0m」最后发现是单位问题这种坑属于看一遍就能避开、没看就必然踩的类型。3. Board 与 Sprint 搭建从项目容器到版本开发周期的顺序3.1 先有项目再有 BoardBoard 的本质是一条 JQL原文写「建立一个 Scrum 的 Boards同时也建好了项目」这是 JIRA 的便利之处用 Scrum 模板建项目时会自动带一个 Board。但顺序要理解清楚Board 只是一个视图它靠 filter 圈定 issue 范围项目才是容器。不理解这层关系后面就会遇到「新建的 Task 在 Board 上不显示」这类问题。常见做法是建完项目先去看一眼 Board 的 filter。默认 filter 往往限定了 issue 类型只包含 Story、Bug、Task 中的某几种如果团队习惯用「技术任务」这种自定义类型它就不会出现在 Board 上。改法有两种改 filter 把类型加进去或者统一团队的工作项类型后者更根本。建项目的步骤大致是选 Scrum 模板 → 填项目名称和 key → 确认 Board 生成 → 检查列配置 → 检查估时统计字段。key 一旦定下不建议改它会出现在所有 issue 编号和 JQL 里改一次等于全量重写查询。建完之后做一次冒烟验证手动建一条 Story填 8h 估时看它是否出现在 Board 的 To Do 列看 Sprint 下拉框能不能选中。三步都通过再往里面批量导入。3.2 三列不够用列与状态的映射要一次定对白板只有三列是物理限制JIRA 里没必要照抄。我一般用五个状态To Do、In Progress、In Review、Done再加上用 Flag 标记的阻塞或者单独一个 Blocked 状态。列配置的关键不是列名好看而是每一列的进入和退出条件明确。列包含状态进入条件退出条件待办To Do已估时、已排进 Sprint有人开始动手进行中In Progress已分配负责人代码提交并自测通过评审中In Review有可评审的产出评审通过或打回完成Done验收标准逐条满足Sprint 结束后不再变动状态流转靠 workflow 的 condition 和 validator 卡住。比如「没有填写测试结论不能进 Done」「没有关联版本不能进评审」这类规则写在 workflow 里比写在制度文档里有效得多因为制度会被绕过validator 不会。代价是配置麻烦但一次配好能管很久。还要注意 Board 的列映射是「状态 → 列」一个列可以包含多个状态但一个状态只能落在一列。有人把 Done 和 In Review 放同一列结果累积流图看不出评审堆积等于自己把瓶颈藏起来了。3.3 Sprint 切分按重要度排按上一轮的实际完成量定容量原文的顺序是先做主要功能再到次要功能再到小功能最后的 Sprint 一般修 bug。这个顺序没问题但落地要补两个约束否则 Sprint 会变成「这个月要干完的事」的别名。第一个约束是每个 Sprint 必须有独立可验收的目标。不是「完成登录和支付」而是「用户能用手机号登录并完成一笔测试支付」。目标写得出来Sprint 评审才有东西可看。第二个约束是容量按上一 Sprint 的实际完成量定不按「大家都很努力」定。头两个 Sprint 没有历史数据宁可保守按总估时的六成排跑完两轮再调。Sprint目标内容范围容量参考Sprint 1核心链路可走通主要功能的原型、UI、主流程开发上一轮完成量的 100%Sprint 2主流程闭环次要功能、接口联调同上允许 ±10%Sprint 3边缘场景补齐小功能、异常分支同上Sprint 4可交付集中修 bug、回归预留 30% 给缺陷Sprint 的起止日期要填不填的话燃尽图的理想线画不出来。长度上 10 人以内团队用两周比较稳一周太短、光开会就占掉不少时间四周太长、范围变化压不住。3.4 版本开发周期设置Fix Version 不是 Sprint原文提到「版本开发周期设置」这一步经常被跳过然后所有人把版本和 Sprint 当同义词用。两者关系是多对多一个版本可以跨多个 Sprint 交付一个 Sprint 也可能只覆盖版本的一部分。版本回答「什么时候交付什么」Sprint 回答「这两周做什么」。建版本的要点是填开始日期和发布日期然后把 issue 关联到版本。版本发布release时未完成的 issue 会被移到哪个版本、要不要移这一步必须人工确认。默认行为不一定符合预期直接点发布很容易出现「版本发了但功能没上」的黑匣子事后只能靠翻历史记录还原。# 建 SprintoriginBoardId 必填日期用 ISO 8601 带时区 curl -s -u $JIRA_USER:$JIRA_TOKEN \ -X POST $JIRA_BASE/rest/agile/1.0/sprint \ -H Content-Type: application/json \ -d {\name\:\Sprint 1\,\startDate\:\${START}\,\endDate\:\${END}\,\originBoardId\:${BOARD_ID}} # 建版本project 用项目 keyreleaseDate 决定版本报告的时间轴 curl -s -u $JIRA_USER:$JIRA_TOKEN \ -X POST $JIRA_BASE/rest/api/3/version \ -H Content-Type: application/json \ -d {\name\:\v1.0\,\project\:\AGILE-DEMO\,\startDate\:\${START_DATE}\,\releaseDate\:\${RELEASE_DATE}\}参数说明START、END用2025-01-06T09:00:00.00008:00这种带时区的格式只写日期部分时区会按服务器默认走跨时区团队会对不上BOARD_ID是数字从 Board 地址栏里取project用 key 不用项目名。两个接口都要求调用者有对应权限Scrum Master 账号能跑通普通开发账号会返回 403这是权限设计生效的表现不是接口坏了。4. 燃尽图与站会把每天 10 分钟变成可追溯的数据4.1 燃尽图的三条线以及每天必须更新的那个字段JIRA 的 Sprint 燃尽图上有三条线理想线从 Sprint 第一天的总估时一路降到零剩余工作线按每天的实际剩余估时绘制范围变化线记录 Sprint 期间估时的增减。原文说「不管任务是否按时完成都必须记录」翻译成 JIRA 的操作就是每天更新 Remaining Estimate而不是只在任务完成时把状态改成 Done。这里有个模式选择Remaining Estimate 可以设成「完成时自动清零」也可以设成「手动填写剩余」。前者省事但失真一个 16 小时的任务做了 12 小时图上还显示 16最后一天突然掉到 0曲线像悬崖。后者每天多花十秒但曲线是真实的。我一般建议 Scrum 团队用手动模式尤其是新团队前两个 Sprint 的曲线形状比数字本身更有参考价值。燃尽图的统计字段也要对齐。Board 设置里 Estimation Statistic 可以选 Story Points 或 Original Estimate选哪个图上算的就是哪个。团队按小时估时就选后者别一边按小时填、一边用故事点画图两条数据永远对不上。4.2 站会三问对应 JIRA 上的三个动作原文的三问很经典今天做了什么、明天打算做什么、遇到什么困难。落到 JIRA 上这三问其实对应三个动作而且动作要发生在会前不是会上。站会三问JIRA 动作谁来做时机今天做了什么完成项状态流转剩余估时清零任务负责人会前 5 分钟明天打算做什么从 To Do 拉到 In Progress确认负责人任务负责人会前 5 分钟遇到什么困难打 Flag 标记或在评论里写明阻塞原因任务负责人会上口述会后补录站会本身控制在 10 分钟左右。做法是站着开、按 Board 从左到右过、只讲三问、不在会上解决技术问题。遇到的困难记下来Scrum Master 会后单独跟进这是他的核心职责原文写得很清楚解决开发团队的困难让项目快速进展下去。会上不要现场改 JIRA一改就会有人开始讨论字段怎么填十分钟变半小时。会前更新、会上只对齐这个习惯坚持两个 Sprint 就能固定下来。4.3 周会看燃尽月会看版本视图选错了会白开周会由 Scrum Master 主持Product Owner 最好在场看三样东西当前 Sprint 的燃尽图、未完成项清单、被 Flag 的阻塞项。周会要出的决策只有一个剩下这几天范围要不要调。调就明说记进范围线不调就接受别在会上反复讨论。月会由 Product Owner 主导看的是版本层面的东西版本报告能预测按当前速度什么时候能发累积流图能看出哪个列在堆积堆积的地方就是瓶颈控制图能看单个任务的周期时间分布尾部特别长的那些就是反复返工的类型。会议频率主要视图要出的决策站会每天Board 当前列今天谁做什么、谁被卡住周会每周Sprint 燃尽图、未完成清单范围是否调整月会每月版本报告、累积流图版本是否延期、瓶颈在哪评审每 Sprint已完成项与验收标准是否接受本 Sprint 产出原文说月会上 Product Owner 要指出产品开发是否在期待范围内这句话的重量在于如果月会只看完成率百分比PO 是判断不出来的必须看版本报告的时间预测和累积流图的趋势。4.4 燃尽图不动时的排查顺序最常被问的一个问题是「燃尽图怎么是一条平线」。按下面这个顺序查基本三轮内能定位别一上来就怀疑工具。顺序检查项判断依据1Sprint 是否已开始Sprint 状态是 Future 时不出图2issue 是否有估时Original Estimate 为空的不计入3Board 统计字段选的是故事点还是原始估时4Board filter 范围当前 issue 类型是否被 filter 排除5剩余估时是否有人更新全自动清零模式下曲线会失真第 2 项和第 5 项占了我遇到的绝大多数情况。前者是导入时漏了估时后者是团队没人改剩余时间。两个都不是配置问题是流程问题改配置解决不了。5. 避坑与排查五条从平线燃尽图到失控 Sprint 的血泪记录5.1 估时与燃尽图相关的问题现象Sprint 开始第三天燃尽图还是一条贴着零的直线团队明明每天都在提交代码。原因Story 只填了 Story Points没填 Original Estimate而 Board 的统计字段选的是 Original Estimate。两边口径不一致图上自然什么都没算进去。另一种情况是估时从 CSV 导入时单位传错8 小时变成 8 秒图上看起来工作量约等于零。解决先统一口径团队按小时管理就把统计字段设成 Original Estimate按点数管理就全部改用 Story Points不要混。然后跑一次 JQL 把所有估时为空且未完成的 issue 拉出来补齐导入脚本里加单位校验REST 传秒、界面填小时、CSV 写8h三处对齐之后再导。现象Sprint 进行到一半燃尽图突然往上翘Product Owner 在会上问是不是进度造假。原因中途往当前 Sprint 加了新 Story而且带了估时。范围线确实记录了这次变化但没有人提前说过图上看起来就是「活越干越多」。这种情况在权限给得太宽的团队里特别常见。解决加需求走变更流程要么换出等量任务保持总量不变要么明确记入范围线并在周会上说明原因。关键不是禁止变更是让变更可见。同时把「管理 Sprint」的权限从开发组收走只留 Scrum Master。5.2 Sprint 节奏与流程相关的问题现象连续几个 Sprint 的完成量忽高忽低规划时完全没法参考团队自己也不信这个数字。原因上一个 Sprint 结束时没有点 Complete Sprint未完成的 issue 一直挂在原 Sprint 里或者被直接拖进下一个 Sprint 但没有重新估剩余时间。两种做法都会让速度统计把「没做完的」和「做完了的」混在一起算。解决每个 Sprint 到期必须关闭未完成项选择移到 Backlog 或下一个 Sprint移之前重新估剩余工时。这条执行两轮之后速度数据才有参考价值。关闭 Sprint 时那句「未完成项去哪」的确认不要一路回车逐个看一眼。现象站会开 25 分钟一半时间在对 JIRA 字段另一半在讨论技术方案。原因会前没人更新 Board所有人到会上才开始回忆昨天干了什么Scrum Master 习惯在会上直接解决问题一讨论就收不住。时间一长站会变成汇报会大家开始抵触。解决会前 5 分钟各自更新状态和剩余估时会上只回答三问遇到需要讨论的问题记在便签上会后拉相关的人单聊用一个看得见的计时器超过 12 分钟就截断。前一周会很别扭第二周就顺了。5.3 权限与流程约束相关的问题现象一条 Story 从 To Do 直接跳到 Done中间没有评审记录问起来说「昨天就测过了」。原因Developers 组被给了过宽的权限workflow 里也没有任何 condition 拦住状态跳转。工具层面允许一步到位流程层面就一定会有人图省事。解决收权限同时给 workflow 加 condition比如「没有测试结论字段不能进 Done」「没有关联版本不能进评审」。规则写在工具里比写在制度文档里有效因为绕过工具需要额外操作绕过文档只需要忘性。现象Sprint 结束做评审PO 说这不是我要的团队说需求文档上就是这么写的双方各执一词。原因Story 的描述里只有一句功能名没有可执行的验收标准PO 在开发过程中也没有参与过中间确认只在最后出现。解决每条 Story 的 Description 至少写一条能判断真假的验收条件比如「输入错误验证码三次后锁定十分钟」。周会请 PO 到场看的是当前 Sprint 的完成项而不是文档。评审时对着验收标准逐条过不过就是不过进下一个 Sprint 修。6. JQL 与关闭核对把 Scrum 数据变成能复查的证据前面所有配置最终都要落到「能查出来」。JQL 是 JIRA 里最值得花半小时学的东西下面几条是我每个项目都会存的过滤器直接改项目 key 就能用。-- 当前 Sprint 未完成周会前必看 project AGILE-DEMO AND sprint in openSprints() AND status ! Done -- 估时为空且未完成燃尽图平线的头号嫌疑 project AGILE-DEMO AND originalEstimate is EMPTY AND status ! Done -- 估时超过 16 小时该拆没拆的 project AGILE-DEMO AND originalEstimate 16h AND status ! Done -- 被标记阻塞的站会后 Scrum Master 跟进 project AGILE-DEMO AND flagged is not EMPTY -- 跨 Sprint 遗留速度失真的来源 project AGILE-DEMO AND sprint in closedSprints() AND status ! Done参数说明project换成自己的项目 key带连字符要加引号16h里的h是 JQL 的时间单位也可以写2dflagged在部分实例里显示名不同以字段实际 ID 为准。这几条查询可以存成过滤器挂到仪表盘上周会直接投屏不用现场敲。真正让数据可信的不是查询是关闭 Sprint 前的核对动作。我现在固定走五步先跑「估时为空」确认没有漏估再跑「当前 Sprint 未完成」逐条决定去留然后检查每条未完成项是否重估了剩余时间接着确认版本关联没有漏最后才点 Complete Sprint。五步加起来不到十分钟但能避免后面花两小时解释为什么速度曲线像心电图。这个习惯是被坑出来的。早些年我图快Sprint 到点直接关闭未完成项一股脑拖进下一个 Sprint估时原样带过去结果连续三个 Sprint 的速度数据全是错的规划会上没人信那张表最后只能手工翻 issue 历史重新算。从那以后我每次关闭 Sprint 前都强制走一遍这五步宁可慢十分钟不再给自己留后悔药。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/29 0:04:47 · 阅读 1.2k JIRA敏捷落地：Scrum角色权限、Sprint与燃尽图避坑指南
简介围绕“基于JIRA的敏捷开发项目管理”这一主题面向产品负责人、Scrum Master及研发测试成员梳理Scrum角色分工、迭代流程与JIRA工具配置的对应关系适合初、中级团队导入敏捷管理时参考。压缩包共1个docx文件大小约6.55MB内容集中便于按章节查阅和团队内部分享目前已有3424人学习。文档覆盖product owner、scrum master与scrum team的职责边界并展开头脑风暴、需求筛选、工作量估算、Sprint拆分和评估复盘五个环节同时说明时间燃尽图、每日站会、bugs sprint等实践。还结合项目计划表、JIRA用户准备、Scrum项目与Boards搭建呈现从任务拆分到进度跟踪的落地思路帮助读者理解如何借助JIRA提升敏捷项目的协作与交付效率。1. 白板上的 Scrum 搬进 JIRA第一个 Sprint 最容易翻车的地方「JIRA 敏捷」这套组合在小团队里几乎成了默认选项但我见过太多团队第一个 Sprint 就翻车白板上 to do / in progress / done 三列跑得挺顺一进 JIRA 就变成一堆没有估时、没有子任务的 Story燃尽图从第一天就是一条平线。问题不在工具在于白板时代那套「口头拆分 口头估时」没有落成字段和状态机。这份资料把 Scrum 的五个步骤——头脑风暴、需求减法与 PRD、工作量估算、Sprint 循环、评估——和 JIRA 的建项目、建 Board、版本周期设置串成了一条线。它适合 10 人以内、正准备从白板迁移到系统化管理的开发测试团队也适合 Scrum Master 拿去对照自查你手上的 Sprint到底是真在迭代还是只是把任务换了个地方存。2. 角色与工作项建模把三个角色落成 JIRA 权限和三层任务2.1 Product Owner、Scrum Master、Scrum Team 在 JIRA 里的权限边界原文对三个角色的定义很干脆Product Owner 是能对功能流程、业务流程拍板的人Scrum Master 是解决团队各类问题、领导项目的人Scrum Team 是具体开发和测试的人。这三句话在白板上靠人盯在 JIRA 里必须翻译成权限否则「拍板」和「改需求」会混成一件事。我一般的分法是Scrum Master 给项目的 Administrators因为他要管 Board 配置、Sprint 启停、字段方案和版本设置这些动作开发人员不需要开发和测试给 Developers能改状态、能填估时、能拆子任务、能被分配 issue但不能动 Sprint 范围和 Board 配置Product Owner 给 Users 或者单独建一个「需求评审」组能建 Story、能排优先级、能在验收时改状态但不给「管理 Sprint」的权限。最后这条边界最容易被妥协。很多团队觉得 PO 是需求方给管理员省事结果就是 Sprint 进行到第三天PO 直接往当前 Sprint 里塞了五个 Story燃尽图当场往上翘。这不是 PO 的问题是权限设计把「变更」变成了零成本动作。需求变更本身没错错的是它没有留下痕迹。角色JIRA 项目角色该给的能力不该给的能力Product OwnerUsers / 需求评审组建 Story、排优先级、验收改状态改 Sprint 范围、改 Board 配置Scrum MasterAdministrators管 Board、启停 Sprint、管字段与版本代替 PO 对需求拍板Scrum TeamDevelopers改状态、填估时、拆子任务管理 Sprint、修改版本还有一层是「拍板」怎么在系统里体现。我的做法是给 Story 加一个简单的选择字段值只有「待确认 / 已确认 / 变更中」PO 确认后才允许拉进 Sprint。这个字段不复杂但它把口头承诺变成了可查的记录周会上不用再翻聊天记录对质。2.2 先建用户和组再建项目顺序反了就是一堆空的下拉框原文的准备工作第二条写得很明确团队中所有成员必须已经在 JIRA 中建立用户并可以正常登陆。这个顺序不能反。JIRA 的项目角色绑定的是用户或组人没建、组没进后面分配 issue 时 Assignee 下拉框就是空的很多人第一反应是「权限出 bug 了」其实是用户根本没进这个项目角色。常见做法是三层全局建用户 → 建组比如 dev-team、qa-team、po-group→ 项目角色绑组而不是逐个用户绑。人员流动时只改组成员不动项目配置这是运维习惯能省掉大量重复劳动。下面这段是 Cloud 版的建用户和入组调用Server 版的路径和字段名略有差异按自己实例的 API 文档调。# 建用户emailAddress 必须是唯一登录名products 决定能访问哪些应用 curl -s -u $JIRA_USER:$JIRA_TOKEN \ -X POST $JIRA_BASE/rest/api/3/user \ -H Content-Type: application/json \ -d {emailAddress:dev1example.com,displayName:dev1,products:[jira-software]} # 把用户加入开发组groupId 或 groupname 二选一按实例返回的字段来 curl -s -u $JIRA_USER:$JIRA_TOKEN \ -X POST $JIRA_BASE/rest/api/3/group/user?groupnamedev-team \ -H Content-Type: application/json \ -d {accountId:上一步返回的 accountId}参数说明JIRA_USER用管理员账号JIRA_TOKEN用 API token 而不是登录密码JIRA_BASE是实例地址且末尾不要带斜杠。products字段决定这个账号有没有 JIRA Software 的许可漏了这一步用户能登录但进不了 Board现象很像权限故障。执行完别急着往下走先做一次验证用新账号登录打开目标项目看能不能被分配 issue、能不能看到 Board。这一步花两分钟比后面排查半小时划算。2.3 Epic、Story、Sub-task 三层拆分与那条 16 小时线原文给了一条很硬的标准最小任务量的工作小时不能超过 16 小时。这条线在 JIRA 里就是拆分的触发器不是建议值。我一般这样映射三层工作项Epic 对应一个功能域或者一个 Sprint 目标下的大块Story 对应可独立验收的功能点Sub-task 对应 16 小时以内的工作包原型、logo、UI、前端、接口、测试各成一条。这里有个 JIRA 的硬约束要提前知道Sub-task 不能跨 Sprint也不能单独拖进 Backlog 排序它永远挂在父 Story 下面。所以拆分要拆在 Story 内部而不是把一堆零散任务直接建成 Story 再指望 Board 帮你归类。父 Story 的估时可以是子任务之和也可以留空但子任务必须逐条填 Original Estimate否则燃尽图算不出来。Issue TypeSummaryOriginal Estimate说明Story登录模块空父级按功能验收Sub-task登录页原型8h未超过 16hSub-task登录页 UI 设计6h未超过 16hSub-task登录接口开发12h未超过 16hSub-task登录前端联调14h未超过 16hSub-task登录用例与回归8h未超过 16h拆分完成后跑一遍校验比人眼扫表格可靠。这段脚本读计划 CSV把所有超过 16 小时的行打出来导入前先修一遍。import csv LIMIT 16 # 单个最小任务的小时上限来自 Scrum 的工作量估算标准 with open(plan.csv, encodingutf-8) as f: for row in csv.DictReader(f): raw (row.get(estimate_hours) or ).strip() if not raw: print(f[缺估时] {row[summary]}) continue hours float(raw) if hours LIMIT: print(f[需拆分] {row[summary]} 估时 {hours}h超出 {hours - LIMIT}h)逻辑很直白先判空再比大小空估时和超估时是两类问题分开报。参数只有LIMIT一个团队如果约定 12 小时或者 2 天改这个常量就行但改完要同步到 Board 的统计口径否则脚本按 16 小时校验、燃尽图按别的口径算两边对不上。2.4 项目计划表怎么变成 JIRA 字段映射定死再导入原文第三步会输出一张项目计划表JIRA 的 Scrum 管理就是基于这张表。我的习惯是先把列定死再谈导入列不定死后面每加一个字段就要重导一次。常用映射如下计划表列JIRA 字段填写要点模块Component一个 issue 只挂一个主模块别当标签用标题Summary动词开头写完能判断是否可验收估时Original Estimate表格里写小时REST 接口传秒优先级Priority只留三档多了等于没有负责人Assignee必须是已进项目角色的用户目标版本Fix Version和 Sprint 不是一回事后面单独讲验收标准Description至少写一条可执行的判断条件这里有个非常容易翻车的参数JIRA 的 Original Estimate 字段内部按秒存储。CSV 导入时写8h通常能被解析但走 REST API 时必须传28800传 8 会被当成 8 秒燃尽图直接失真到没法看。我见过有人排查了一下午「为什么估时显示 0m」最后发现是单位问题这种坑属于看一遍就能避开、没看就必然踩的类型。3. Board 与 Sprint 搭建从项目容器到版本开发周期的顺序3.1 先有项目再有 BoardBoard 的本质是一条 JQL原文写「建立一个 Scrum 的 Boards同时也建好了项目」这是 JIRA 的便利之处用 Scrum 模板建项目时会自动带一个 Board。但顺序要理解清楚Board 只是一个视图它靠 filter 圈定 issue 范围项目才是容器。不理解这层关系后面就会遇到「新建的 Task 在 Board 上不显示」这类问题。常见做法是建完项目先去看一眼 Board 的 filter。默认 filter 往往限定了 issue 类型只包含 Story、Bug、Task 中的某几种如果团队习惯用「技术任务」这种自定义类型它就不会出现在 Board 上。改法有两种改 filter 把类型加进去或者统一团队的工作项类型后者更根本。建项目的步骤大致是选 Scrum 模板 → 填项目名称和 key → 确认 Board 生成 → 检查列配置 → 检查估时统计字段。key 一旦定下不建议改它会出现在所有 issue 编号和 JQL 里改一次等于全量重写查询。建完之后做一次冒烟验证手动建一条 Story填 8h 估时看它是否出现在 Board 的 To Do 列看 Sprint 下拉框能不能选中。三步都通过再往里面批量导入。3.2 三列不够用列与状态的映射要一次定对白板只有三列是物理限制JIRA 里没必要照抄。我一般用五个状态To Do、In Progress、In Review、Done再加上用 Flag 标记的阻塞或者单独一个 Blocked 状态。列配置的关键不是列名好看而是每一列的进入和退出条件明确。列包含状态进入条件退出条件待办To Do已估时、已排进 Sprint有人开始动手进行中In Progress已分配负责人代码提交并自测通过评审中In Review有可评审的产出评审通过或打回完成Done验收标准逐条满足Sprint 结束后不再变动状态流转靠 workflow 的 condition 和 validator 卡住。比如「没有填写测试结论不能进 Done」「没有关联版本不能进评审」这类规则写在 workflow 里比写在制度文档里有效得多因为制度会被绕过validator 不会。代价是配置麻烦但一次配好能管很久。还要注意 Board 的列映射是「状态 → 列」一个列可以包含多个状态但一个状态只能落在一列。有人把 Done 和 In Review 放同一列结果累积流图看不出评审堆积等于自己把瓶颈藏起来了。3.3 Sprint 切分按重要度排按上一轮的实际完成量定容量原文的顺序是先做主要功能再到次要功能再到小功能最后的 Sprint 一般修 bug。这个顺序没问题但落地要补两个约束否则 Sprint 会变成「这个月要干完的事」的别名。第一个约束是每个 Sprint 必须有独立可验收的目标。不是「完成登录和支付」而是「用户能用手机号登录并完成一笔测试支付」。目标写得出来Sprint 评审才有东西可看。第二个约束是容量按上一 Sprint 的实际完成量定不按「大家都很努力」定。头两个 Sprint 没有历史数据宁可保守按总估时的六成排跑完两轮再调。Sprint目标内容范围容量参考Sprint 1核心链路可走通主要功能的原型、UI、主流程开发上一轮完成量的 100%Sprint 2主流程闭环次要功能、接口联调同上允许 ±10%Sprint 3边缘场景补齐小功能、异常分支同上Sprint 4可交付集中修 bug、回归预留 30% 给缺陷Sprint 的起止日期要填不填的话燃尽图的理想线画不出来。长度上 10 人以内团队用两周比较稳一周太短、光开会就占掉不少时间四周太长、范围变化压不住。3.4 版本开发周期设置Fix Version 不是 Sprint原文提到「版本开发周期设置」这一步经常被跳过然后所有人把版本和 Sprint 当同义词用。两者关系是多对多一个版本可以跨多个 Sprint 交付一个 Sprint 也可能只覆盖版本的一部分。版本回答「什么时候交付什么」Sprint 回答「这两周做什么」。建版本的要点是填开始日期和发布日期然后把 issue 关联到版本。版本发布release时未完成的 issue 会被移到哪个版本、要不要移这一步必须人工确认。默认行为不一定符合预期直接点发布很容易出现「版本发了但功能没上」的黑匣子事后只能靠翻历史记录还原。# 建 SprintoriginBoardId 必填日期用 ISO 8601 带时区 curl -s -u $JIRA_USER:$JIRA_TOKEN \ -X POST $JIRA_BASE/rest/agile/1.0/sprint \ -H Content-Type: application/json \ -d {\name\:\Sprint 1\,\startDate\:\${START}\,\endDate\:\${END}\,\originBoardId\:${BOARD_ID}} # 建版本project 用项目 keyreleaseDate 决定版本报告的时间轴 curl -s -u $JIRA_USER:$JIRA_TOKEN \ -X POST $JIRA_BASE/rest/api/3/version \ -H Content-Type: application/json \ -d {\name\:\v1.0\,\project\:\AGILE-DEMO\,\startDate\:\${START_DATE}\,\releaseDate\:\${RELEASE_DATE}\}参数说明START、END用2025-01-06T09:00:00.00008:00这种带时区的格式只写日期部分时区会按服务器默认走跨时区团队会对不上BOARD_ID是数字从 Board 地址栏里取project用 key 不用项目名。两个接口都要求调用者有对应权限Scrum Master 账号能跑通普通开发账号会返回 403这是权限设计生效的表现不是接口坏了。4. 燃尽图与站会把每天 10 分钟变成可追溯的数据4.1 燃尽图的三条线以及每天必须更新的那个字段JIRA 的 Sprint 燃尽图上有三条线理想线从 Sprint 第一天的总估时一路降到零剩余工作线按每天的实际剩余估时绘制范围变化线记录 Sprint 期间估时的增减。原文说「不管任务是否按时完成都必须记录」翻译成 JIRA 的操作就是每天更新 Remaining Estimate而不是只在任务完成时把状态改成 Done。这里有个模式选择Remaining Estimate 可以设成「完成时自动清零」也可以设成「手动填写剩余」。前者省事但失真一个 16 小时的任务做了 12 小时图上还显示 16最后一天突然掉到 0曲线像悬崖。后者每天多花十秒但曲线是真实的。我一般建议 Scrum 团队用手动模式尤其是新团队前两个 Sprint 的曲线形状比数字本身更有参考价值。燃尽图的统计字段也要对齐。Board 设置里 Estimation Statistic 可以选 Story Points 或 Original Estimate选哪个图上算的就是哪个。团队按小时估时就选后者别一边按小时填、一边用故事点画图两条数据永远对不上。4.2 站会三问对应 JIRA 上的三个动作原文的三问很经典今天做了什么、明天打算做什么、遇到什么困难。落到 JIRA 上这三问其实对应三个动作而且动作要发生在会前不是会上。站会三问JIRA 动作谁来做时机今天做了什么完成项状态流转剩余估时清零任务负责人会前 5 分钟明天打算做什么从 To Do 拉到 In Progress确认负责人任务负责人会前 5 分钟遇到什么困难打 Flag 标记或在评论里写明阻塞原因任务负责人会上口述会后补录站会本身控制在 10 分钟左右。做法是站着开、按 Board 从左到右过、只讲三问、不在会上解决技术问题。遇到的困难记下来Scrum Master 会后单独跟进这是他的核心职责原文写得很清楚解决开发团队的困难让项目快速进展下去。会上不要现场改 JIRA一改就会有人开始讨论字段怎么填十分钟变半小时。会前更新、会上只对齐这个习惯坚持两个 Sprint 就能固定下来。4.3 周会看燃尽月会看版本视图选错了会白开周会由 Scrum Master 主持Product Owner 最好在场看三样东西当前 Sprint 的燃尽图、未完成项清单、被 Flag 的阻塞项。周会要出的决策只有一个剩下这几天范围要不要调。调就明说记进范围线不调就接受别在会上反复讨论。月会由 Product Owner 主导看的是版本层面的东西版本报告能预测按当前速度什么时候能发累积流图能看出哪个列在堆积堆积的地方就是瓶颈控制图能看单个任务的周期时间分布尾部特别长的那些就是反复返工的类型。会议频率主要视图要出的决策站会每天Board 当前列今天谁做什么、谁被卡住周会每周Sprint 燃尽图、未完成清单范围是否调整月会每月版本报告、累积流图版本是否延期、瓶颈在哪评审每 Sprint已完成项与验收标准是否接受本 Sprint 产出原文说月会上 Product Owner 要指出产品开发是否在期待范围内这句话的重量在于如果月会只看完成率百分比PO 是判断不出来的必须看版本报告的时间预测和累积流图的趋势。4.4 燃尽图不动时的排查顺序最常被问的一个问题是「燃尽图怎么是一条平线」。按下面这个顺序查基本三轮内能定位别一上来就怀疑工具。顺序检查项判断依据1Sprint 是否已开始Sprint 状态是 Future 时不出图2issue 是否有估时Original Estimate 为空的不计入3Board 统计字段选的是故事点还是原始估时4Board filter 范围当前 issue 类型是否被 filter 排除5剩余估时是否有人更新全自动清零模式下曲线会失真第 2 项和第 5 项占了我遇到的绝大多数情况。前者是导入时漏了估时后者是团队没人改剩余时间。两个都不是配置问题是流程问题改配置解决不了。5. 避坑与排查五条从平线燃尽图到失控 Sprint 的血泪记录5.1 估时与燃尽图相关的问题现象Sprint 开始第三天燃尽图还是一条贴着零的直线团队明明每天都在提交代码。原因Story 只填了 Story Points没填 Original Estimate而 Board 的统计字段选的是 Original Estimate。两边口径不一致图上自然什么都没算进去。另一种情况是估时从 CSV 导入时单位传错8 小时变成 8 秒图上看起来工作量约等于零。解决先统一口径团队按小时管理就把统计字段设成 Original Estimate按点数管理就全部改用 Story Points不要混。然后跑一次 JQL 把所有估时为空且未完成的 issue 拉出来补齐导入脚本里加单位校验REST 传秒、界面填小时、CSV 写8h三处对齐之后再导。现象Sprint 进行到一半燃尽图突然往上翘Product Owner 在会上问是不是进度造假。原因中途往当前 Sprint 加了新 Story而且带了估时。范围线确实记录了这次变化但没有人提前说过图上看起来就是「活越干越多」。这种情况在权限给得太宽的团队里特别常见。解决加需求走变更流程要么换出等量任务保持总量不变要么明确记入范围线并在周会上说明原因。关键不是禁止变更是让变更可见。同时把「管理 Sprint」的权限从开发组收走只留 Scrum Master。5.2 Sprint 节奏与流程相关的问题现象连续几个 Sprint 的完成量忽高忽低规划时完全没法参考团队自己也不信这个数字。原因上一个 Sprint 结束时没有点 Complete Sprint未完成的 issue 一直挂在原 Sprint 里或者被直接拖进下一个 Sprint 但没有重新估剩余时间。两种做法都会让速度统计把「没做完的」和「做完了的」混在一起算。解决每个 Sprint 到期必须关闭未完成项选择移到 Backlog 或下一个 Sprint移之前重新估剩余工时。这条执行两轮之后速度数据才有参考价值。关闭 Sprint 时那句「未完成项去哪」的确认不要一路回车逐个看一眼。现象站会开 25 分钟一半时间在对 JIRA 字段另一半在讨论技术方案。原因会前没人更新 Board所有人到会上才开始回忆昨天干了什么Scrum Master 习惯在会上直接解决问题一讨论就收不住。时间一长站会变成汇报会大家开始抵触。解决会前 5 分钟各自更新状态和剩余估时会上只回答三问遇到需要讨论的问题记在便签上会后拉相关的人单聊用一个看得见的计时器超过 12 分钟就截断。前一周会很别扭第二周就顺了。5.3 权限与流程约束相关的问题现象一条 Story 从 To Do 直接跳到 Done中间没有评审记录问起来说「昨天就测过了」。原因Developers 组被给了过宽的权限workflow 里也没有任何 condition 拦住状态跳转。工具层面允许一步到位流程层面就一定会有人图省事。解决收权限同时给 workflow 加 condition比如「没有测试结论字段不能进 Done」「没有关联版本不能进评审」。规则写在工具里比写在制度文档里有效因为绕过工具需要额外操作绕过文档只需要忘性。现象Sprint 结束做评审PO 说这不是我要的团队说需求文档上就是这么写的双方各执一词。原因Story 的描述里只有一句功能名没有可执行的验收标准PO 在开发过程中也没有参与过中间确认只在最后出现。解决每条 Story 的 Description 至少写一条能判断真假的验收条件比如「输入错误验证码三次后锁定十分钟」。周会请 PO 到场看的是当前 Sprint 的完成项而不是文档。评审时对着验收标准逐条过不过就是不过进下一个 Sprint 修。6. JQL 与关闭核对把 Scrum 数据变成能复查的证据前面所有配置最终都要落到「能查出来」。JQL 是 JIRA 里最值得花半小时学的东西下面几条是我每个项目都会存的过滤器直接改项目 key 就能用。-- 当前 Sprint 未完成周会前必看 project AGILE-DEMO AND sprint in openSprints() AND status ! Done -- 估时为空且未完成燃尽图平线的头号嫌疑 project AGILE-DEMO AND originalEstimate is EMPTY AND status ! Done -- 估时超过 16 小时该拆没拆的 project AGILE-DEMO AND originalEstimate 16h AND status ! Done -- 被标记阻塞的站会后 Scrum Master 跟进 project AGILE-DEMO AND flagged is not EMPTY -- 跨 Sprint 遗留速度失真的来源 project AGILE-DEMO AND sprint in closedSprints() AND status ! Done参数说明project换成自己的项目 key带连字符要加引号16h里的h是 JQL 的时间单位也可以写2dflagged在部分实例里显示名不同以字段实际 ID 为准。这几条查询可以存成过滤器挂到仪表盘上周会直接投屏不用现场敲。真正让数据可信的不是查询是关闭 Sprint 前的核对动作。我现在固定走五步先跑「估时为空」确认没有漏估再跑「当前 Sprint 未完成」逐条决定去留然后检查每条未完成项是否重估了剩余时间接着确认版本关联没有漏最后才点 Complete Sprint。五步加起来不到十分钟但能避免后面花两小时解释为什么速度曲线像心电图。这个习惯是被坑出来的。早些年我图快Sprint 到点直接关闭未完成项一股脑拖进下一个 Sprint估时原样带过去结果连续三个 Sprint 的速度数据全是错的规划会上没人信那张表最后只能手工翻 issue 历史重新算。从那以后我每次关闭 Sprint 前都强制走一遍这五步宁可慢十分钟不再给自己留后悔药。希望帮到你。本文还有配套的精品资源点击获取