企业官网建设流程全解析

我见过太多团队，项目里明明开着JIRA的Scrum模板，Sprint规划、Daily Standup、Review、Retro一个不落，可问到“Scrum到底是什么”，得到的回答多半是“就是两周一轮，开四个会嘛”。可真按这个理解去跑，结果往往是：会开了一堆，需求照样烂，迭代照样拖，Backlog挤得像早晨八点的地铁，生产环境该出问题还出问题。

我最早接触Scrum也是这么过来的。当时某团队让我当Scrum Master，我说行，翻了一晚上资料，第二天就开始组织开会，结果前三个Sprint全在给上一轮欠的债擦屁股。后来慢慢把框架的来龙去脉啃了一遍，又把JIRA里的配置从头捋了一轮，才明白问题根本不在于“会议有没有开”，而在于“Scrum这套东西到底是靠什么逻辑在维持运转”。这篇文章我就把这套东西从头掰开讲清楚，顺带说说我在JIRA里实际落地时踩过的坑。

1. 别急着背定义：Scrum为什么总被讲成玄学

说句实在话，Scrum被讲玄学这件事，一半要怪工具，一半要怪传播方式。

现在随便打开一家公司的项目管理模板，默认清单里大概率有Scrum和Kanban两套。很多团队看到JIRA里自动生成了“Backlog”“Sprint”“看板”这些词，就以为自己已经在用Scrum了。但Scrum是个框架，不是一个皮肤。你换了一套看板的皮肤，并不代表框架跑起来了。

1.1 框架、流程、方法论，三者根本不是一回事

网上最常见的一句话是“Scrum是一种敏捷开发流程”。这话不能说错，但特别容易误导人。流程暗示的是“按固定工序走完就能出活”，可Scrum偏偏不是这么回事。

Scrum官方定义叫“轻量级框架”，它只给了你角色、事件、工件和规则这几样东西，至于每天站会说什么、用户故事怎么拆、Sprint到底定一周还是两周，它统统不做硬性规定。它跟那些把每个角色每一步行动都写死的重型流程是两种完全不同的思路。

我常跟团队打一个比方：Scrum更像家里的“例行大扫除”制度，规定每周六早上要打扫、每周日晚要做一次物品归位复盘，但具体是先擦窗还是先拖地，没有人管，只要你在规定时间内把该暴露的卫生死角暴露出来就行。而传统流程更像飞机检修手册，每个螺丝要拧几下，每根线要测几次，全部钉死。

1.2 三个支柱才是Scrum的地基

既然框架故意“不给细节”，那它靠什么保证项目能往前走？答案是三个支柱：透明、检验、适应。翻译成大白话就是：

• 透明：所有人能看见工作真实状态，包括做完了多少、还剩多少、堵在谁那儿。
• 检验：每隔固定时间就停下来看看，东西做得对不对、方向偏没偏。
• 适应：发现偏了之后，下一轮立刻调整，而不是硬着头皮继续。

这三个词看着简单，实际执行起来非常反人性。因为“透明”意味着你不能藏活，不好摸鱼了；“适应”意味着你上周拍板的方案这周可能被推翻。很多团队Scrum跑不起来，不是不会开会，是不愿意做到“真实透明”。

JIRA在这三个支柱里能干的活其实非常明确：它把“透明”落地成了看得见的看板和燃尽图；把“检验”落地成了Sprint Review和Retro的工具入口；把“适应”落地成了Backlog重排和Sprint调整的空间。工具本身不是Scrum，但它确实是最顺手的一块黑板。

2. 拆开组件箱：角色、工件、事件各自的真实分工

说完了地基，该看房子结构了。Scrum官方核心组件就三样：三个角色、三个工件、五个事件。很多团队背得很熟，但实际落地的错位基本都出在这三样东西的理解上。

2.1 三个角色：不是给岗位起名字，而是让责任归位

三个角色分别是产品负责人、Scrum Master和开发团队。

产品负责人是唯一有权决定“做什么、先做哪个、不做哪个”的人。注意是“唯一”。现实里最滑稽的场面就是，产品负责人手里并没有真正的权力，需求优先级被客户、老板、运营、客服轮流插队。团队问到底听谁的？产品负责人说“我也没办法”。这时候Scrum的规则就破了，因为责任没有归位。

我对这个角色的理解很朴素：产品负责人就是“对结果负责的人”。他可以听取所有人意见，但最终Backlog的顺序必须是他拍板。如果团队里没有这么一个人，Scrum就是瘸腿跑。

Scrum Master是另一种容易被误解的角色。很多公司把这个角色直接等同于“项目助理”或者“开会主持人”，只负责订会议室、催进度、更新JIRA状态。但这种干法把最关键的部分丢了：Scrum Master真正的职责是确保Scrum被正确执行，是帮大家扫除障碍的人。

