迭代最佳实践：项目负责人敏捷项目实操方法，常见问题

迭代延期，很多时候不是团队“做得不够快”，而是负责人把迭代计划当成了一张承诺表：需求先全收进来，估算再往乐观方向靠，最后靠加班补差额。我的判断恰好相反：迭代管理的首要目标不是让每个人更忙，而是让团队更早看见“承诺与能力之间的偏差”，并在偏差变成延期之前做出取舍。下面以一个匿名的企业软件团队为例，拆解项目负责人如何从计划、执行、验收到复盘，建立能落地、可调整、可验证的迭代实践。

文中案例数值是情景模拟，用于说明方法，不代表行业统计或任何具体企业的真实经营数据。

一、先讲核心结论：迭代不是装满工作，而是管理承诺

1. 迭代成功不等于计划项全部关闭

项目负责人容易把“完成率”当成迭代成绩：计划了二十项，完成十八项，完成率就是百分之九十。这个数字看起来不错，却可能掩盖关键问题：最重要的客户流程没有交付，所谓完成的事项还没有通过验收，或者团队为了赶进度把测试和文档推迟到了下一轮。

我更倾向于同时看三个结果：本轮目标是否达成，已完成工作是否达到可交付标准，未完成工作是否及时暴露并重新安排。单看任务数量，只能说明清单被处理了多少，不能说明用户是否获得了可用价值。

迭代的管理对象不是任务，而是团队在明确约束下做出的价值承诺。任务是实现承诺的手段；一旦任务变化，负责人要重新判断目标、风险和容量，而不是机械地保留原计划。

2. 负责人要管“流动”，不只是管“人”

迭代中最常见的阻塞，并非有人坐着不做事，而是工作卡在等待：等需求澄清、等设计确认、等测试环境、等外部接口、等决策人回复。此时，催促执行者通常不会让工作更快，负责人应该定位等待发生在哪个节点，以及谁能解除阻塞。

因此，我会把管理重点放在工作流上：需求是否准备好，任务是否过大，进行中的工作是否过多，测试是否排队，验收是否有明确标准。团队看板不是为了统计谁做了多少，而是为了让等待和返工变得可见。

3. 计划是预测，不是免责承诺

计划阶段的信息永远不完整。接口依赖可能变化，需求边界可能在开发后才暴露，团队成员也可能临时处理线上问题。负责人应当把计划表达为“基于当前信息的最佳判断”，同时明确哪些条件变化会触发重新规划。

在启动会上，可以把承诺分成两层：迭代目标是团队努力守住的结果；任务清单是实现目标的当前方案。若出现新证据，负责人可以调整方案，但不能悄悄改变目标口径，更不能让所有新增工作都自动进入本轮。

二、背景和真实场景：为什么团队看起来很忙，迭代却总是失控

1. 一个典型的企业软件团队情景

以下案例为匿名化情景模拟：一个约二十人的企业软件团队，每两周发布一次迭代版本。团队成员包括产品、研发、测试和设计，另有几个需要协调的外部系统团队。迭代开始时，负责人通常会收到来自客户成功、销售、运维和产品规划的多类需求。

团队在迭代启动时选入十六项工作，开发过程中又插入四项“看起来不大”的紧急请求。到迭代最后两天，三项功能还在等待接口确认，两项需求发现验收条件不清，测试集中排队。最终交付看似完成了多数开发任务，但真正通过端到端验收的功能只有一部分。

这个场景的症结不是简单的估算不准。更深一层的问题是：团队把未澄清需求当成了可执行工作，把外部等待当成了个人效率问题，把新增需求当成了零成本工作。负责人如果只在最后一天追问“为什么没做完”，就已经错过了最有价值的干预时点。

2. 迭代开始前，先检查输入质量

我会把迭代计划会前的工作看成“输入质量控制”。产品负责人需要提前准备候选事项，研发和测试则应在会议前标出明显的技术风险、依赖和验收疑问。会议现场不适合第一次阅读长篇需求，更不适合临时讨论一个事项到底要解决什么问题。

一个需求进入计划候选池前，至少要能回答四个问题：谁遇到问题，当前问题是什么，预期改变是什么，怎样判断改变已经发生。若其中两项答不出来，负责人应先安排澄清，而不是用一个粗略估算把它包装成确定工作。

