企业官网建设流程全解析

简介：华为敏捷软件开发培训PPT，聚焦华为内部敏捷推行背景、核心理念与落地要求，适合软件项目经理、开发测试、架构人员以及准备参加敏捷知识考试的相关岗位系统学习。内容涵盖敏捷宣言的四大价值观与12条原则、敏捷诞生的历史背景与传统瀑布模型差异、华为对管理者和研发人员的任职资格要求及考试范围，并给出82%项目生产率提升、78%质量提升等实践效果数据。包体内共1个pptx演示文稿，约5.39MB，幻灯片采用内部培训风格，章节间逻辑清晰，从“敏捷概述”到“正确了解敏捷”“实施策略”“常见误解”逐步展开。目前已有45人学习下载，适合推进团队敏捷转型、理解华为模式或补充敏捷方法论的读者参考。通过这份资料可系统梳理敏捷核心理念与常见误区，帮助避免“敏捷不需要文档、仅适用小项目”等误解，为实际工作落地提供直接支撑。

1. 华为敏捷软件开发：不只是一份 PPT，而是一套可落地的交付方法

很多人拿到“华为敏捷软件开发.pptx”这份材料，第一反应是找里面的Scrum流程图，然后把角色名称换成自己的。但真正值得抄的不是那张图，而是华为在大型团队里把“计划、执行、度量”三条线拧在一起的做法。它解决的是一个问题：软件团队人数多、模块多、硬件强依赖时，怎么让敏捷不在约会上空转。这篇博客不讲PPT原文，只讲一线工程团队照着这套思路能直接落地的框架、命令和参数。

2. 华为敏捷软件开发的框架与角色分工

2.1 从瀑布到敏捷：为什么华为要自建一套敏捷体系

华为做的是嵌入式软件，比如基站控制器、路由器固件，这类软件有几个共同点：模块边界复杂，硬件联调只能在特定设备上做，发布窗口受制于硬件版本。传统瀑布模型让需求在分析阶段就必须冻结，等到编码完成再集成，问题会在最后一个月集中爆发。华为在2006年前后开始试点敏捷，不是简单引入Scrum，而是把迭代从“两周一个周期”变成“带硬件依赖的增量交付”来设计。

所以你在PPT里经常看到的“价值交付”“需求分层”，背后要回答的是“哪些需求可以进这个迭代，哪些必须等硬件”。自建体系的真正原因，是标准敏捷框架没有回答“硬件固件和软件一起迭代”这个问题。华为的做法是：把需求拆成小颗粒，同时把硬件依赖项单独做成验证任务，放进迭代待办列表里面。

这里有一个常见的误解：敏捷就不做计划。实际上华为的迭代计划比传统计划更细，只是计划的单位不再是“任务清单”，而是“验证过的用户故事”。每个故事在迭代内要完成编码、单测、代码评审和可运行验证，否则不算完成。这也是后文所有工作的基础。

2.2 核心角色与职责定义

华为的敏捷团队角色和Scrum很像，但多出两个关键角色：系统架构师和版本经理。系统架构师负责在迭代开始前把接口协议和硬件依赖标注清楚，避免开发到一半发现模块对接不上。版本经理则管理多个发布分支，确保每个迭代是否要同步到维护版本或升级分支。这两个角色让团队在复杂产品里仍然保持敏捷。

下表列出了常用角色和各自的边界，这比死记“Scrum三大角色”更贴近实际场景：

这里的“常见错误”来自我看到的团队切换环节，如果你的团队只有两个人，不需要生硬设置五个角色，但产品负责人和迭代经理这两角一定要分开，否则优先级和流程质量会同时失控。

2.3 迭代节奏与工件：用Scrum框架看懂这张PPT

华为常见的迭代周期是2到4周，硬件相关的团队会偏向4周，因为一次硬件编译、烧板、回读日志的循环可能就要两三天。迭代内的工作件包括：产品待办列表、迭代待办列表、用户故事卡片、燃尽图和演示成果。PPT里通常会把它们画成一个环形，但实际驱动环形的不是仪式，而是“迭代目标”。

用户故事的写法建议采用下面这个模板，字段数量控制在五栏以内，避免把故事卡写成需求文档：

作为<角色> 我希望<功能> 以便<业务价值> 验收标准: 1. 场景A下输出符合预期 2. 场景B下能在设备上运行 依赖硬件: - 需要XX单板, 联调前确认内核版本