我做Scrum Master那阵子，最常干的事不是盯进度，而是帮开发把“来自其他部门的依赖”清掉。比如测试环境配不出来、设计图迟迟不给、权限申请两周都没审批，这类事情才是真正的阻塞。催完这些，Sprint自然跑得顺。

开发团队则是一个跨职能的自组织小组。理想的形态是：团队里有人写代码、有人能测、有人能设计、有人能跟产品掰扯需求，一个Sprint需求来了，不用等外部配合，团队内部就能端到端交付。现实中大多数团队做不到完全跨职能，但至少要往这个方向靠，否则团队天天被外部依赖卡脖子。

2.2 三个工件：把工作从人脑子里搬到看得见的地方

三大工件是指产品待办列表、冲刺待办列表和产品增量。翻译成JIRA语言，其实就是Backlog、Sprint和每次交付出来的可用功能。

产品待办列表是所有需求的一池子源头。它可以有Bug、有优化、有技术债、有新功能。每一条叫“产品待办项”，通常以用户故事的形式存在。这个列表永远存在，也会永远排序。优先级高的放在上面，低的沉在底部。产品负责人要做的事情就是持续维护这个列表：删掉过时的，补上新长出来的，把模糊的拆清楚。

Sprint Backlog则是本轮冲刺要完成的一组待办项，是从产品待办列表顶部抓出来的。它一旦锁定，理论上不应该被中途插队。很多团队问我“老板临时说加需求怎么办”，我的回答永远是：可以加，但对应要从当前Sprint里拿掉工作量等量的东西。不加白不加，加了就爆炸。Sprint Backlog在JIRA里就是进入当前Sprint的计划需求清单。

产品增量则是“可用的”“符合完成定义”的成果。很多人忽略了“可用”二字，总觉得写完了就是完成，其实没测试过、没部署、用户根本点不到的功能根本不算增量。这也是JIRA里“Done”列为什么必须配一个明确完成定义的原因。

2.3 五个事件：节奏感不是开会，是检验循环

五个事件分别是Sprint冲刺本身、Sprint计划会、每日站会、Sprint评审会、Sprint回顾会。这事也常被简化成“四个会议”，但Sprint本身才是最大的节奏单元。

Sprint计划会是决定“这一轮干什么、打算怎么干”的会议。计划会通常分两段：一段是跟产品负责人定范围，一段是开发团队自己拆任务、估工作量。在JIRA里，这个过程对应的就是“从Backlog拖动需求到当前Sprint并拆成子任务”。

每日站会是每天固定在同一个时间和地点，15分钟以内，只回答三个问题：昨天做了什么、今天打算做什么、有没有遇到阻塞。这个会被无数团队跑成汇报会，从一个15分钟的同步工具变成每天半小时的地主斗长工。正确的姿势是站着开、不讨论细节、不解决问题，有问题拉上相关的人会后再单独聊。

Sprint评审会是迭代结束时给干系人看成果的会，重点是“看东西”，不是“讲PPT”。在这个会上，团队要把真正能跑的功能演示给大家看，干系人现场反馈，产品负责人当场调整Backlog。要是什么都拿不出来，这个Sprint就不算结束。

Sprint回顾会则是团队内部开的改进会，问三个问题：这轮做得好的是什么、做得差的是什么、下轮怎么改。这个问题听着简单，实际极容易变成甩锅大会或者沉默大会。我后来发现，回顾会更适合用“Stop Start Continue”这种框架，让每个人匿名写纸条再归类，既能避免沉默，也能避免互相指责。

3. 规则都照做了，项目为什么还是不行：价值观是最大的暗坑

经常听到这样的抱怨：“我们角色也分了，工件也有了，会也开了，怎么项目还是延期、需求还是跑偏、团队还是天天吵架？”这种时候往往不是框架的问题，而是价值观出了问题。

3.1 五句话看起来像口号，其实是运行前提

Scrum官方明明白白写了五个价值观：承诺、专注、开放、尊重、勇气。这五个词单独拎出来每个都像墙上的标语，但你在做具体决策时是否真的遵守它们，直接决定框架会不会变形。

承诺对应的场景是Sprint计划会上所有开发成员一起确认“这一轮我们能做到什么程度”。专注对应Sprint内不被外部请求打断。开放对应员工愿意把真实进度亮出来。尊重对应产品负责人听取开发意见，开发也认同产品负责人的决策权。勇气则是对着老板说“这个Sprint真的排不下了，硬塞会导致质量崩盘”。

