华为敏捷开发落地指南：从85页PPT到可执行操作卡

简介：这份85页PPT系统梳理了华为敏捷软件开发的核心知识体系，面向软件开发管理者、产品经理、开发与测试人员，以及希望理解敏捷理念与落地策略的技术从业者。内容从敏捷诞生的历史背景切入，覆盖敏捷宣言四大价值观、常见误解澄清、理念与优秀实践的分层解读，并延伸到迭代交付、持续集成、Scrum与XP等具体实践，帮助读者建立对敏捷的统一认知。资源包内含1个PPT文件，整体约8.62MB，以幻灯片形式呈现，结构清晰，便于按章节学习与内部培训引用。目前已有82人学习。PPT中结合华为内部推行要求，给出管理者与员工应知应会的知识框架，并引用业界调查数据说明敏捷对生产率、质量、满意度与成本的改进效果，适合用于团队敏捷入门培训、任职资格备考或研发流程优化参考。

1. 敏捷落地为什么总在“85页PPT”里打转

很多团队都经历过这样的场景：一份 85 页的敏捷开发宣讲材料在会议室里从头翻到尾，Scrum 角色、燃尽图、用户故事、迭代评审讲得头头是道，散会后大家回到工位，需求照样走三个月的大版本，测试照样在提测前一周才开始介入。问题不在于 PPT 讲错了，而在于它只讲了“敏捷是什么”，没讲“明天早上站会该说什么、需求怎么拆、看板怎么摆”。

这份以“85页PPT华为敏捷软件开发”为关键词流传的材料，本质上是一套把敏捷理念翻译成研发流程动作的框架。它真正能解决的是：需求从提出到交付的链路太长、跨职能协作靠邮件和会议、质量活动被压缩在末端这三类问题。适合谁看？适合正在从瀑布或半瀑布往迭代制迁移的研发团队负责人、项目经理、测试负责人，以及需要把“敏捷”从口号变成日常动作的一线工程师。下面我不复述 PPT 内容，而是按这套框架的落地逻辑，把选型、步骤、参数和坑讲清楚。

2. 从需求到迭代：把 85 页框架拆成可执行的四件事

2.1 需求分层：为什么用户故事不能直接进迭代

敏捷框架里最容易被误用的就是“用户故事”。很多人把需求文档里的功能点改写成“作为…我要…以便…”的句式，就认为完成了敏捷需求拆分。实际上，用户故事只是需求的一种表达形式，它必须挂在更大的结构上才有意义。常见做法是三层结构：主题（Theme）→ 特性（Feature）→ 用户故事（Story）。主题对应一个业务目标，特性对应可独立交付的功能模块，用户故事对应一个迭代内能完成的最小价值单元。

为什么不能直接进迭代？因为一个用户故事如果超过 3 天工作量，估算就会失真，验收标准也会模糊。我一般会用一个硬性判断：如果一个故事无法在迭代中期演示出可运行的结果，它就还不够小。这里的关键参数是“迭代长度”和“故事粒度”的匹配关系。两周迭代下，单个故事的工作量建议控制在 1 到 3 人天；一周迭代下，控制在 0.5 到 1.5 人天。超过这个范围，就要继续拆。

拆分的依据不是代码模块，而是验收路径。比如“用户能重置密码”可以拆成“请求重置链接”“校验链接有效性”“设置新密码并生效”三个故事，每个都有独立的验收条件。这样拆的好处是，测试可以在第一个故事完成时就介入，而不是等整个功能做完。

2.2 迭代计划会：输入、输出和时间盒怎么定

迭代计划会是敏捷节奏的起点，但很多团队开成了“任务分配会”。正确的输入应该包括：排好序的产品待办列表、上一个迭代的速率、团队成员的可用工时。输出应该包括：迭代待办列表、迭代目标、每个故事的验收标准。

时间盒建议：两周迭代的计划会控制在 2 小时以内，一周迭代控制在 1 小时以内。超时的原因通常是需求澄清不充分，而不是讨论太激烈。我一般会要求产品负责人在计划会之前完成待办列表的梳理，每个待办项必须有明确的验收标准，否则不进入计划会。

一个可复用的计划会流程：

# 迭代计划会检查清单（以两周迭代为例） # 会前：产品负责人完成待办列表排序，每个条目附带验收标准 # 会中： # 1. 产品负责人讲解迭代目标（10分钟） # 2. 团队逐条确认待办项，澄清疑问（40分钟） # 3. 团队认领任务并拆解为可执行子任务（40分钟） # 4. 确认迭代待办列表和迭代目标（20分钟） # 5. 识别依赖和风险（10分钟） # 会后：迭代待办列表录入看板工具，任务拆解到天

这段清单的关键在于“会前”那一步。如果产品负责人没有提前准备好验收标准，计划会就会变成需求评审会，时间盒必然失控。参数上，我建议每个待办项的验收标准不超过 5 条，每条都能用“是/否”判断，避免“性能良好”这类模糊表述。