这里“验收标准”是迭代评审时打勾的依据，不是“尽量完成”的愿望；“依赖硬件”则告诉迭代经理是否需要在迭代前做硬件申请。如果一张故事卡依赖的硬件还没到，就不应该进入迭代承诺。这三行字段，就是这份PPT和真实团队之间最实际的桥。

迭代经理盯的不是每个人的工时，而是迭代目标是否还有障碍。每一天站会后更新剩余工时，每周对比预计与实际的速率。如果发现偏差超过20%，不是加班压低数字，而是回到待办列表里重新找范围。这就是“这是一份PPT”背后最常见的执行差异。

3. 让迭代计划可复现：用Python管理燃尽图和工作量估算

3.1 最小可行的迭代数据结构

我见过的团队，离开PPT之后最大的问题是数据散落在Excel、微信群和口头里。要想快速跑通，最少只要维护一张CSV表格。列包括：日期、计划总工时、当日剩余总工时、昨天完成点数、当天完成点数。不用一开始就上Jira或者云平台，只要这几列就能让燃尽图动起来。

date,planned_hours,remaining_hours,completed_points,today_completed_points 2025-06-02,240,240,0,0 2025-06-03,240,210,8,8 2025-06-04,240,180,6,14 2025-06-05,240,160,5,19

这里planned_hours是迭代开始前团队承诺的总工时，在迭代内不变化。remaining_hours是每天站会后把未完成任务的剩余估计加总得到的值。completed_points是累计完成的故事点，可以用来画第二条曲线。注意planned_hours不要每天重新估算，否则燃尽图会变成“埋头拉线图”。

3.2 用Python脚本生成迭代燃尽图

有了CSV之后，生成燃尽图只需要不到三十行代码。下面是常见做法：

import pandas as pd import matplotlib.pyplot as plt df = pd.read_csv("sprint.csv", parse_dates=["date"]) # 保证日期有序 df = df.sort_values("date") # 理想燃尽线：从计划总工时线性降到0 ideal_x = [df["date"].min(), df["date"].max()] ideal_y = [df["planned_hours"].iloc[0], 0] plt.plot(ideal_x, ideal_y, color="gray", linestyle="--", label="理想燃尽") plt.plot(df["date"], df["remaining_hours"], marker="o", label="剩余工时") # 把计划线下方的面积标出来，便于观察提前或滞后 plt.fill_between(df["date"], 0, df["remaining_hours"], alpha=0.1) plt.xlabel("日期") plt.ylabel("剩余工作量(人时)") plt.title("迭代燃尽图") plt.grid(True) plt.legend() plt.tight_layout() plt.savefig("burndown.png", dpi=160)

这段代码的逻辑是：取计划总工时作为起始点，将从迭代开始到结束这两点连成一根直线，再把你每天记录的剩余工时按顺序打点。fill_between用于标记计划线下方的面积，如果进度滞后，面积会扩大。参数里最关键的是remaining_hours，必须每天由同一个标准汇总出来，既不包含未来几天“预估会完成”的乐观值，也不扣除已经离开团队的请假人员工时。

如果你只有需求点数没有工时，可以把remaining_hours改成remaining_points，逻辑完全一致。不要同时混用两类单位，否则图形的斜率会失去直观意义。生成图片后，放到PPT里用于站会和评审，比口头说“进度正常”强很多。

3.3 工作量估算与迭代容量参数

在开始一个迭代前，先算容量再选需求，这是最容易出错的一步。容量公式我一般这样写：

容量(人时) = 人数 × 迭代工作天数 × 每天有效工作小时 × (1 - 会议占比)

假设团队6人，迭代10个工作日，每人每天有效工作5.5小时，会议和评审占15%，容量 = 6 × 10 × 5.5 × (1 - 0.15) = 280.5人时。注意不要直接用8小时，因为站会、评审、环境准备和上下文切换都会吃掉时间。

下面是一组供估算用的参考参数，来自常见嵌入式敏捷团队：

这些参数不是固定标准，而是你团队的第一版起点。一旦有了第一轮数据，就可以把“容量公式”和“燃尽图”合到一起，形成下一次迭代的输入。坚持两个迭代，就能看出流程瓶颈在开发、测试还是等待硬件验证。

4. 质量内建与度量体系：让改进看得见

4.1 质量内建的四道关卡

