敏捷项目Scrum全流程：项目成员制度设计与一文讲清

Scrum 项目最常见的失速，不是团队不会开每日站会，而是产品负责人、Scrum Master 和开发团队的职责边界没有被设计出来：需求谁说了算、谁能改变 Sprint 目标、成员能否被临时抽走、延期由谁解释，往往直到冲突发生才临时讨论。Scrum 全流程真正要先搭好的，不是一套会议日历，而是一套让决策有归属、工作有边界、反馈能闭环的成员制度。

一、先讲核心结论：Scrum 首先是责任制度，其次才是流程

1. 先明确三类责任，不要从会议安排开始

我设计 Scrum 团队时，通常先问四个问题：谁对产品价值负责？谁负责让团队持续改进？谁决定 Sprint 内如何完成工作？这三个问题的答案，分别对应 Product Owner、Scrum Master 和 Developers。Scrum Guide 2020 将这三者定义为 Scrum Team 的三项责任，而不是传统部门里的职位名称。

Product Owner 对产品价值和 Product Backlog 管理负责；Scrum Master 对 Scrum 的有效理解与实践负责；Developers 对每个 Sprint 中创造可用增量负责。三者不是上下级，也不是一个人把任务派给另一个人执行。只要“谁负责”与“谁有权决定”长期分离，流程就会退化成会议加审批。

这里要区分“责任”和“独占权”。Product Owner 对 Backlog 排序负责，不代表他可以在 Sprint 中随意追加工作；Developers 自主管理工作，不代表可以不透明地改变 Sprint Goal；Scrum Master 促进团队解决障碍，不代表替团队承诺日期或替经理分配任务。

2. 用边界规则保护 Sprint，而不是用口号要求专注

Scrum 的基本节奏包括 Sprint Planning、Daily Scrum、Sprint Review 和 Sprint Retrospective。它们不是四场状态汇报会，而是围绕目标、计划、检查和调整形成的反馈回路。若团队开完会后仍由项目经理私下改任务、业务方直接插单，会议本身并不能让 Scrum 成立。

我建议先写出一页团队约定，至少包含成员名单与投入比例、产品决策人、Sprint Goal、紧急需求入口、完成标准、缺席与替补规则、跨团队依赖升级方式。规则不必厚，但必须能回答日常争议。所谓敏捷，不是规则少到无法判断，而是规则足够轻，遇到变化时能迅速调整。

下面的数值为情景模拟，用于展示团队制度成熟度提升后可能观察的变化，不是行业统计。重点不是把目标定成某个固定百分比，而是建立可持续追踪的基线。

3. 先把“流程完成”与“价值交付”分开

团队可以准时开完所有会议，却没有交付可用增量；也可能在某个 Sprint 中少开一场形式化会议，却通过清晰的异步协作完成检查和调整。判断 Scrum 是否有效，不能只看仪式是否齐全，还要看产品增量是否符合 Definition of Done、用户反馈是否进入 Backlog、团队是否持续改善交付方式。

因此，第一步不是追求“严格照表打卡”，而是为每个事件定义输入、参与者、决策和输出。例如 Sprint Planning 的输出应包括 Sprint Goal、选入的工作以及实现计划；Daily Scrum 的输出应是对 Sprint Goal 进展的检查与计划调整，而不是逐人向主管报进度。

二、背景与真实场景：为什么成员制度比流程图更难

1. 多项目共享成员，让“团队”只存在于组织图上

在规模较小的产品团队里，成员可能同时支援客户项目、平台维护和业务需求。组织图上他们属于一个 Scrum Team，日历里却被不同负责人拆成零散工时。Sprint Planning 依据“每个人本周大概有空”制定计划，几天后就被临时会议、故障排查和跨项目任务冲散。

这类问题不能仅靠团队提高估算准确性解决。估算的前提是容量相对稳定；如果成员投入比例没有进入计划，团队估算的不是工作量，而是在猜本 Sprint 还剩多少可用时间。我的判断是：成员稳定性不足时，先改善容量与变更管理，再讨论估算方法。

2. 业务方多头提需求，Product Owner 名义存在、决策权缺位

另一个常见场景是 Product Owner 负责整理需求，却无权确定优先级。销售、交付、研发负责人和高层都能直接要求团队“先做这个”，而 Product Owner 只能在事后补写 Backlog。结果是团队表面上有统一入口，实质上仍然接受多头指挥。