我见过一个团队，JIRA里的任务状态全是“In Progress”，看板密密麻麻全是进行中，燃尽图一条直线横在顶部。后来我逐个跟人聊，发现真相是：任务本来都做完了，但大家怕做完后被打上新任务，所以故意不改状态。这事的根子就是信任缺失，团队不“开放”，也不“承诺”。工具救了不价值观，但它能帮你发现价值观崩了——燃尽图不会说谎。

3.2 常见走形现场：开过的Sprint和没开过的Sprint

我整理几个最容易走形的情况，每个都附上我的观察和应对思路。

第一类是估算变成政治斗争。有人故事点估8，有人估1，最后吵到翻脸。我的经验是，估算别追求精确，它只是为了排Sprint顺序和预判交付时间。团队头三个Sprint估算不准是正常的，跑三四个Sprint之后用速度图校准，比开会校正估点更有效。

第二类是站会变成轮流汇报。这种会一开气氛就很微妙，每个人对着Scrum Master述职，Scrum Master再对着项目经理总结。我做调整的办法很简单：把固定的“轮流发言”改成“围绕看板从右到左讲解”。谁的任务接近完成谁先说，卡住的多聊，顺畅的少说，效率能高不少。

第三类是Review变成挑毛病大会。干系人打开一个半成品，哪哪都不满意，搞得开发很受挫。后来我把演示脚本提前一天发给干系人，同时明确“这次就看功能走通，视觉细节下次再聊”，现场气氛才正常下来。评审会的目标是收集反馈，不是给成果打分。

3.3 完成定义没写好，一切等于白做

很多团队的Done就是“代码写完了上传仓库了”，但测试呢、文档呢、部署呢、线上验证呢？如果完成定义不写清楚，每个Sprint看起来都完成了，实际一堆没验证的功能在信用卡账上越滚越多。

在我现在的团队里，我们写完的完成定义包含：代码评审通过、单元测试覆盖关键路径、冒烟测试通过、部署到了预发环境、关键监控指标有登记。每一条都在JIRA的“完成定义”字段里列着，没有满足全部的卡不允许拖进“Done”。这么规定之后，燃尽图的“完成”才终于有了可信度，Sprint数据才有参考价值。

4. 在JIRA里把Scrum跑起来：从建项目到开完第一个Sprint

理论说太多容易飘，我实际的做法是按“先管好待办列表，再跑第一个Sprint，最后看报表”这个顺序来。JIRA Cloud和Server版本菜单位置有差异，但核心逻辑一致，我以比较常见的版本为例。

4.1 选模板：公司项目和个人项目差别很大

新建项目时，如果团队是几个人要协同，我建议选“公司管理的项目”，这样权限和流程比较规范。如果只是个人试用或小组轻量使用，“团队管理的项目”更轻便，改字段、改流程都不会影响其他项目，适合刚起步的小团队。

模板上直接选“Scrum开发”即可，不用自定义。它会自动生成Backlog界面、Sprint界面、活动过程Sprint界面和报表，省掉后头一堆配置功夫。我唯一会做的调整是把自带示例数据清掉，避免团队被那个“披萨店需求”混淆了。

4.2 Backlog的正确打开方式：Epic、Story、Task、Bug的四层结构

很多团队把需求一股脑扔在Backlog里，全是无类型的Issue。这样做的问题在于，排序和过滤全靠人脑，根本撑不起超过50个条目的列表。

我在JIRA里的习惯是用这样的结构：

创建JIRA项目后，第一步是建两三个Epic，然后让产品负责人在Epic下面把需求按Story拆分。每条Story的描述字段里，建议用最标准的模板“作为[角色]，我想要[功能]，以便[价值]”，再加一条“验收标准”。“验收标准”是JIRA里最容易被忽略的字段，但它恰恰是评审会能不能过得痛快的核心。

4.3 第一个Sprint怎么开：规模、估点、看板列

第一次开Sprint，计划会的主要内容是先选范围再拆任务。范围怎么定？让产品负责人把Backlog按优先级从上往下拉，团队评估“这一轮有信心完成多少”。第一次的估算一定不准，这很正常，关键是别贪多。

Sprint长度我建议新团队从两周起步。一周太短，计划会占掉的精力比例太高；一个月太长，反馈循环慢，做偏了要一个月才发现。等团队进入状态了，再按交付特征调成一周或三周都行。

选完范围后，开始拆分和估算。Story一般保留在Story级别，按“是否可在一到两天内完成”来拆。大故事要拆成更小的故事或技术任务。估点用“故事点”，但注意：不要拿到獭点以后开会讨论“到底谁感觉准确”，这没有意义。我建议用斐波那契数列1、2、3、5、8、13来做选项，团队各自独立给分，给完取大多数人的值。几个Sprint后，用实际完成点数和预测点数的偏差来校准。