华为敏捷软件开发里很强调“质量内建”，意思是缺陷不应该只靠测试发现，而是每个环节都要有检查动作。四道关卡通常是：需求澄清、代码评审、自动化测试、集成验证。需求澄清要求在故事进入迭代前，验收标准已经能被写成用例。代码评审不关注“谁的代码”，只关注“接口契约是否满足”。自动化测试需要在提交代码后15分钟内跑完核心用例，否则反馈太慢就没人看结果。集成验证则把当前迭代的所有可运行部分部署到一台干净环境，跑一遍端到端。

这四道关卡听起来像流程，其实有一个统一目标：把缺陷成本留在离它产生最近的位置。如果在需求阶段漏掉一个分支，修起来可能是一行代码；如果等到系统测试阶段才发现，代价是恢复整个版本。

4.2 用累积流图识别瓶颈

质量内建做得再好，交付节奏仍可能被瓶颈卡住。累积流图是看板数据里最直观的工具。它把每个看板列的“未完成卡片数量”按日期堆叠，如果某列带宽持续增加，说明任务在该列积压。下面是绘制CFD的常见脚本：

import pandas as pd import matplotlib.pyplot as plt df = pd.read_csv("kanban_flow.csv", parse_dates=["date"], index_col="date") df = df.sort_index() # 要求数据是每天统计的各列in-flow，即进入该列后未流出的卡片数 for col in ["待开发", "开发中", "待测试", "已完成"]: if col in df.columns: plt.plot(df.index, df[col], marker=".", label=col) plt.xlabel("日期") plt.ylabel("卡片数") plt.title("累积流图") plt.legend() plt.grid(True) plt.tight_layout() plt.savefig("cfd.png", dpi=160)

这段代码里，kanban_flow.csv至少要有日期和各个看板列卡片数。列名的实际计数逻辑是：当一张卡片进入“开发中”，该列计数加一；当它进入“待测试”，从“开发中”移出去，同时“待测试”加一。因此曲线不是卡片总量，而是存量。如果“待测试”曲线在某段时间上升斜率明显高于“开发中”，说明测试资源是瓶颈。此时需要做的不是催测试加班，而是把一部分测试用例前移到开发阶段自动执行。

4.3 让PPT里的指标回归简单

很多PPT会展示十多个图表，但对一线团队真正要盯的指标不超过五个。速度、吞吐量、缺陷逃逸率、周期时间、流动效率。速度看团队历史承诺能力，吞吐量看单位时间交付卡片数，缺陷逃逸率看漏到线上的缺陷比例，周期时间看需求从开始到完成的天数，流动效率则是实际开发时间占总周期的比例。下表给出计算公式和预警信号，方便放到自己的汇报模板里：

我第一次用这个表是在一个网络设备软件团队，当时发现周期时间中位数从5天涨到11天，排查后发现问题不是开发慢了，而是“待测试列”积压了太多包。这个结论如果只看燃尽图很难发现，因为燃尽图只显示总体剩余工作量，不会区分在哪个阶段。

5. 华为风格会议的三板斧：站会、评审与回顾

5.1 站会别开成汇报会

站会不是每个人向迭代经理汇报，而是为了“调整今天计划”。在华为的团队里，站会通常站在看板前，每人只说三句话：昨天完成了哪张卡，今天要动哪张卡，有没有障碍。障碍不说“快好了”，而是明确到“等待测试环境申请完成”，然后迭代经理立刻去协调，而不是带到下一个会议。

5.2 评审会盯“完成”而不是“进度”

评审会上，演示的每一项都要对照DoD逐条打勾。这里有个可落地的验收方式：要求开发当场在干净环境跑一遍自动化用例，用例过了才算展示通过。如果只能给截图或一个没有数据准备的界面，那就要自动扣分。我建议在评审前把“可运行版本”预部署到演示环境，评审现场从外部访问，避免被“PPT演示”带偏。

5.3 回顾会引入定量改进

回顾会不能只靠觉得很，建议把上一个迭代的缺陷逃逸率、周期时间、吞吐量调出来，选一个指标作为下个迭代的改进目标。常见做法是建立一个共享表格，列出“改进项、负责人、验证方式、验证日期”。每次站会开头花30秒检查这些行动项，而不是等到下次回顾会才看。这个动作和敏捷流程无关，却决定了改进措施是否会消散。

项目里如果环境允许，可以把“行动项检查”写成一条定时提醒命令，放在版本发布流水线里，确保周五回顾会结束后，下周一早上自动在团队群播报未关闭行动项。这样会议终于不再是灵感碰撞，而是被流程推动着闭环。

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