判断决策权是否真实，不要只问谁的名片上写着 Product Owner，而要看发生优先级冲突时，谁能做最终排序；谁能与利益相关者解释取舍；谁对产品结果负责。若答案始终是“开会再看领导意见”，这个角色就还没有获得有效授权。

3. 大型组织的依赖与治理要求，不能靠团队自治自动消失

中大型组织通常需要处理安全评审、架构依赖、合规检查、发布窗口和跨部门交付。Scrum 的团队自治不是忽视这些约束，而是把它们放到透明的工作系统中。若依赖长期藏在个人聊天和表格里，团队即使按时完成 Sprint 任务，也可能无法形成可发布增量。

规模扩大时，成员制度需要同时解决两层问题：单个团队如何自主完成工作；多个团队如何共享接口、风险和节奏。不要把所有协调都塞进一个更大的每日站会。团队间的依赖应尽量提前暴露，并明确由谁协调、何时升级、对 Sprint Goal 有何影响。

4. 工具能呈现制度，不能替团队作出制度选择

当团队从几十人扩展到多个产品线，电子表格、聊天记录和个人看板可能难以维持同一套需求状态与跨团队视图。此时项目管理平台的价值在于呈现 Backlog、迭代、缺陷、依赖、权限和历史变化，而不是自动决定谁是 Product Owner、哪些需求该优先。

例如，服务中大型企业及 100 人以上组织的 PingCode，可用于集中管理需求、迭代与协作过程；其支持私有化部署，并提供 Jira 平滑迁移能力。选型时，我会把“国产替代不二选择”视为供应商或方案方的宣传表达，而不会把它当成无需验证的结论。企业仍应依据迁移完整性、权限模型、集成能力、安全要求、运维成本和试点结果作出判断。

对于工具迁移，重点不是把旧系统里的每张卡片原样搬过去，而是确认字段、工作流、附件、权限、历史记录和关联关系是否需要保留。先选择一个有代表性的团队做迁移演练，再核对关键数据和日常使用体验，通常比全公司一次性切换更容易控制风险。

三、常见误区：看似规范，实际让责任变得模糊

1. 把 Product Owner 当成需求录入员

如果 Product Owner 的主要工作是把不同人的要求复制到工具中，却不能决定需求顺序、拒绝低价值请求或与用户验证假设，团队就没有真正的产品决策入口。Backlog 再整齐，也只是需求仓库。

改进时要明确授权范围：哪些优先级由 Product Owner 决定，哪些涉及预算、法规或战略方向的事项需要更高层确认；确认后谁负责把决策反馈给团队。授权边界清晰，才不会让团队在每个冲突中都重新寻找“真正的老板”。

2. 把 Scrum Master 当成项目秘书或进度追踪员

Scrum Master 的价值不在于替团队催任务、维护会议纪要或向管理层汇报每个人完成了多少，而在于帮助组织理解 Scrum、改善团队协作、清除阻碍，并让事件有效发生。如果他被要求同时承担行政跟催和人员考核，团队成员很容易把 Daily Scrum 变成向监督者报数。

在小团队里，Scrum Master 可以是兼职角色，但必须有明确时间和授权。如果此人每天都被业务交付占满，却仍被要求解决组织障碍，那么制度只是在纸面上设置了一个无人履行的责任。

3. 把 Developers 理解为“只负责编码的人”

Scrum Guide 中的 Developers 是对创建产品增量负责的角色群体，不等于只写代码的工程师。实际工作可能涉及设计、测试、数据、分析、运维或其他交付能力。若测试和设计完全在团队之外排队，团队就可能每个 Sprint 都“开发完成”，却没有可用增量。

团队组成要围绕交付所需能力设计。若某项能力无法全职进入团队，也要明确服务约定和依赖窗口，不能把“资源支持”当作随时可用的隐性承诺。

4. 把 Sprint Commitment 误解为不许调整

Sprint Goal 提供方向，不是把所有工作锁死。产品负责人和 Developers 可以协商调整 Sprint Backlog，前提是不危及 Sprint Goal；如果目标已经失去意义，Product Owner 有权取消 Sprint。实际工作中真正需要保护的是目标和透明度，而不是每张卡片的原始计划。