JIRA看板的列一般默认就叫“待处理”“进行中”“完成”，我建议改成符合自己团队语义的列。最常见的设法是：待办、开发中、待评审、待测试、已完成。注意，看板的列只是工作状态的可视化，不代表任何“阶段门禁”。列多了会变成流程瀑布，列少了又看不出卡点，根据自己团队习惯微调一两轮就好。

4.4 报表别当摆设：燃尽图和速度图怎么看

不少团队开着JIRA，却没人看报表。其实报表才是JIRA帮你发现异常的最好工具。

燃尽图是看“剩余工作量”是否按预期下降的图。理想状态下是一条斜线从左上到右下，但现实中更多是阶梯状，甚至偶尔往上跳。往上跳说明有未完成的任务被Sprint中途改了，或者估算不够又加了新任务，这本身就是警报。如果图上在Sprint结束还有一大截剩余量，不要只说团队干劲不足，去翻Sprint期间是否频繁插入新需求。

速度图是看每个Sprint实际完成了多少故事点。这个数据是后续Sprint范围设置的黄金参考。很多新团队规划下一个Sprint时完全凭感觉拍脑袋放需求，结果每个Sprint都不稳定。正确逻辑是：过去三个Sprint的平均完成点数，就是下一个Sprint最可靠的参考值。要是突然想加量，就得有本事承担完不成的风险。

5. 这半年我带Scrum踩过的坑，和最后的一些经验

到这里，Scrum是什么、JIRA里怎么跑，基本都聊明白了。不过我这几年实际带团队时踩过的坑，还是值得单独拎出来说说，尤其是那些看起来“问题不大”，实际很影响体验的事情。

5.1 第一个坑：Sprint中途扛不住“紧急需求”

我带的某团队，连续三个Sprint都有生产事故和老板急活插进来，搞得开发完全按计划走的比例只有百分之三四十。一开始我也恼火，后来想通了：插需求本身不可怕，可怕的是每次插进来都不把等价工作量挪出去。我后来定了一条规矩：Sprint中途任何新增需求必须对应移走一个同量级的故事，除非产品负责人愿意整个Sprint延期。规矩立了一个月，插进来的需求少了很多，因为对方发现“要插必须自己负责砍需求”，就不再那么随便了。

类似的道理也适用于“BUG泛滥”的团队。如果Sprint里一半时间在修老Bug，大概率不是开发偷懒，而是完成定义没卡住质量。高质量地把故事做对，永远比疯狂塞工作量挣回口碑要快。

5.2 第二个坑：站会变成15分钟不够用

我们站会从最早的20分钟加人到35分钟，后来我把规则调整为“站会只要三件事：看板上一块卡有没有移动、找出谁被堵了、约下方会议”。凡是展开讨论的都放到会后单独拉人，站会上不做教学、不做复盘、不做技术评审。坚持两周后时间回到10分钟以内。

5.3 第三个坑：团队以为“用了JIRA”就是“用了Scrum”

这是最隐蔽的坑。有些团队把JIRA当成管理工具来用，任务是项目经理分配的，估点是形式上的，Sprint是模板生成的，一切都在JIRA上运转，但方向始终是自上而下派活，而不是团队自组织认领目标。

这种状态其实是用Scrum的壳，跑着瀑布的心。所谓的仪式、工件全都在，但真正驱动项目运行的决策逻辑没有变。我以前也用工具过程优雅来评价一个项目的敏捷度，现在不看了，就看一件事：产品负责人有没有真正在用Backlog排序来做产品决策，开发团队有没有真的在Sprint里对自己承诺的结果负责，Scrum Master有没有在不停地清障。这三点在，才是Scrum。

5.4 最后一点个人体会：从“小步快跑”到“适度标准化”

我觉得新团队没必要一上来就追求“教科书级Scrum”。一家公司能把Scrum的节奏感先跑出来，比把所有模板细节配到极致更有价值。记得刚开始做敏捷转型的某团队，光为了“JIRA里Epic怎么分层”就开会讨论了半天，现在回头看纯粹是浪费时间，不如先把需求切成能交付的价值块，把Sprint固定下来，再逐步调整。

我给新团队的建议永远是：先用纸和看板墙模拟一周，跑通节奏之后再把同样的流程搬进JIRA。工具只是载体，它不是敏捷的天花板。等你在JIRA里把第一个Sprint完整跑完，燃尽图稳定回归，评审会上真的能给大家演示新功能，回顾会上真的能提出一条下轮改掉的问题——那时候你会明白，Scrum并不是什么神秘框架，它只是用固定的节奏，逼迫团队面对问题、持续改善而已。