企业官网建设流程全解析

简介：面向敏捷开发初学者与项目管理者的一份JIRA实践文档，聚焦如何借助JIRA落地Scrum方法，解决需求梳理、任务量化与进度可视化等项目管理问题。压缩包内仅含1个docx文件，约6.55MB，以图文形式系统整理了Scrum团队角色分工、头脑风暴到评估的五步流程，以及工作拆分、用户建立、Scrum Boards搭建等准备工作，并配有项目计划表与时间燃尽表示例。内容覆盖站会三问、Sprint拆分、Bugs修复冲刺等实操细节，也点出新团队磨合与团队协作要求等注意事项，便于读者对照搭建自己的JIRA敏捷项目、理解燃尽表跟踪进度的思路。目前已有3440人学习，适合需要快速上手JIRA Scrum管理的中初级读者参考。

1. 从一张贴满白板的任务卡说起：这套方案要解决什么

接手一个十人左右的开发团队，最头疼的往往不是技术难题，而是「谁在做什么、还剩多少活、明天能不能交」。传统瀑布式开发要求需求、设计、开发、测试全部就绪才动工，一旦中途需求变更，整条链路跟着返工。这套基于 JIRA 的 Scrum 敏捷开发项目管理方案，就是冲着这个痛点来的：用增量迭代替代一次性交付，用可视化看板替代口头同步，用时间燃尽表替代拍脑袋估工期。它适合两类人——正在做敏捷开发课程设计或毕设的学生，需要一套能跑通、能答辩的完整流程；以及刚接手小团队、想把项目管理从 Excel 搬到工具上的从业者。整套方案围绕 Scrum 的三个角色、五个步骤和 JIRA 的 Boards 配置展开，读完你能直接照着搭出自己的项目空间。

2. 角色与流程设计：三个角色、五个步骤怎么落到 JIRA 里

Scrum 的团队规模通常控制在 10 人左右，人一多，站会就变成汇报会，沟通成本反而上升。这套方案先把角色边界划清楚，再谈工具配置，否则 JIRA 里建再多看板也只是摆设。

2.1 三个角色的职责边界与权限映射

Product owner 是需求方，负责提出需求并对功能流程、业务流程拍板。在 JIRA 里，这个角色通常对应项目管理员权限，能创建和调整版本、编辑需求描述、决定优先级排序。Scrum master 是团队负责人，负责解决团队各类问题、领导项目推进，在 JIRA 里需要看板配置权限和 Sprint 管理权限，能开合 Sprint、调整任务归属。Scrum team 是具体开发和测试人员，权限收窄到任务领取、状态流转和工时登记。

这里有个血泪经验：很多团队一开始把所有人都设成管理员，结果看板被改得面目全非，燃尽图数据全乱。我一般会按「最小权限」原则配置，Product owner 管需求池，Scrum master 管 Sprint 节奏，开发测试只管自己名下的任务卡。权限一乱，后面所有数据都不可信。

2.2 五个步骤的输入输出与 JIRA 对应关系

原文把 Scrum 开发拆成五步，每一步都有明确的输入输出，这套方案的关键是把它们映射到 JIRA 的具体功能上。

步骤一是头脑风暴。Product owner 对需求清楚时可以跳过，否则召集技术团队和用户群体公开征求意见，输出产品建议表。JIRA 里对应的是「需求收集」阶段，可以用一个独立的 Issue Type 承载建议条目，状态设为「待筛选」。

步骤二是需求筛选与 PRD 输出。Product owner 对建议表做减法，提炼核心需求，由 Scrum master 输出 PRD，业务逻辑和功能流程必须和 Product owner 确认清楚。JIRA 里这一步落到「需求」类型的 Issue 上，描述字段写业务逻辑，附件挂 PRD 文档。

步骤三是工作量估算。把任务量化到原型、UI 设计、前端开发等最小单元，单个任务的工作小时不超过 16 小时，然后估算总体项目时间。JIRA 里用「故事点」或「原始时间估算」字段记录，任务卡贴到白板的三栏——to do、in progress、done，这正是 JIRA Boards 的雏形。

步骤四是 Sprint 执行。按重要度把任务组合成 n 个 Sprint，先做主要功能，再做次要功能，最后修复 bugs。每个 Sprint 独立执行，每天开 10 分钟左右的站会，每人回答三个问题：今天做了什么、明天打算做什么、遇到什么困难。JIRA 的 Sprint 功能和燃尽图直接承接这一步。