2.3 每日站会：三个问题之外的看板规则

每日站会的标准三问是“昨天做了什么、今天打算做什么、有什么阻碍”。但只问这三个问题，站会很容易变成流水账。真正让站会有效的是看板规则。看板上的列通常包括：待办、进行中、待验证、已完成。每一列设置 WIP（在制品）上限，比如“进行中”最多 3 个任务，“待验证”最多 5 个任务。超过上限就不再拉新任务，而是集中力量清空当前列。

为什么 WIP 上限重要？因为多任务并行是迭代交付的最大杀手。一个人同时做三个任务，每个任务的上下文切换成本大约占 20% 到 30% 的有效工时。设置上限后，站会的焦点从“你做了什么”变成“哪个任务卡住了、谁能帮忙清掉”。

站会时间控制在 15 分钟以内，站立进行。如果某个问题需要深入讨论，记下来，站会后拉相关人单独沟通。我一般会指定一个轮值主持人，负责控制节奏和记录阻碍项。阻碍项必须在站会后 24 小时内有人跟进，否则站会就失去了意义。

2.4 迭代评审与回顾：演示什么、复盘什么

迭代评审会的目的是展示可运行的产品增量，而不是汇报进度。演示的内容必须是迭代待办列表里已完成的故事，每个故事由开发或测试人员现场操作，产品负责人和利益相关者验收。没有演示的故事，不算完成。

评审会的时间盒：两周迭代控制在 1 小时以内，一周迭代控制在 30 分钟以内。演示环境必须是独立的、可复现的，不能依赖开发本地环境。常见做法是每次迭代构建一个演示包，部署到测试环境，评审会直接访问。

迭代回顾会紧跟在评审会之后，聚焦三个问题：哪些做得好、哪些需要改进、下个迭代准备尝试什么改进。回顾会的输出不是“改进清单”，而是“下个迭代要验证的一个改进项”。一次只改一个，改完再评估。我见过太多团队在回顾会上列了十条改进，结果下个迭代一条都没落地。

3. 看板与度量：怎么让进度可见而不是靠感觉

3.1 看板列的设计：从“待办/进行中/完成”到可度量的流转

很多团队的看板只有三列：待办、进行中、完成。这种看板只能看数量，看不出瓶颈。可度量的看板至少要有五列：待办、分析中、开发中、待验证、已完成。每一列对应一个明确的准入准出条件。

准入准出条件举例：

这张表的价值在于，它把“完成”的定义从“代码写完”变成了“验收通过”。很多团队的迭代交付率低，就是因为把“开发完成”当成了“完成”，测试和验收的时间被压缩到迭代末尾。

3.2 累积流图：比燃尽图更早发现瓶颈

燃尽图看的是剩余工作量，累积流图看的是各阶段的在制品数量。累积流图的横轴是时间，纵轴是任务数量，每条色带代表一个阶段。如果某条色带越来越宽，说明该阶段积压了任务，瓶颈就在这里。

常见瓶颈位置和应对：

• “待验证”色带变宽：测试资源不足或提测质量差。应对是开发阶段加强自测，或者测试左移，在开发阶段就介入用例设计。
• “开发中”色带变宽：任务拆分不够细，或者技术方案不明确。应对是计划会时把任务拆到 1 人天以内，技术方案在分析阶段确认。
• “已完成”色带变宽：验收不及时。应对是产品负责人每天固定时间验收，而不是等迭代结束。

累积流图不需要额外工具，用 Excel 或在线表格就能画。每天站会后更新一次各列任务数，坚持一个迭代就能看出趋势。

3.3 速率与交付周期：两个必须分开看的指标

速率（Velocity）是每个迭代完成的故事点总和，用来做迭代容量规划。交付周期（Lead Time）是从任务进入待办到验收通过的时间，用来衡量响应速度。这两个指标必须分开看。

速率稳定不代表交付周期短。如果待办列表里积压了大量低优先级任务，速率可能很高，但新需求从提出到交付的周期很长。我一般会同时跟踪两个指标：速率用于计划，交付周期用于改进。交付周期的改进方向是减少等待时间，而不是加快单个任务的处理速度。

一个可操作的度量方法：

# 交付周期计算示例（单位：天） # 数据来源：看板工具导出的任务流转记录 tasks = [ {"id": "T1", "start": "2025-01-01", "end": "2025-01-05"}, {"id": "T2", "start": "2025-01-03", "end": "2025-01-12"}, {"id": "T3", "start": "2025-01-06", "end": "2025-01-08"}, ] def lead_time(task): from datetime import datetime start = datetime.strptime(task["start"], "%Y-%m-%d") end = datetime.strptime(task["end"], "%Y-%m-%d") return (end - start).days times = [lead_time(t) for t in tasks] print(f"平均交付周期: {sum(times)/len(times):.1f} 天") print(f"最长交付周期: {max(times)} 天")