需求准备不代表所有细节都必须提前设计完。敏捷并不要求一次性消除不确定性，而是要求团队知道不确定性在哪里，并选择适合的验证方式。探索性任务可以进入迭代，但应明确它的输出是技术结论、原型反馈还是可发布功能。

3. 迭代过程中，最贵的是晚发现

假设团队第二天就发现接口负责人尚未确定，尚有时间换方案、缩小范围或协调资源。若到迭代第九天才发现，代码可能已经围绕错误假设实现，测试环境也可能来不及准备。延误成本不是匀速增加的，越靠近交付日，重排工作越困难。

因此，我不建议负责人等到每日站会才第一次检查风险。站会适合快速同步昨天完成、今天计划和阻塞事项；真正的风险管理还需要看板、依赖清单、测试排期和需求变更记录。不同信息要放在容易被发现的位置，而不是藏在聊天记录里。

三、常见误区：看起来像敏捷，实际在放大风险

1. 把“所有人都很忙”误认为高效

当每个人手里都有很多任务时，表面上没有闲置，实际却可能出现大量并行和切换。开发做一半去处理紧急问题，测试等一批功能后集中验证，产品又在多个需求之间反复补充细节。每项工作都在推进，却没有一项稳定流到完成。

负责人要观察“进行中工作”而非只看任务总量。若一个人同时负责多个高优先级事项，遇到临时工作时，原有工作很可能只是从“进行中”变成“暂时没人看”。为团队设置合理的并行上限，往往比继续往清单里塞任务更能缩短交付周期。

2. 把故事点当成个人绩效排名

估算的价值在于帮助团队讨论复杂度和不确定性，不是把不同成员的产出换算成可比较的个人分数。若管理者把故事点和奖金、排名绑定，团队很快就会学会报大数字、拆小任务，或者避开难以估算的工作。

我更看重团队自己的历史数据是否稳定，以及估算讨论有没有揭示不同理解。若某项工作有人估两天、有人估一周，真正重要的不是取平均，而是追问差异来自范围、技术方案、依赖，还是对“完成”的理解不同。

3. 把站会开成逐级汇报

站会不是负责人逐个盘问“做了多少”，也不是让每个人念一遍工作日志。它应帮助团队同步当前迭代目标、发现阻塞，并决定谁需要在会后继续讨论。如果问题需要技术评审或需求决策，站会上只确认参与人和时间，不要让全体成员陪着展开半小时。

如果同一个阻塞连续几天出现在站会上，却没有负责人、下一步和升级路径，那么站会只是重复播报问题。会后要把阻塞转成具体动作：谁在什么时间前联系谁，何时确认结果，失败后采用什么备选方案。

4. 把新增需求称作“顺手做一下”

新增需求通常不是零成本。即使开发量只有半天，也会带来澄清、设计、测试、发布说明和回归检查。负责人应要求新增事项经过明确的变更判断：它是否影响当前迭代目标，是否有必须立即处理的业务风险，进入本轮要挤出哪项已承诺工作。

真正的紧急事项当然可以插入，但“有价值”不等于“必须现在做”。如果每个提出方都能把自己的需求标成最高优先级，优先级就失去意义。负责人要建立可解释的入口，而不是依赖谁声音更大。

5. 把开发完成当成用户可用

代码合并不代表功能已经交付。测试未完成、配置未准备、权限未验证、迁移方案未检查，任何一个环节都可能让功能无法安全使用。若团队经常在最后一天才集中测试，应重新审视任务拆分方式和“完成”定义，而不是只要求测试加快速度。

团队可以定义最小但明确的完成标准：实现完成，自动化或必要的手工验证通过，验收条件满足，相关风险和发布依赖已记录。标准可以因工作类型不同而有差异，但不能在临近交付时临时放宽。

四、专业判断逻辑：项目负责人如何做取舍

1. 先判断目标，再判断任务

当需求发生冲突，我不会先问“哪项更简单”，而会先问“本轮最重要的结果是什么”。目标如果是让管理员能独立完成某个关键流程，就应优先保住这个完整流程，而不是为了任务数量同时交付多个彼此割裂的页面。

目标要足够具体，能让团队在中途判断是否偏离。例如，“提升体验”过于宽泛；“让新建项目的管理员无需人工协助完成初始化，并能在引导页看到失败原因”更容易转化为验收条件和验证方案。