步骤五是评估。Product owner 和团队对产品评估，不满意的地方建立 bugs sprint 继续修，直到达到 Product owner 的预期。

提示：五个步骤不是串行一次就结束，Sprint 阶段是循环的，评估后的修改会回流到需求池，形成闭环。

2.3 站会、周会、月会的节奏设计

站会每天一次，站着开，控制在 10 分钟左右，三个问题必须问到位。Scrum master 要在站会后立刻解决开发团队提出的困难，否则第二天站会还是同样的问题。周会每周一次，Product owner 最好在场，同步本周进度和下周计划。月会每月一次，Product owner 指出产品开发是否在期待范围内。

这套节奏在 JIRA 里的落地方式是：站会看板上的任务流转，周会看 Sprint 燃尽图的趋势，月会看版本发布报告。会议本身不产生数据，数据来自日常任务卡的更新，所以任务卡的状态变更必须当天完成，不能攒到周末补录。

3. 总体架构与 JIRA 配置：从项目计划表到 Scrum Boards

工具配置是这套方案最容易翻车的地方。很多人一进 JIRA 就急着建项目，结果字段没规划好，后面改起来牵一发动全身。正确的顺序是先有项目计划表，再建用户，最后建 Boards。

3.1 项目计划表的结构与字段设计

工作量估算阶段会得到一张项目计划表，这张表是 JIRA 配置的依据。表里至少要有任务名称、所属模块、预估工时、优先级、负责人、所属 Sprint 六个字段。预估工时按原文要求不超过 16 小时，超过的必须继续拆分，拆到能在一个两天内完成为止。

下面是一个计划表的结构示例，用 Python 字典表示，方便后续批量导入 JIRA：

# 项目计划表结构示例，字段与 JIRA Issue 字段一一对应 project_plan = [ { "summary": "用户登录模块原型设计", # 任务名称，对应 JIRA Summary "module": "账号体系", # 所属模块，对应 Component "estimate_hours": 12, # 预估工时，上限 16 小时 "priority": "High", # 优先级，对应 Priority "assignee": "dev_a", # 负责人，对应 Assignee "sprint": "Sprint 1" # 所属 Sprint }, { "summary": "登录接口开发", # 开发类任务 "module": "账号体系", "estimate_hours": 16, # 刚好卡在上限，不能再大 "priority": "High", "assignee": "dev_b", "sprint": "Sprint 1" } ]

这段结构的关键在estimate_hours字段，它是燃尽图的数据来源。超过 16 小时的任务必须拆成两条，否则燃尽图的曲线会失真——一个大任务卡在那里不动，看起来像团队停滞，实际是在憋大招。module字段对应 JIRA 的 Component，方便按模块筛选；sprint字段决定任务进入哪个迭代。

3.2 用户建立与权限组划分

团队所有成员必须先在 JIRA 中建立用户并能正常登录，这是建项目的前置条件。用户建好后按角色分到三个组：po-group、sm-group、dev-group。Product owner 进po-group，Scrum master 进sm-group，开发和测试进dev-group。

权限组的作用在项目多了以后特别明显。新开一个项目，直接把组挂上去，不用一个个加人。我一般还会给sm-group单独开一个「管理 Sprint」的权限，其他人只能看不能动，避免 Sprint 被误开误关。

3.3 建立 Scrum Boards 与版本开发周期设置

准备工作就绪后，在 JIRA 里新建一个 Scrum 类型的项目，系统会自动生成一个 Board。Board 默认三列：To Do、In Progress、Done，正好对应原文白板的三部分。如果团队有测试环节，可以加一列「待测试」，但列不要超过五列，列一多，任务卡就在各列之间来回跳，站会看不过来。

版本开发周期在项目设置里配置，一个版本对应一个或多个 Sprint。Sprint 长度建议固定为两周，固定节奏比灵活节奏更容易估算。版本设置里填好开始日期和发布目标，JIRA 会自动按 Sprint 生成燃尽图。

# 通过 JIRA REST API 创建 Sprint 的示例（需替换实际地址和认证信息） curl -X POST \ -H "Content-Type: application/json" \ -u "sm_user:api_token" \ -d '{ "name": "Sprint 1", "startDate": "2024-03-04T09:00:00.000Z", "endDate": "2024-03-15T18:00:00.000Z", "originBoardId": 1 }' \ "https://your-jira-instance/rest/agile/1.0/sprint"

这段命令的含义是：以 Scrum master 身份，在 Board 1 下创建一个从 3 月 4 日到 3 月 15 日的 Sprint。originBoardId必须和实际 Board 的 ID 一致，填错会报 404。startDate和endDate决定燃尽图的横轴范围，日期格式必须是 ISO 8601，少个Z都可能解析失败。