如果团队因故障必须处理生产问题，应记录占用容量、影响目标的程度和替代方案。若每周都有大量临时工作，就不该继续把它伪装成偶发事件，而应把支持性工作纳入容量设计，或建立轮值机制。

5. 把速度当作个人绩效指标

Velocity 是特定团队在一段时间内的估算完成量，用于辅助团队自己的规划。它不适合跨团队比较，更不应直接转化为个人产出排名。估算尺度、工作类型、团队构成和质量标准不同，数字并不具备天然可比性。

把速度与奖金、排名绑定，往往会诱发拆分任务、抬高估算或回避复杂工作。若管理层需要观察交付健康度，应同时看目标完成、交付周期、缺陷和用户结果，并将数据用于系统改进，而不是寻找“低绩效成员”。

四、专业判断逻辑：按决策权、容量和反馈质量设计制度

1. 用“决策归属”检查角色是否真实存在

我会把关键决策逐项列出，再确认谁负责、谁参与、谁拥有最终决定权。角色名称并不重要，决策是否在需要的时间发生才重要。遇到需求冲突时，团队应能在一个明确的入口获得排序结果，而不是等待多个负责人反复拉扯。

2. 用容量事实替代“大家尽量挤一挤”

Sprint Planning 前，团队应估算可用工作日和非计划负担。一个简化示例：7 名成员，Sprint 为 10 个工作日，每人理论上 10 天，共 70 人日；扣除假期、培训、值班和固定支持后，若可投入比例为 75%，可规划容量约为 52.5 人日。这个结果不是精确预测，而是让隐性占用显性化。

对知识工作而言，人日不等于可直接装满的任务量。会议、协作、返工和不确定性都会影响实际产能。团队可以从过去若干个 Sprint 的完成情况校准容量，但不应因为一次超额完成就永久提高承诺。

3. 用变更分类决定如何处理，而不是每次都争论“能不能插单”

需求变化至少要区分三类：影响 Sprint Goal 的紧急事件、可进入下一轮排序的普通需求、发现后需要补充信息的探索项。前两类的处理路径不同，第三类通常需要产品负责人继续澄清，而不是直接变成开发任务。

对紧急事件，可以设定清楚的触发条件，例如安全事故、关键服务不可用或法定期限变化。处理时由 Product Owner 与 Developers 评估影响：是否替换等量工作、是否调整目标、是否需要取消 Sprint。每次插单都记录原因，才能知道它究竟是例外还是运营负担。

4. 用可用增量定义完成，而不以个人任务状态代替

Definition of Done 应是团队共享的质量标准，可包括代码评审、自动化测试、文档更新、安全检查和可部署性等适用条件。它不应只是“开发完成”或“测试同学验收通过”，否则团队可能将未验证工作推迟到 Sprint 之外。

不同产品的完成标准可以不同，但不能在每个需求上临时改变而不透明。若某项工作受外部合规流程限制，应在计划时说明条件，并明确哪些部分能形成可用增量、哪些仍属于未完成工作。

5. 用事件的输出判断会议是否值得保留

我不会用“会议时长越短越敏捷”来评价团队。更有用的问题是：Sprint Planning 是否形成可信的目标和计划？Daily Scrum 后团队是否调整工作？Review 是否让利益相关者基于可运行增量给出反馈？Retrospective 是否选出可执行的改进实验？若答案是否定的，先修正事件目的和参与方式，再考虑压缩时间。

Scrum Guide 建议 Sprint 为一个月或更短，且事件时间框是上限而非必须开满的时长。团队可以根据实际情况采用更短 Sprint，但需要评估集成、测试、外部审批和反馈速度是否匹配。

五、案例与数据观察：一个多角色产品团队如何重建成员制度

1. 案例边界：先说明这是情景推演，不包装成真实客户数据

以下是依据常见团队协作问题构造的情景推演，不代表某家企业的真实经营数据。团队有 8 人，包含产品、设计、开发和测试能力，采用两周 Sprint；成员同时承担产品迭代、线上支持和跨部门需求。连续几个 Sprint 出现计划外工作偏多、测试集中到最后几天、业务方绕过产品负责人加急等情况。

团队原先把任务数和完成率作为主要观察指标。复盘时发现，问题不是成员不努力，而是两个制度缺口：每周约有固定支持工时，却未进入计划；Product Owner 没有明确的优先级授权，导致业务方可直接改变工作顺序。