2. 用容量约束计划，不用愿望填满时间

估算容量时，不能把所有成员的工作日简单相加。团队还要扣除已知休假、支持轮值、会议、发布准备、跨团队协调和不可避免的维护事项。对于承担线上支持的团队，历史上实际能投入计划工作的时间，往往比名义工时更有参考价值。

初期不需要追求精细到小时。负责人可以连续记录数个迭代：计划工作量、实际完成量、临时插入量、未完成原因和缺陷回流，再用本团队的数据修正容量假设。重点不是找一个漂亮的平均值，而是识别波动范围和主要来源。

3. 看风险时，区分不确定性和重要性

高不确定性不等于高优先级，高重要性也不等于必须立刻实现。负责人可以将工作粗略放入两个维度：业务影响和不确定性。影响高且不确定性高的事项，通常应优先做验证或拆出探索任务；影响低且不确定性高的事项，则可能应该暂缓，而不是消耗整轮容量。

评审风险时，我会追问三件事：如果判断错了，损失有多大；多久能拿到证据；有没有成本更低的验证方式。这个问题组能帮助团队区分“要马上开发”与“要尽快学习”。

4. 把变更纳入机制，而不是压制变化

敏捷不代表需求可以无限插入，也不代表迭代开始后完全不能调整。合理做法是明确变更入口：提出方说明业务原因和时限，产品负责人判断优先级，团队评估影响，项目负责人确认需要移除或延期的事项，并记录决策。

若变更来自严重故障、安全风险或监管要求，优先处理可能是正确的；若只是重要客户希望提前看到一项改进，则应比较其收益、影响面和当前承诺。决定可以不同，但理由要透明，避免团队把每次插入都理解为“原计划没有价值”。

5. 预测交付时，关注趋势与范围，不迷信单个日期

负责人需要向干系人给出判断，但不应把不确定的日期伪装成确定承诺。可以表达当前范围、已验证部分、剩余高风险项和时间区间，再随着证据更新预测。若外部必须要一个日期，应说明该日期依赖哪些条件，以及范围变化时如何重新评估。

对团队内部来说，燃尽趋势、完成流量和阻塞年龄可以帮助提早发现异常；但单张图不能代替讨论。若燃尽线平稳下降，却有大量工作停留在待验收，团队仍然没有形成可交付结果。

五、案例拆解：把“赶不上”变成可处理的计划偏差

1. 情景设定：一个两周迭代的企业产品团队

以下数据为情景模拟。团队计划交付三项与管理员工作流有关的结果：完善权限配置、增加导入失败原因提示、补齐相关自动化验证。启动时，团队根据已知容量选择了七项主工作，并预留一部分时间处理支持和未知问题。

迭代第三天，团队发现导入服务依赖的外部接口文档与实际行为不一致。与此同时，销售团队提出一项高价值客户请求，希望本轮增加一个导出格式。若负责人把两项都直接塞入计划，原目标很可能被稀释；若一概拒绝，又可能错失重要业务机会。

2. 第一步：把问题拆成事实、假设和决策

团队先把接口问题写成事实：测试环境返回字段与文档不一致，当前不能确认所有失败场景。再把尚未证实的内容标为假设：生产环境可能使用另一套版本，或者文档落后于服务实现。最后明确需要的决策：先用一到两天验证真实行为，再决定继续原方案、增加兼容处理或调整交付范围。

这样做的价值在于避免争论停留在“接口是不是有问题”。团队有了可验证动作、责任人和截止时间，项目负责人也能向相关方说明当前的不确定性和可能影响。

3. 第二步：对插入需求做容量置换

出口格式请求经过确认后，团队判断它对一个关键客户确有价值，但不属于安全或故障级紧急事项。负责人请提出方确认业务时限，并把工作拆成最小可用范围。随后，团队比较它与当前三项目标的关系，决定本轮只做接口验证和权限配置，导出格式进入下一轮候选池。

这不是简单拒绝需求，而是让需求进入透明的优先级队列。提出方知道了等待原因，团队没有在承诺不变的情况下增加工作，产品负责人也保留了根据验证结果重新排序的空间。

4. 第三步：让风险在中途变成选择，而不是末尾变成事故