注意：Sprint 一旦开启，结束日期可以延长但不要随意缩短，缩短会让燃尽图的剩余工作量曲线突然上翘，看起来像进度倒退。

4. 核心模块实现：任务流转、燃尽图与 Bug 管理

配置搭好后，日常运转靠的是任务卡的状态流转和燃尽图的数据更新。这一章把三个核心模块的实现细节拆开讲，每个模块都给出可操作的配置或代码。

4.1 任务卡状态流转与站会数据更新

任务卡在 Board 上的流转规则要提前定死：To Do 表示未开始，In Progress 表示正在做，Done 表示已完成。开发人员每天站会前把自己的任务卡挪到正确位置，站会时对着 Board 讲三个问题，讲完 Scrum master 当场记录困难项。

状态流转的实现依赖 JIRA 的工作流配置。默认工作流是「Open → In Progress → Resolved → Closed」，这套方案建议简化为「To Do → In Progress → Done」三态，减少无效状态。简化后的工作流在项目设置的工作流方案里修改，改完要重新关联到项目。

# 站会后批量更新任务状态的示例逻辑 def update_task_status(issue_key, target_status, jira_client): """ issue_key: JIRA 任务编号，如 PROJ-101 target_status: 目标状态，取值 To Do / In Progress / Done jira_client: 已认证的 JIRA 客户端实例 """ transitions = jira_client.transitions(issue_key) # 找到目标状态对应的 transition id target_id = None for t in transitions: if t['to']['name'] == target_status: target_id = t['id'] break if target_id is None: raise ValueError(f"状态 {target_status} 不可达，检查工作流配置") jira_client.transition_issue(issue_key, target_id)

这段逻辑的关键在transitions查询，JIRA 的状态不是随便跳的，必须走工作流定义的路径。如果从 To Do 直接跳 Done 报错，说明工作流里没配这条直达路径，需要回项目设置里补一条 transition。target_id找不到时抛异常而不是静默失败，是为了让站会当场发现问题，而不是等到燃尽图平了才回头查。

4.2 时间燃尽表的生成与异常记录

燃尽图是 Scrum 的精华，横轴是天数，纵轴是剩余工时。Day 1 记录总工时，之后每天按完成度更新剩余时间。原文特别强调：不管任务是否按时完成都必须记录，发现技术难点或成员请假导致工期增加，也要在燃尽表里体现。

JIRA 的燃尽图基于「原始时间估算」和「剩余时间估算」两个字段自动生成。任务开始时填原始估算，每天站会后更新剩余估算。剩余估算不降反升是正常的，说明发现了新问题，但连续三天上升就要在站会上说明原因。

-- 查询某 Sprint 内每日剩余工时汇总，用于核对燃尽图数据 SELECT DATE(worklog_date) AS log_date, -- 记录日期 SUM(remaining_hours) AS total_remaining -- 当日剩余工时合计 FROM sprint_worklog WHERE sprint_id = 'Sprint 1' GROUP BY DATE(worklog_date) ORDER BY log_date;

这条查询按天汇总剩余工时，和 JIRA 燃尽图对照，能快速定位哪一天的数据对不上。对不上通常是有人改了估算但没走站会同步，或者任务卡挪了状态但没更新剩余时间。sprint_id要换成实际的 Sprint 标识，不同 JIRA 版本的字段名可能略有差异，以实际库表为准。

4.3 Bug Sprint 的建立与测试节奏

每个 Sprint 都必须测试，尽量大家一起测。Bug 太多时单独开一个 Sprint 来修，这个 Sprint 只放 Bug 任务，不掺新功能。JIRA 里用 Issue Type 区分「Story」和「Bug」，Bug Sprint 里只拉 Bug 类型的任务。

测试节奏建议放在 Sprint 后半段，开发完成主要功能后集中测试。Bug 的优先级按影响范围定：阻塞主流程的标 Highest，界面问题标 Medium，文案问题标 Low。Bug Sprint 的燃尽图单独看，不和功能 Sprint 混在一起，否则功能进度被 Bug 修复拖累，看不出真实情况。

提示：Bug Sprint 不要超过一周，时间一长团队会陷入「修 Bug—引入新 Bug」的循环，该收口时就收口。

5. 避坑与排查：五个最容易翻车的点