2. 第一步：画出投入结构，先看到被隐藏的工作

团队按过去四周记录不同工作类别：计划内产品工作、线上支持、跨团队协调、返工和临时需求。记录不用于追责，而是为了理解容量流向。采集数据时保持口径一致，例如把“线上故障处理”和“故障后复盘”分开，避免一项工作被重复计入多个类别。

情景模拟中的结果显示，原计划容量里约有 18% 被线上支持占用，约 10% 被临时需求占用。真正可用于计划内产品工作的时间，比团队原先假设少近三成。这个发现改变了计划方式：团队不再承诺名义上的满负荷任务，而是保留支持容量，并明确紧急事件的入口。

3. 第二步：把需求入口收敛到 Backlog，而非关闭业务反馈

团队规定，任何利益相关者都可以提出需求，但只有 Product Owner 负责整理、澄清并确定排序。紧急事件按约定条件触发；普通需求进入 Backlog，等待基于价值、风险、依赖和成本讨论。这样做不是让产品负责人垄断信息，而是让团队避免被多个彼此冲突的优先级同时驱动。

为防止入口收敛变成信息黑箱，团队在 Review 中展示近期排序变化及原因，并开放利益相关者反馈。Product Owner 对取舍负责，也需要说明为什么某项需求暂缓。透明度降低了“私下找工程师插队”的动机。

4. 第三步：把测试、集成和验收前移到 Sprint 计划

团队发现测试工作集中在 Sprint 后半段，并不是测试人员不够努力，而是需求拆分方式造成开发完成后才开始验证。于是他们把验收条件写进 Backlog refinement，将测试设计、自动化和集成依赖提前纳入计划，并将“可运行、符合 Definition of Done”作为团队共同责任。

这一步没有立刻让所有任务变短，但减少了“开发卡片完成、产品却不能使用”的假完成。团队每周观察未完成工作是否集中在测试、评审或外部审批环节，并据此调整拆分粒度和依赖安排。

5. 第四步：用少量指标追踪系统变化，而不是堆满仪表盘

改进前后，团队保留四项核心观察：Sprint Goal 达成情况、交付周期、计划外工作占比和生产缺陷趋势。每项指标都服务于具体问题。例如计划外工作增加时，先检查需求入口与支持负担；交付周期变长时，检查等待、依赖和批量规模，而不是直接要求成员“提高速度”。

以下数据是情景模拟，用于示范一组指标如何配合解读。实际团队应先用一致口径建立自己的基线，至少观察多个 Sprint，再判断改动是否有稳定效果。单个 Sprint 的波动不足以证明制度成功或失败。

6. 复盘真正的结果：交付稳定不等于产品成功

如果目标达成率提高，下一步仍要检查产品结果：用户是否采用、关键流程是否改善、缺陷是否下降、业务假设是否被证实。团队可以非常高效地交付一批用户不需要的功能。因此 Scrum 的检查不应止于速度和完成数量，还要让产品反馈回到 Product Backlog 的优先级决策。

若团队无法直接获得用户数据，可以先使用访谈、支持工单、可用性测试或业务方反馈建立证据，再逐步改善埋点和分析能力。数据不完整时要标明局限，避免把内部交付指标误称为用户价值。

六、不同情况下的行动建议：从最影响交付的缺口开始

1. 新团队：先建立最小可运行的制度

新组建的团队不需要一开始就写几十页敏捷手册。先确认三类责任人、产品目标、Backlog 入口、Sprint 长度、团队容量、Definition of Done 和事件节奏。将这些约定放在成员都能找到的地方，并在前两个 Sprint 后依据实际问题修订。

启动阶段尤其要避免把团队成员名单等同于真实投入。每位成员的投入比例、兼职职责、固定值班和审批依赖都要进入规划。否则第一个 Sprint 的偏差会被解释为估算错误，组织真正的容量问题反而被忽略。

2. 成员跨多个项目：先讨论稳定性，再承诺功能量

若核心成员长期同时服务多个项目，管理层需要做资源取舍：选择相对稳定的团队投入，或承认团队是共享服务模式并采用适配的容量计划。不要要求成员对两个互相冲突的 Sprint Goal 同时负责。

短期内无法调整组织结构时，可以为共享成员设定明确的服务时段、工作优先级和响应窗口，并把协调成本纳入计划。长期看，应评估频繁切换对交付周期和质量的影响，再决定是否形成更稳定的产品团队。