这段代码的逻辑很简单：计算每个任务从开始到结束的天数，然后取平均值和最大值。参数上，start应该是任务进入“待办”列的日期，end是任务进入“已完成”列的日期。如果只看平均值，可能会忽略长尾任务；最长交付周期往往暴露了流程中的特殊卡点。

4. 避坑：敏捷迁移中最容易翻车的五个地方

4.1 站会变成汇报会，15 分钟拖到 40 分钟

现象：站会一开始，每个人轮流对着项目经理汇报昨天做了什么，项目经理逐条追问细节，其他人低头看手机。原因：站会的主持人角色错位，项目经理把自己当成了进度跟踪者，而不是流程维护者。解决：站会主持人由团队成员轮值，只控制时间和记录阻碍，不追问细节。每个人回答三个问题时，只讲和看板任务相关的内容，不展开技术讨论。超过 15 分钟直接结束，未讨论完的阻碍项站会后单独拉群。

4.2 迭代中途插入需求，迭代目标形同虚设

现象：迭代进行到一半，产品负责人或上级领导插入紧急需求，团队被迫调整计划，原定目标无法完成。原因：没有明确的迭代保护规则，或者产品负责人没有对需求优先级做取舍。解决：迭代开始后，迭代待办列表冻结。新需求进入产品待办列表，由产品负责人评估优先级，决定是否替换当前迭代中的某个任务。替换必须经过团队同意，并且被替换的任务回到待办列表。如果频繁插入，说明迭代长度太长，考虑缩短到一周。

4.3 验收标准模糊，测试和开发互相扯皮

现象：开发认为功能已完成，测试认为不满足要求，双方对“完成”的理解不一致。原因：用户故事的验收标准写得太笼统，比如“系统响应快”“界面友好”。解决：验收标准必须可量化、可验证。每条标准用“给定…当…则…”的格式写。比如“给定已登录用户，当点击重置密码，则系统在 2 秒内发送重置链接到注册邮箱”。验收标准在计划会时由产品负责人和团队共同确认，写入任务卡片。

4.4 回顾会开成吐槽会，改进项从不落地

现象：回顾会上大家轮流抱怨，列了一堆问题，下个迭代照旧。原因：改进项太多，没有优先级，也没有人负责跟进。解决：每次回顾会只选一个改进项，指定一个负责人，在下个迭代中验证。改进项要具体到动作，比如“站会主持人轮值表贴在看板上”，而不是“加强沟通”。下个迭代回顾会的第一件事就是检查上个改进项是否落地。

4.5 工具先行，流程没变

现象：团队上了看板工具、敏捷管理平台，但需求还是走邮件，迭代还是按季度排。原因：把工具当成了敏捷本身，以为买了工具就是敏捷了。解决：先用白板和便利贴跑通一个迭代，确认流程可行后再选工具。工具是流程的固化，不是流程的替代。选工具时只看三个功能：看板列自定义、WIP 上限设置、累积流图导出。其他功能都是锦上添花。

5. 从 85 页到一页：把框架压缩成团队自己的操作卡

那份 85 页的材料，信息量很大，但团队真正需要的是能贴在工位旁边的一页操作卡。我一般会带团队做一次“压缩练习”：把框架里的所有活动列出来，然后问三个问题——这个活动如果不做，会出什么问题？如果出问题，影响多大？如果影响不大，能不能合并到其他活动里？

压缩后的操作卡通常包含五块内容：迭代节奏（多长、什么时候开什么会）、需求流转规则（从待办到完成的列和准入准出）、站会规则（时间、主持人、阻碍项跟进）、验收规则（谁验收、怎么验收、验收不通过怎么办）、改进规则（回顾会怎么开、改进项怎么跟踪）。每块内容不超过 5 行，用团队自己的话写，不用敏捷术语。

一个可复用的操作卡模板：

这张卡的价值在于，它把 85 页的框架变成了团队每天能执行的动作。新成员入职时，看这张卡就能知道怎么参与迭代，不需要从头读 PPT。

验证这套框架是否落地，我一般看三个信号：站会是否准时结束、迭代目标是否在评审会上演示、回顾会的改进项是否在下个迭代被验证。三个信号都满足，说明框架已经跑起来了。如果只有一个满足，说明还在过渡期，需要继续调整。

最后说一个我自己的教训：早期带团队做敏捷迁移时，我总想把 85 页里的所有实践都落地，结果团队疲于应付各种会议和文档，反而影响了交付。后来我改成一次只加一个实践，跑顺了再加下一个，迁移周期拉长到半年，但落地效果扎实得多。敏捷不是一次性的改造，而是持续的习惯调整。希望帮到你。

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