这套流程跑起来之后，问题往往不出在设计上，而出在执行细节里。下面五条是项目里最常见的翻车点，每条按现象、原因、解决三段说清楚。

5.1 燃尽图突然变平或上翘

现象是燃尽图连续几天横着走甚至往上翘，团队看起来像没干活。原因通常是任务卡没更新剩余工时，或者有人把大任务拆小后没同步原始估算。解决方法是站会上强制核对每张 In Progress 卡的剩余时间，Scrum master 每天收盘前扫一遍 Board，发现没更新的当场提醒。我一般会要求开发在挪卡到 Done 之前必须先填剩余工时为 0，这个习惯能省掉大量对账时间。

5.2 Sprint 范围中途膨胀

现象是 Sprint 进行到一半，Product owner 往里塞新需求，团队加班也做不完。原因是需求池没有冻结机制，Sprint 边界形同虚设。解决办法是在 Sprint 启动会上明确本次范围，中途新增需求一律进下一个 Sprint 的候选池，除非 Product owner 主动移除等量的现有任务。JIRA 里可以用 Sprint 的「范围变更」报告看每次加了多少任务，数据摆出来，争论就少了。

5.3 站会开成汇报会

现象是站会超过 20 分钟，每个人对着 Scrum master 详细讲技术方案。原因是三个问题的回答没有约束，遇到难题就开始展开讨论。解决办法是站会只回答「做了什么、要做什么、卡在哪」，卡住的问题记下来，站会后拉相关人单独开小会。Scrum master 要控场，看到有人展开就打断，说「这个问题会后单独聊」。

5.4 任务粒度失控

现象是某张任务卡在 In Progress 待了一周不动，燃尽图被它拖平。原因是估算时没拆到 16 小时以内，或者拆了但开发又合并回去。解决办法是建卡时就卡死上限，超过 16 小时的卡不允许进 Sprint。JIRA 里可以配一个校验规则，原始估算超过 16 小时的任务在 Sprint 启动时标红提醒。

5.5 权限混乱导致看板被改坏

现象是某天早上发现 Board 的列被删了一列，或者工作流被改了，燃尽图数据全乱。原因是所有人都给了管理员权限。解决办法是按角色分组授权，只有 Scrum master 有看板配置权限，改动前在团队里说一声。JIRA 的审计日志能查到谁在什么时候改了什么，出问题先查日志再追责，比互相猜疑高效得多。

6. 验收与答辩：怎么证明这套流程真的跑通了

验收这套方案，不看文档写得多漂亮，看三个东西：燃尽图、Sprint 报告、Bug 收敛曲线。答辩时导师或评审最常问的是「你怎么证明敏捷比瀑布好」，答案不在理论里，在你自己的数据里。

先看燃尽图。一个健康的 Sprint，燃尽曲线应该从左上向右下稳定下降，中途允许有小幅上翘（发现新问题），但不允许长期横盘。答辩时把两个 Sprint 的燃尽图并排放，第一个 Sprint 如果有横盘，第二个 Sprint 修正了，这本身就是最好的过程改进证据。

再看 Sprint 报告。JIRA 自动生成的 Sprint 报告里有承诺任务数、完成数、未完成数三个数字。承诺 20 完成 18，说明估算偏乐观；承诺 20 完成 20 但 Bug 一堆，说明测试介入太晚。把这两个数字和实际发布时间对照，能讲清楚估算准确度和交付质量的关系。

最后看 Bug 收敛曲线。每个 Sprint 的 Bug 新建数和关闭数画成两条线，健康的项目里关闭数应该追着新建数走，两条线不出现持续扩大的剪刀差。如果剪刀差越来越大，说明测试资源不足或者需求变更太频繁，答辩时主动指出这个问题并给出下个迭代的调整方案，比藏着掖着强。

下面这张表可以作为答辩时的自检清单：

答辩陈述时有个技巧：不要从「什么是 Scrum」讲起，直接从你的第一个 Sprint 的燃尽图讲起，讲你遇到了什么问题、怎么调整的、第二个 Sprint 数据怎么变的。评审想听的是你的判断过程，不是教科书定义。我见过太多答辩栽在「背概念」上，反而那些坦承「第一个 Sprint 估算全崩了，第二个 Sprint 把任务拆细后完成率从 60% 提到 85%」的，分数都不低。

从那以后我每次带新项目，第一个 Sprint 都当成校准 Sprint，不追求完成率，只追求把估算偏差摸清楚，第二个 Sprint 再正式承诺。这个习惯让我少踩了很多「拍脑袋定工期」的坑。希望帮到你。

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