3. 产品负责人权力不足：建立授权与升级机制

如果 Product Owner 没有最终排序权，先与业务负责人明确哪些决策可以在授权范围内完成，哪些事项需要管理层确认，以及确认时限。把“谁提出需求”与“谁决定团队当下做什么”区分开，避免提出者直接越过产品决策链。

当管理层保留重大方向决策权并不一定有问题，关键在于决策是否及时、输入是否透明。如果优先级经常因高层临时意见改变，应将其作为治理现状处理，而不是假装产品负责人拥有完整授权。

4. 线上支持占比高：建立轮值或容量缓冲

若支持工作不可预测，考虑轮值成员、专门支持时段或明确的容量缓冲。轮值的优点是让其他成员保持相对专注；缺点是轮值者可能被频繁打断，且需要覆盖关键技能。选择方式时要看故障类型、响应时限和团队规模。

若支持工作长期占据较大比例，单纯增加 Sprint 缓冲不够。应进一步分析工单来源、重复故障、自动化机会和服务稳定性，把降低运营负担纳入产品改进，而不是让团队永远在“开发”和“救火”之间切换。

5. 跨团队依赖多：让依赖显性化并设定协调责任

多个团队共享组件、环境或发布窗口时，应在 Sprint Planning 前识别依赖，说明依赖方、所需日期、接口条件和延迟后的替代方案。不要把“对方会配合”当作计划依据。若依赖经常阻断交付，优先减少耦合、改进接口或调整团队边界。

跨团队协调会议只有在能够解决真实依赖时才有价值。会前应准备依赖清单，会上形成责任人和完成时间，会后回到各团队的工作系统中跟踪。单纯增加会议频次，并不会自动降低等待时间。

6. 百人以上组织：先试点迁移和治理，再扩展平台化管理

在 100 人以上组织，工具选型往往涉及权限、数据驻留、审计、身份集成、项目模板、报表和跨团队视图。可以把 PingCode 等项目管理平台纳入评估，但不应先根据功能清单做全量采购判断。先挑选产品形态、合规要求和协作方式有代表性的团队进行试点。

若组织正在从 Jira 迁移，可先定义迁移范围：哪些项目继续维护，哪些历史数据必须保留，工作流和字段如何映射，用户权限如何转换，集成如何替代。支持平滑迁移是重要条件之一，但不能代替数据校验、用户培训和回滚预案。私有化部署也应同时评估升级维护、备份恢复和内部运维能力。

试点成功的标准不只是“数据导入成功”。还要观察成员能否完成日常计划、需求是否可追溯、权限是否正确、管理报表口径是否一致，以及新系统是否增加了重复录入。若原有流程本身混乱，直接迁移只会把混乱复制到新平台。

七、不同情况下的取舍：Scrum 没有脱离约束的标准答案

1. 稳定团队与灵活共享：专注度和资源利用率之间的取舍

稳定团队有利于共同建立产品知识、降低交接成本和持续改善；共享成员模式在专业人员稀缺、工作量短期波动时可能更灵活。代价是上下文切换和计划不确定性更高。若组织选择共享模式，就应接受预测范围变宽，不要同时要求固定团队般的承诺稳定性。

是否值得形成稳定团队，可以比较切换频率、等待时间、返工率和交付周期，而不是只看成员利用率。资源利用率接近百分之百，往往意味着一旦出现变化就没有缓冲，未必带来更快的价值交付。

2. 两周 Sprint 与更短周期：反馈速度和仪式成本之间的取舍

更短的 Sprint 可让团队更快检查方向，但规划、评审和回顾也更频繁；更长的 Sprint 能容纳复杂工作，却可能延迟问题暴露。Scrum Guide 允许一个月或更短的 Sprint，团队应根据反馈周期、集成能力和工作切分方式选择，而不是把“两周”当成唯一正确答案。

如果团队每个 Sprint 都无法形成可用增量，先检查工作切片、测试集成和依赖，不要单纯延长 Sprint 以掩盖流程问题。只有当工作确实需要更长验证周期，且团队能保持中途透明检查时，较长周期才可能合理。

3. 细化估算与粗粒度规划：预测精度和维护成本之间的取舍

细致估算可帮助识别工作量差异，但估算本身需要投入，且需求不确定时精确数字容易产生虚假确定感。粗粒度规划更适合早期探索或高不确定需求，但需要更频繁地根据实际交付更新预测。