迭代第六天，验证发现外部服务确实存在两个版本差异。团队确认可以通过兼容层处理，但若本轮强行加入完整的导入失败提示和所有自动化覆盖，测试时间将不足。团队于是拆分交付：先保障权限配置和高频失败原因提示，低频场景补充到下一轮，并在发布说明中标明已覆盖边界。

这个决策不是降低质量标准，而是缩小本轮范围，让保留的部分达到完成标准。负责人需要确认“缩小范围”没有变成隐藏风险：哪些场景暂未支持，谁会受到影响，用户如何获知，下一轮何时评估，都要有记录。

5. 第四步：复盘偏差，修改下一轮输入

迭代结束时，团队不只统计完成项，还回看依赖何时被发现、澄清用了多久、测试何时开始、临时请求占了多少容量。情景模拟中，团队发现接口文档在计划会前没有经过服务方确认，测试介入偏晚，新增请求也缺少统一入口。

下一轮改进不是笼统要求“加强沟通”，而是落实为三项具体动作：接口类需求在计划前指定技术联系人；候选需求增加依赖确认字段；测试参与验收条件评审。每项动作都指定负责人，并在下一次复盘检查是否有效。

6. 如何理解情景中的观察数据

团队可以记录每轮的计划工作、完成工作、插入工作和未完成原因，但不应把这些数字直接当成团队优劣排名。若某轮未完成是因为外部依赖信息错误，改进重点应是依赖验证；若反复出现测试积压，改进重点则可能是更早集成、更小批交付或优化自动化覆盖。

情景模拟中的数值只能帮助演示决策结构。真正使用时，应从团队自己的看板、缺陷记录、发布记录和会议纪要中取数，并写清统计口径。例如“完成”是否含验收，工时是否扣除支持轮值，插入工作是否包含线上故障处理。

六、实操方法：负责人如何跑完一个迭代周期

1. 计划会前：整理候选项和依赖

计划会前一至两天，负责人应推动产品、研发和测试共同检查候选项，而不是独自替团队排满清单。每项候选工作至少要有目标、范围、验收条件、依赖方和主要风险。存在关键空白时，先安排澄清或探索，不要靠会议上的临时猜测生成承诺。

可以用一张轻量表记录信息：需求名称、目标用户、预期结果、验收条件、依赖、估算区间、风险、是否适合本轮。表格的目的不是增加审批，而是减少计划会上反复补背景的时间。

2. 计划会中：先定目标，再挑工作

负责人先带团队确认本轮目标和不可突破的约束，例如发布窗口、必须处理的风险或已知假期。然后根据容量和风险排序候选项，先选择对目标贡献最大的工作，再讨论可选项。若容量不足，应在会上明确删减，而不是把每项都标为“尽量完成”。

对于过大的工作，优先按可独立验证的用户结果拆分，而不是按前端、后端、测试机械切割。拆分后的部分应能形成可检查结果；若一个功能必须全部完成才有用户价值，也可以先设计小规模技术验证，并明确它不是完整交付。

3. 迭代每日：用短同步发现阻塞

每日同步围绕迭代目标展开，不必让每个人机械回答三个固定问题。团队可以直接看板上讨论：哪些工作完成了，哪些正在等待，是否有任务停滞，今天最需要谁协助。负责人负责把需升级的事项带出会议，并安排后续决策。

对于进行中时间明显过长的事项，可询问是否存在隐性范围扩张、依赖迟迟未解决或任务拆分不足。不要先假定执行者效率低。必要时让团队成员结对排查，或拆出一个短时验证任务，以尽早确定剩余范围。

4. 迭代中途：检查目标和预测，不只看燃尽图

在迭代中段，负责人应检查尚未开始的承诺、阻塞年龄、测试排队和新增需求。中途检查不是要求团队为了曲线好看把任务改状态，而是重新判断当前范围是否仍能交付，以及需要做什么才能守住核心结果。

若预测显示无法全部完成，尽早提出选项：缩小低价值范围、拆分发布、增加协作、调整日期，或接受明确的风险。选项之间要说明影响，决策应由有权承担业务后果的人参与，而不是把压力留给开发和测试自行消化。

5. 迭代结束：分开做评审和复盘

评审关注交付物和用户反馈：功能是否符合预期，使用者是否能完成目标，仍有哪些边界未覆盖。复盘则关注工作方式：哪里等待过久，哪些信息太晚出现，团队的协作机制是否需要调整。两者目的不同，混在一起容易让团队只讨论功能意见，忽略过程问题。