我的建议是把估算用于团队规划和风险讨论，而不是把估算精度当作管理成熟度。若团队在估算上花费大量时间，却无法因估算结果改变排序、切分或容量安排，就应降低估算粒度。

4. 自建工具与专业平台：控制力和维护负担之间的取舍

自建看板初期成本低、灵活，但当团队增多后，权限、审计、流程变更、跨项目报告和数据一致性可能逐渐变成隐性运维成本。专业平台能够集中配置工作流、关系和权限，也会带来采购、培训、迁移和平台治理成本。

选型时先写业务需求和约束，再做试点比较。可以将需求分为必需、重要和可选，评估迁移难度、数据安全、集成、使用负担和总体拥有成本。工具“功能更多”不等于组织“更敏捷”，能否减少信息断层和重复维护才是关键。

八、落地清单：把制度变成下一个 Sprint 能执行的动作

1. Sprint 开始前：确认目标、容量和决策人

开始前，团队先确认 Product Backlog 是否足够清晰、优先级由谁决定、成员可用容量是多少、已知依赖和支持工作有哪些。Sprint Planning 中共同形成 Sprint Goal，并根据容量选择工作；如果关键成员缺席或依赖未确认，应明确计划风险，而不是用乐观承诺填满工作量。

规划会议的结果要让团队成员能够回答：为什么这个 Sprint 值得做？我们要形成什么增量？遇到变化时如何协商？答案含糊，通常意味着团队还没有在目标上达成共识。

2. Sprint 进行中：检查目标，而非逐人点名报数

Daily Scrum 由 Developers 组织，围绕 Sprint Goal 检查进展并调整当天计划。若某项工作受阻，应明确需要谁协助、何时解决、是否影响目标。管理者可以参加了解情况，但不宜把它变成对个人承诺的逐项审问。

新需求按约定入口处理。团队与 Product Owner 协商是否调整 Sprint Backlog，必要时说明对目标、容量和其他工作造成的影响。对于真正影响产品价值或安全的紧急情况，优先透明处理，而不是为了维护计划表而隐瞒现实。

3. Sprint 结束时：评审增量，再回顾团队系统

Sprint Review 重点是检查增量、讨论产品目标进展、收集利益相关者反馈，并据此调整后续工作。演示幻灯片可以辅助解释，但不能替代可检查的产品增量。若增量不可用，要坦诚说明未满足的条件及下一步处理方式。

Sprint Retrospective 则聚焦团队的协作、工具、流程和质量实践。每次选择一到两项可验证的改进实验，明确负责人、检查时点和预期信号。不要一次列出十几项行动，却没有资源或时间执行。

4. 每月或每季度：检查制度是否仍匹配业务现实

团队制度不是一次写完就永久有效。产品目标变化、团队规模增长、支持负担上升或合规要求改变时，都应重新检查角色授权、容量模型、依赖处理和工具配置。规则若已与现实不符，成员会绕过规则，系统也就失去可信度。

组织可以定期回看计划外工作占比、交付周期、目标完成情况、缺陷趋势和用户反馈，但应避免把不同团队的数字直接排名。指标只有在定义一致、背景透明、用途明确时才有解释力。

九、结语：Scrum 全流程的关键，是让冲突在制度里被看见

Scrum 不是把传统项目管理的职位换个名称，也不是把需求拆进 Sprint 后就自动获得敏捷能力。它要求团队围绕产品目标持续检查与调整，而这依赖清楚的责任边界、真实的成员容量、可执行的完成标准和可信的反馈入口。

我最看重的判断标准是：当需求冲突、成员缺席、线上故障或依赖延迟发生时，团队是否知道由谁决策、如何评估影响、怎样更新计划。若每次都要临时找人拍板，制度还没有真正建立；若变化能够透明进入系统，团队才有可能在不掩盖风险的情况下保持灵活。

下一步可以从一个团队、一个 Sprint 开始：确认三类责任人，记录真实容量，约定插单入口，定义 Definition of Done，并在 Sprint Review 与 Retrospective 后检查实际结果。先解决最影响目标的一个制度缺口，再扩展到更多团队和工具。流程的成熟，不在于规则有多复杂，而在于团队遇到变化时，仍能做出清楚、及时、可追溯的决定。