复盘改进行动要少而明确。每轮选一到两个最有影响的改进项，写清负责人、完成时间和验证方式。若连续几轮列出十几项改进却没有回看，复盘就会成为情绪释放，而不是组织学习。

七、不同情况下的行动建议与取舍

1. 小团队、依赖少、需求变化快

小团队不需要为了“敏捷”建立复杂流程。保留清晰的目标、轻量看板、简短同步和周期性复盘即可。负责人要特别注意角色重叠造成的隐性成本：同一个人既做产品决策又写代码时，需求澄清和实现很容易在脑中完成，却没有留下可供其他人理解的验收信息。

此类团队可降低会议和文档负担，但不能省略变更记录和完成标准。取舍的重点是轻量而可见：少写流程说明，多让当前优先级、阻塞原因和交付状态容易被团队共同看见。

2. 中大型团队、跨部门依赖多

规模扩大后，信息传递和责任边界会变成主要风险。负责人需要明确需求入口、依赖责任人、版本计划、风险升级路径和跨团队协作节奏。仅靠即时消息推进，容易出现“每个人都以为对方已经确认”的情况。

对于中大型企业及百人以上组织，可以考虑使用具备需求管理、迭代规划、缺陷跟踪、权限治理和报表能力的项目管理平台。以 PingCode 为例，评估时应关注它是否适配现有流程、能否承载跨团队协作、权限和审计要求是否满足，以及能否与研发工具链衔接。产品适配程度应由实际试点验证，不能仅凭功能清单下结论。

如组织需要私有化部署，应把部署架构、升级责任、备份恢复、运维能力和安全审查一起纳入评估。工具支持私有化不等于部署后自动满足组织的全部安全要求；实际配置、运维制度和验收标准同样重要。

若团队考虑从 Jira 迁移，所谓“平滑迁移”应拆成可验收的迁移计划：字段与工作流映射、用户和权限迁移、历史数据保留、附件与关联关系检查、自动化规则重建、培训和回滚预案。应先选择一个代表性团队试迁，核对关键记录，再决定扩大范围。国产替代是否适合，不应由口号决定，而应由功能覆盖、数据治理、服务响应、迁移成本和长期运维能力共同判断。

3. 线上支持和紧急插入较多

若团队常被故障和客户问题打断，计划容量必须反映真实情况。可以设支持轮值，或根据历史记录预留一部分容量。具体预留比例要由团队数据决定，不宜直接照搬其他组织的数字。

同时要建立紧急等级和处理入口。真正影响服务可用性、安全或合规的事项，可以进入快速通道；一般咨询和体验建议则进入候选池。轮值人员集中处理入口，能减少所有成员被零散消息同时打断的情况。

4. 团队交付周期长、每轮都难以形成成果

优先检查工作拆分是否过大、集成是否太晚、测试是否被安排在最后。如果一个故事需要跨多个迭代才能看到结果，可尝试先做技术验证、缩小用户场景、分阶段开放或拆成可独立验收的纵向切片。

不要为了让看板快速变绿，把一个大事项拆成大量没有独立价值的子任务。拆分的标准是能否更早获得反馈或降低风险，而不是让进度统计更好看。

5. 外部日期固定、业务活动不能延期

当发布日期不可移动，负责人应尽早讨论范围弹性和风险边界。可以把必需功能、可延后功能和明确不在本次范围的事项分开，并提前进行发布演练、环境检查和关键路径验证。

取舍上，通常应先保护关键用户流程和质量底线，再调整次要范围；不建议在最后几天以删测试、跳验收的方式“守住日期”。如果业务决策方坚持固定日期且不接受范围调整，应把因此增加的风险明确记录，让决策责任与执行责任对应。

八、指标与工具：用数据发现问题，不用数字制造压力

1. 指标要回答一个具体问题

如果团队想知道工作为什么堵住，可以看周期时间和阻塞年龄；如果想知道计划是否过载，可以看计划完成比例、插入工作量和未完成原因；如果关心发布稳定性，则需要观察缺陷回流、回滚和线上事件。指标应服务于一个清楚的问题，否则只会增加报表负担。

尤其要谨慎使用速度指标。团队速度可以用于团队自身的容量预测，但不适合跨团队比较，更不适合直接评价个人。人员变化、工作复杂度和支持任务都会影响数值，脱离背景的排名容易鼓励错误行为。

2. 先约定统计口径，再看趋势

周期时间从哪里开始、在哪里结束？“完成”是否包含验收？临时工作是否纳入分母？缺陷回流按发现时间还是修复时间统计？这些定义不同，结果就不能直接比较。负责人应把口径写在仪表盘说明或团队约定里。

观察趋势时，优先寻找持续变化和异常信号，不要因一个迭代波动就断言流程失败。若数据变差，要回到具体工作项核查：是否发生了大量跨团队等待，是否有大需求，是否遇到假期或线上故障。数据提出问题，事实调查解释问题。

3. 工具选择看流程适配和治理成本

工具的价值不是多几个看板，而是让团队用较低成本保持信息一致。评估工具时，我通常检查：需求到发布是否能形成可追踪关系，团队能否按自身流程配置状态，权限是否适合组织边界，数据是否便于分析，迁移和集成是否可控。

选型前应做小规模试点，至少覆盖一个真实迭代和一个跨团队依赖场景。试点期间记录配置时间、用户适应成本、数据迁移问题、报表可用性和管理维护工作量。工具承诺的能力，只有在真实流程中能被使用，才算组织可获得的能力。

九、常见问题解答

1. 迭代中途新增需求，是否一定不能接？

不是。关键是判断其紧急程度、业务影响和机会成本。故障、安全风险或明确的监管要求可能需要立即处理；一般新增需求则应进入优先级评估，并说明加入本轮后需要移除什么工作。这样既允许变化，也避免承诺无限膨胀。

2. 迭代计划完成率低，负责人应该先做什么？

先按原因分类，而不是立刻要求团队加班。区分估算偏差、需求变更、依赖等待、任务过大、测试积压和支持工作，再检查哪些原因反复出现。若计划完成率低但核心目标稳定达成，问题可能是清单管理；若核心目标也频繁落空，则需要调整容量、输入质量或风险处理方式。

3. 每日站会是否必须每天开？

站会频率应服务于团队协作需要。共同工作、依赖密集或变化较快的团队，每日短会通常有价值；成熟且协作成本较低的团队，可以尝试异步同步加定期讨论。无论采用哪种方式，阻塞都必须有明确的处理人和升级路径。

4. 没有故事点，还能做迭代管理吗？

可以。团队可以使用相对规模、工作项数量、周期时间或历史吞吐量辅助计划，但更重要的是范围清晰、容量真实、风险可见。故事点不是敏捷的必需条件，也不是迭代管理的目的。

5. 什么时候该缩小范围，什么时候该延期？

若能保留完整且安全的核心用户价值，并清楚披露未覆盖边界，缩小范围通常有利于尽早交付。若拆分后会破坏关键流程、产生数据不一致或带来不可接受的风险，则延期或重新规划可能更负责任。判断依据应是用户影响和风险，而不是看板是否按时变绿。

6. 团队成员长期加班，是否说明迭代计划不合理？

这通常是需要调查的信号，但不能仅凭加班推断原因。可能是容量长期高估、支持工作未计入、需求反复变化，也可能是关键技能集中在少数人或存在技术债。负责人应收集工作分布和变更数据，先处理系统性原因，不能把持续加班当作正常计划能力。

十、总结：把迭代做稳，靠的是更早做出正确取舍

迭代管理最容易走偏的地方，是把可视化、会议和估算当成了敏捷本身。它们只是帮助团队获得信息的工具。真正决定迭代质量的，是负责人能否在计划时承认容量边界，在执行中及时暴露依赖，在变更时要求明确置换，在交付时坚持完成标准。

我的独特判断是：高质量迭代不是“每轮都按原计划完成”，而是团队能持续缩短从发现偏差到做出选择的时间。早发现接口问题，可以改方案；早发现范围膨胀，可以重新排序；早发现测试排队，可以拆分交付。拖到最后才面对现实，往往只剩加班、降质和延期三种昂贵选项。

项目负责人下一步可以从一轮小实验开始：挑一个团队，记录计划容量、插入工作、阻塞年龄和验收完成情况；计划会上先明确目标与候选项边界；迭代中途检查一次依赖和测试排队；结束时只选一到两个改进行动，并在下一轮验证。先让事实可见，再决定该增加流程、调整工具还是改变团队协作方式。