敏捷项目Scrum全流程：跨部门团队落地方案与一文讲清

Scrum落地最常见的失败，不是团队不会开每日站会，而是一个跨部门需求在产品、研发、测试、运营之间传递时，没人能对“何时算完成”给出同一个答案。比如，业务部门认为功能已开发就能发布，测试认为还缺回归，运维则尚未确认监控和回滚方案。结果是看板上的任务不断变绿，真正可交付的增量却迟迟出不来。我的核心判断是：跨部门Scrum不是把会议排进日历，而是把决策权、依赖关系和完成标准放进同一套短周期反馈机制。

一、先讲核心结论：Scrum的落地点是可交付增量，不是会议数量

1. 一个团队要对同一个结果负责

Scrum通常由产品负责人、Scrum Master和开发团队构成。跨部门场景中，“开发团队”不是只指写代码的人，而是为产品增量完成所需的多技能成员：研发、测试、设计、数据、安全、运维或业务专家，都可能需要进入同一个交付协作单元。

关键不在组织架构上是否把这些人调到同一部门，而在于他们能否围绕一个产品目标共同规划、共同检查、共同承担结果。如果每个职能仍各自接单、各自排期，团队只是把多个部门的待办放进同一块看板，Scrum的短周期反馈就会被职能交接抵消。

2. 先压缩依赖，再讨论提速

我会先检查一项需求从提出到上线，经过多少次“等别人”。跨部门交付的核心成本经常不在编码本身，而在需求澄清、环境准备、审批、安全评审、数据校验和发布窗口之间的等待。若团队把迭代周期从四周缩短到两周，却没有减少这些等待，通常只会把延期暴露得更频繁，不会自动加快交付。

因此，落地顺序应是先定义产品目标和完成标准，再梳理关键依赖，随后建立迭代节奏，最后用数据持续调整。不要先买工具、先开会，再期待协作方式自然改变。

3. 用少量指标检验机制，而不是用忙碌感证明成功

Scrum是否有效，不能只看每日站会是否按时结束、迭代计划是否写满。至少要同时看交付结果、流动效率和质量风险。例如，迭代目标完成率、需求从开始到交付的周期、返工占比、生产缺陷数、阻塞项持续时间，分别回答“有没有交付”“交付是否变快”“是否靠牺牲质量换速度”。

下面的数字是用于讨论机制的情景模拟，不是行业统计，也不代表某家企业的实际表现。它展示的是一个团队在引入依赖管理和完成标准后，可能需要观察的指标结构。

二、背景和真实场景：跨部门交付为什么容易卡在边界上

1. 部门目标不同，需求却被当成一个整体承诺

一个常见场景是：业务部门承诺活动日期，产品部门确认需求范围，研发部门按技术依赖拆分任务，测试部门等待版本稳定后集中验证，运维部门则要求发布前完成风险评估。每个部门都在完成自己的工作，但没有人能单独控制从需求到上线的整条链路。

这时，管理者常看到局部进度“都差不多完成”，实际发布却仍需等待。问题不是某个职能不配合，而是组织把一条端到端的交付链拆成了多个局部队列。只要关键资源同时服务多个产品，队列之间就会发生优先级竞争。

2. “跨部门团队”不等于人员全职归属同一小组

现实中，安全、数据治理、法务、基础设施等岗位未必能全职加入一个Scrum团队。强行要求所有专家全程驻场，可能造成资源浪费；但只让专家在最后一天审批，又会把风险推迟到最昂贵的阶段。

更实用的办法是区分稳定团队成员与按需参与者。稳定成员负责迭代内连续协作；按需参与者在需求澄清、方案评审、风险检查或验收等明确节点提供服务。重点是把参与时点、响应时间、输入材料和决策权限写清，而不是在组织图上把所有人画进一个框。

3. 最容易被忽视的是跨团队依赖的等待时间

在迭代计划会上，团队往往能说出任务还需要几天，却说不清任务要等待几天。前者容易进入估算，后者常被藏在“外部依赖”“待确认”或“对方处理中”等状态里。若不记录阻塞开始和解除时间，就无法判断交付慢是工作量估计偏差，还是资源、决策或环境的排队问题。

我建议给阻塞项加上责任人、所需决策、最晚响应时间和升级路径。阻塞并不意味着某个部门“做错了”，它是对系统瓶颈的观测信号。团队要优化的是解决问题的路径，而不是把阻塞状态改成更好看的颜色。

三、常见误区：把Scrum做成流程仪式，反而掩盖了交付问题

1. 误区：每日站会就是向经理汇报进度

每日Scrum的目的，是让团队检查朝迭代目标前进的情况，并调整接下来一天的工作。若每个人逐条汇报“昨天做了什么、今天做什么、有什么问题”，而讨论对象始终是经理，会议就容易变成状态收集。

当问题需要深入讨论时，不必让全员等待。团队可以在站会后由相关成员继续解决，其他人回到工作。站会要留下的是对目标、风险和协作安排的共同理解，而不是一份更口语化的日报。

2. 误区：把迭代计划排满，等于承诺更可靠

如果团队把每个人的可用工时全部换算成任务，再将任务塞满迭代，计划看起来很精确，实际上没有给评审、缺陷处理、突发支持和跨部门响应留下空间。尤其是共享测试或运维人员，常常同时承担多个团队的工作，纸面上的“可用时间”并不等于实际可投入时间。

计划时应先明确迭代目标，再根据历史完成情况和当前可用能力选择工作。若团队没有稳定历史数据，可以先用一到两个迭代建立基线，不必急着用复杂公式预测。计划的价值在于让团队作出可解释的选择，而不是把未来的不确定性包装成精确数字。

3. 误区：故事点可以直接比较团队效率

故事点是团队内部讨论相对规模和不确定性的手段，不是跨团队统一的生产率单位。A团队每个迭代完成40点，不代表一定比完成25点的B团队效率高，因为估算尺度、工作类型、质量门槛和依赖条件都可能不同。

若管理层把故事点用于排名，团队就会有动机提高估算、拆分任务或挑选更容易完成的工作。更稳妥的做法是观察单个团队自身的趋势，并结合周期、缺陷和目标结果分析。跨团队比较时，应比较交付边界和业务结果，而不是比较一个人为定义的估算数字。

4. 误区：所有需求都要在迭代开始前完全写清

Scrum不是要求团队在开始工作之前消灭所有不确定性。对于需要探索的需求，团队可以先安排原型、用户访谈、技术验证或数据分析，把未知转化为更好的决策依据。真正需要避免的是把“还不清楚”伪装成“已准备好”，随后在迭代中反复改变目标。

如果核心假设尚未验证，先做小规模发现工作通常比直接承诺完整功能更合适。若需求边界已足够明确，则应尽量把工作切成可在短周期内验证的增量。两类工作需要不同的验收方式，不能用一套“完成百分比”强行衡量。

5. 误区：工具上线后，协作问题就会自动消失

工具能让任务、依赖、变更和决策留痕，却不能替团队决定谁有权调整优先级，也不能让一个没有响应机制的外部依赖自动变快。看板越精细，若状态定义不一致，反而可能增加维护负担。

选择系统时，我会先问三个问题：团队是否有统一的工作项层级？跨团队依赖能否被识别和追踪？管理者能否看到真实流动而不是手工拼出的状态汇总？如果这些问题没有答案，先做工作规则试点，往往比先配置复杂流程更有效。

四、专业判断逻辑：先确认适用边界，再设计Scrum机制

1. 判断工作是否适合以Scrum迭代推进

Scrum更适合目标可以逐步验证、工作需要跨技能协作、需求存在一定变化、团队能较频繁检查成果的场景。若工作主要是高频、不可预测的服务请求，任务到达后必须立即处理，持续流动的看板方式可能比固定迭代承诺更贴合。

如果交付受监管审批、硬件采购或长周期外部依赖约束，仍可以使用迭代，但必须把这些约束纳入规划。不能因为团队采用Scrum，就假设审批、合同和供应链周期也会同步变短。方法要服务于工作特征，而非让所有工作迁就方法。

2. 判断团队是否具备端到端交付能力

每个迭代目标都应能指向一个可验证的用户或业务结果。若团队只能完成“接口开发”，却无法测试、部署或获得业务验收，那么它承担的只是交付链的一段，不是端到端产品增量。此时可以通过补足技能、建立稳定服务约定或缩小目标范围改善，不必一开始就做大规模组织重组。

我会把依赖分为三类：信息依赖、资源依赖和决策依赖。信息依赖可通过提前澄清和文档模板降低；资源依赖要确认容量与排期；决策依赖则要明确决策人和时限。不同依赖用不同办法处理，把它们统称为“沟通问题”会失去诊断价值。

3. 判断交付承诺是否可信

可信承诺不等于每次都按原计划完成，而是团队清楚说明目标、范围、主要风险和调整规则。迭代中出现新信息时，产品负责人和团队可以讨论如何调整范围，但不应默默扩大工作量，同时保留原目标和原日期不变。

在复盘中，我会区分三种偏差：估算偏差、范围变化和外部等待。估算偏差说明团队对工作量或不确定性的判断需要校准；范围变化说明优先级或需求治理需要改进；外部等待说明系统依赖需要处理。把三种偏差混在一起，只会让复盘变成追责。

4. 判断指标是否会诱发错误行为

任何指标被用于考核后，都可能改变团队行为。以完成任务数为目标，团队可能把工作拆得更碎；以零缺陷为目标，团队可能少报缺陷；以准时率为唯一目标，团队可能拒绝有价值的变更。

因此，指标最好成组使用，并明确它们的解释边界。例如，交付周期要结合工作类型与等待原因，缺陷数要结合发布量和严重程度，目标完成率要结合目标是否在迭代中被变更。指标提供调查线索，不应直接充当绩效结论。

五、Scrum全流程：从产品目标到迭代复盘逐步落地

1. 定义产品目标和责任边界

先用一句话说明产品或项目要改善什么，而不是先列一串功能。例如，“减少客户提交资料后等待审核的时间”比“增加资料上传、提醒和审核列表”更能指导团队取舍。目标应有观察方式，但不必一开始就假装知道所有实现细节。

随后明确产品负责人对价值排序的责任、Scrum Master对团队有效协作的支持责任，以及团队对完成增量的共同责任。跨部门专家的参与方式也要写清：谁负责提供业务规则，谁批准风险，谁确认验收，谁对发布窗口作决定。

2. 建立产品待办列表并持续细化

产品待办列表不是所有人的愿望清单，而是按价值、风险和依赖排序的工作集合。每个条目至少应能回答：服务什么用户或业务场景、希望改变什么、如何判断结果、有哪些已知依赖。

细化不等于把每个需求写成厚重规格。团队可以通过示例、流程图、原型、数据样本和验收条件减少关键歧义。对于仍有未知的条目，明确未知是什么、用什么实验验证、何时决定继续或停止，比填写一份形式完整但无法验证的需求文档更有用。

3. 计划迭代：目标先于任务清单

迭代计划应先讨论迭代目标，再选择能够支持目标的待办工作，最后拆解实现路径。跨部门团队还要检查依赖是否具备：测试环境可用吗？数据权限申请了吗？安全评审是否需要提前预约？业务验收人是否有时间？

把“预计需要谁支持、何时支持、输入是什么”写在计划中。若依赖尚未确认，可以选择较小的验证任务，或明确它是风险而不是既定承诺。计划会的产出不是一张塞满任务的表，而是团队对目标和现实约束的共同理解。

4. 迭代执行：围绕目标调整，不围绕状态表演

执行期间，团队每天检查是否需要调整协作。遇到阻塞时，先确认问题类型、责任人和下一步行动；如果问题跨越团队权限，再按约定升级。Scrum Master可以协助清除组织障碍，但不应成为所有问题的唯一转发站。

当新需求进入时，产品负责人和团队要判断它是否影响当前迭代目标。若确实需要调整，应明确交换了什么范围、风险如何变化；若只是把新任务塞进来而不移除旧工作，计划就失去解释力。稳定目标不等于拒绝变化，而是让变化的代价可见。

5. 迭代评审：检查增量和下一步选择

评审不是团队向管理层汇报工作量，而是让相关干系人检查实际增量、业务反馈和未解决问题。演示应尽可能基于可运行的产品或真实数据，不要只展示静态页面或幻灯片来暗示功能已经完成。

参与者应讨论：目标是否得到支持？用户反馈是否改变优先级？哪些假设需要验证？哪些依赖影响下一步？评审形成的信息要回到产品待办列表，经过产品负责人排序，而不是直接成为所有人的即时任务。

6. 迭代回顾：选择一个系统问题做可验证改进

回顾的重点是团队如何工作，而不是给个人打分。可以从“哪些做法帮助我们交付”“哪些环节增加等待或返工”“下个迭代尝试什么改变”入手。每次最好选一到两项具体行动，指定负责人、观察窗口和判断方式。

例如，团队发现测试环境平均要等待两天，可以尝试在迭代开始前完成环境检查，并记录等待时长变化。与“加强沟通”相比，这项行动更容易验证，也更容易在无效时调整。

7. 完成定义：把“做完”变成共同可检查的条件

跨部门团队最需要共同维护的，是完成定义。它应说明一个增量达到什么条件才可以被视为完成，例如代码审查、必要测试、权限与安全检查、文档更新、监控准备、业务验收和发布状态。并非每项工作都需要同样复杂的条件，但差异必须透明。

如果某项工作由于外部原因不能满足完成定义，应如实标记为未完成或部分完成，并说明剩余风险。不要为了让迭代报表更好看，把“开发完成”重新定义成“交付完成”。这种口径短期能改善数字，长期会让管理层失去判断实际发布能力的依据。

六、案例与数据观察：用一个模拟项目看清卡点和改进路径

1. 场景设定：客户资料审核流程改造

以下是用于说明方法的模拟案例，不对应特定企业或真实项目。某服务团队准备改造客户资料提交与审核流程，参与角色包括产品、前后端研发、测试、运营、数据和安全。业务希望缩短客户提交后的等待时间，同时不能降低审核准确性。

第一轮计划包含资料上传、审核列表、提醒规则和数据看板。团队很快发现，关键瓶颈并非开发任务数量，而是审核规则由业务确认、数据字段需安全评估、测试环境依赖其他系统。几项工作各自看似不大，却让后续验证无法连续进行。

2. 第一轮诊断：把交付周期拆成工作与等待

为了避免凭印象归因，团队对需求从开始到可验收的时间做了示意性拆分。模拟观察显示，直接制作和验证占周期的一部分，等待业务规则、环境准备和审批也占了相当比例。这里的数值只用于演示诊断方法，真实项目应从工作流系统或人工抽样中取得。

3. 采取行动：提前约定输入、决策人和反馈时限

团队没有把所有需求都拆得更小了事，而是做了三项针对性调整。第一，业务规则在计划前由指定负责人确认；第二，环境和数据访问在迭代开始前检查；第三，安全与运营代表在需求细化时参与风险识别，而非等到发布前才审查。

同时，团队将原本较大的功能目标拆成两个可验证增量：先验证资料提交和审核状态流转，再验证自动提醒与运营分析。这样做不是为了追求更小的任务颗粒，而是为了尽早获得关于业务流程和数据条件的反馈。

4. 复盘观察：不要把变化全部归功于Scrum

下面的对比仍为情景模拟，展示团队可以如何观察变化。若真实项目看到交付周期降低，不能直接断言是某次会议或某款工具带来的效果；还要检查需求难度、发布范围、人员投入和外部政策是否发生变化。

5. 形成可复用的观察口径

在真实团队里，我会建议先连续记录数个迭代，再讨论趋势。样本少时，一个复杂需求就可能显著改变平均值，可以同时看中位数和分布，并把工作类型分层。交付周期最好明确起点和终点，例如从“团队开始处理”到“达到完成定义”，避免不同部门各用一套口径。

此外，指标需要配合事件记录：需求何时进入、何时开始、何时阻塞、何时解除、何时验收。没有这些节点，团队只能看到周期变长，却不知道应该改需求准备、资源排期还是审批路径。

七、不同条件下的行动建议：先做多大、从哪里开始

1. 小团队、单一产品线：从一个完整交付切片试点

若团队规模较小、干系人有限，可以先选一个有代表性的产品目标，运行两到三个迭代。不要同时改组织架构、考核方式、工具和发布制度。一次改太多，结果变好或变差时都难以判断原因。

优先确认产品负责人是否有排序权、团队是否能获得必要的测试和业务反馈、完成定义是否可执行。试点结束后，回看目标完成、周期、缺陷和阻塞，决定继续、调整还是换一种工作模式。

2. 多团队、共享职能：先治理依赖接口

当多个团队共用测试、安全、数据或平台资源时，单个团队的迭代节奏可能受共享队列牵制。此时要为共享服务建立明确的请求入口、优先级规则、容量预留和响应预期，并让依赖进入计划视野。

不要把共享专家无限拆分到所有团队里，却不给他们处理工作的连续时间。某些岗位适合定期参加细化和评审，某些工作则适合集中服务队列。选择哪种模式，取决于工作的紧急程度、上下文切换成本和风险要求。

3. 强监管或高风险产品：迭代开发不等于削弱控制

金融、医疗、公共服务或涉及敏感数据的项目，可能有审计、权限、留痕、风险评估和审批要求。Scrum可以让团队更早暴露风险，但不能替代法规、合同和组织控制。应把必要的验证纳入完成定义，并尽量将证据生成嵌入日常工作。

如果某类审批必须由独立职能做出，团队应提早预约并提供一致材料，减少迭代末端集中排队。对高风险变更，可以采用分阶段验证、灰度发布或回滚演练；这些措施的具体适用性要由组织的风险规则决定。

4. 维护与突发工作较多：不要假装容量稳定

若团队经常被生产支持、客户升级或故障响应打断，可先分析突发工作占比和到达规律。若这类工作持续且不可预测，固定迭代承诺可能不是最合适的唯一机制；可以让计划保留明确缓冲，或让维护工作采用持续流动、产品改进保持迭代节奏。

关键是把突发工作记录下来，而不是把它藏在“其他事项”中。若不记录，团队会反复被指责承诺不足；若记录后发现主要问题是重复故障，则应把部分容量用于消除根因，而非永久接受救火作为常态。

5. 工具选型：先定协作模型，再验证系统边界

工具要支持工作流透明、角色协作、依赖追踪和数据回看，不应把团队锁进与实际流程不符的字段和审批。评估时建议用真实项目做小范围演练：建立待办、跨团队关联、迭代计划、评审记录和指标报表，再观察成员是否能低成本维护信息。

如果组织规模超过百人，且涉及多团队协作、权限治理或本地化部署，工具评估还应关注组织级配置、数据隔离、审计、迁移和后续运维能力。以PingCode为例，若企业在评估其能力，可重点核验其产品材料和合同中关于私有化部署、Jira迁移支持及规模适配的具体范围；迁移是否平滑，仍需通过字段映射、历史数据抽样、权限验证和试迁移来确认。任何平台都不能仅凭功能清单就被视为“国产替代”的不二选择，最终应以安全要求、总拥有成本、团队使用体验和退出方案综合判断。

工具试点不宜只由管理员参与。至少让产品负责人、研发、测试和一个外部依赖方完成一轮真实协作，检查状态是否容易理解、数据能否支撑复盘、权限是否符合要求。若团队必须花大量时间维护看板，说明配置或工作规则可能过重。

八、不同情况下的取舍：敏捷不是把所有事情都做得更快

1. 迭代稳定性与需求灵活性之间的取舍

迭代目标需要一定稳定性，但业务环境也可能发生变化。若变化影响法规、重大客户承诺或核心风险，团队应及时重新评估目标；若只是新增一个“顺手做”的需求，则应进入待办排序，避免每次有人提出想法就打断当前工作。

更好的做法不是绝对禁止变更，而是要求变更有明确理由、责任人和影响说明。团队可讨论替换哪些工作、是否改变发布日期、质量风险是否增加。取舍一旦显式化，管理者就能做真实决策，而不是把额外工作隐形转嫁给执行团队。

2. 跨职能稳定团队与专家共享之间的取舍

把关键职能固定在团队中，通常能减少上下文切换和排队，但会降低专家在组织中的共享弹性；让专家服务多个团队，资源利用可能更灵活，却容易造成响应延迟和任务频繁切换。

可以依据工作连续性和风险程度决定：持续参与且经常影响迭代目标的职责，更适合纳入稳定团队；低频但必须独立把关的职责，可以采用明确服务约定。不要追求组织结构上的“全员嵌入”，而应追求关键工作在需要时可获得且责任清晰。

3. 自动化与人工判断之间的取舍

测试、部署、质量检查和报告中的重复工作，通常适合逐步自动化。但涉及业务例外、风险接受、法律解释和复杂用户体验的判断，不能因为系统可以设规则就全部机械化。

自动化也有维护成本。团队应优先自动化频率高、规则相对稳定、错误代价明确的步骤，并记录自动化失败后的处理方式。若一项自动化长期需要人工绕行，问题可能不是成员不够自律，而是规则设计或系统边界不合适。

4. 流程一致性与团队自治之间的取舍

大组织需要统一的基础口径，例如工作状态、完成定义的底线、风险记录和审计字段；但不同产品的探索方式、发布节奏和依赖结构可能不同，完全一致的流程会降低适配能力。

我倾向于把标准分为不可妥协的控制要求和团队可调整的工作约定。安全、隐私、审计等要求由组织明确；迭代长度、细化方式、会议形式和指标组合，则可在共同原则下因团队而异。统一底线，不统一所有细节，通常比一套流程覆盖所有团队更可持续。

九、落地计划：用三十天建立第一版运行机制

1. 第一周：诊断当前交付链，不急着重画组织图

选一条真实需求，记录从提出到交付经过的步骤、参与角色、等待节点和返工原因。分别访谈业务、产品、研发、测试和运营人员，核对同一项工作是否存在不同的完成口径。此阶段的目标是找到系统瓶颈，不是先判断哪个部门效率低。

同时选定一个小而真实的试点范围，确认产品负责人和团队成员有足够时间参与。若关键人员只能偶尔出现，先解决参与方式和服务约定，再开始承诺固定迭代目标。

2. 第二周：定义目标、工作项和完成标准

将试点目标写成可验证的结果，整理一组有序待办，并为近期条目补上验收条件和依赖信息。制定简洁的完成定义，确保开发、测试、业务验收和必要风险检查都能理解并执行。

不要为了“流程完整”一次设计所有状态、字段和报表。每一个新增字段都应能回答：谁需要它、在什么决策中使用、由谁维护。没有明确用途的信息，先不要求团队录入。

3. 第三周：运行一个完整迭代，记录偏差而非掩盖偏差

按团队实际情况选择合理的迭代长度，进行计划、每日检查、评审和回顾。每天关注目标和阻塞，重要问题在合适的小组中解决。出现计划外工作时记录其来源和影响，不要把它们悄悄塞进原承诺。

工具可以先用现有系统或轻量看板。关键是让工作状态、依赖和完成条件真实可见。若成员不断争论状态该填什么，优先修订工作规则，而不是立刻增加更多状态。

4. 第四周：评估结果，选择下一轮实验

回顾目标完成情况、交付周期、阻塞时间、缺陷和范围变化。把每项变化解释为初步观察，而不是因果结论。团队可以选择一个最影响交付的问题，提出下一轮可验证改进，例如提前确认业务规则、固定环境检查时点或调整共享专家的响应机制。

一个月后，不必急于宣布“全面成功”或“方法不适用”。更值得回答的是：目标是否更清楚？工作是否更早暴露风险？跨部门等待是否可见？完成定义是否真实？这些问题有明确答案后，再决定扩大范围、修改机制或转向其他工作模式。

1. 选定一条端到端产品交付链，避免一开始覆盖整个组织。
2. 明确目标、优先级责任、团队成员和外部参与者的决策边界。
3. 记录工作开始、阻塞、解除和验收等关键时间点。
4. 采用适合团队的迭代节奏，完成至少一次评审与回顾。
5. 根据数据和反馈选择一项改进，观察其效果后再扩大实施。

十、结语：Scrum真正改变的是组织面对不确定性的方式

跨部门Scrum最有价值的地方，不是让所有工作看起来更整齐，而是让目标、依赖、风险和取舍尽早变得可讨论。它不保证每个迭代都按原计划完成，却能帮助团队更早知道什么在阻碍交付、哪些假设需要验证、哪些承诺必须重新协商。

我的独特判断是：评价Scrum落地，不要先问“会议是否规范”，先问“一个可交付增量是否能在团队内部完成验证，外部依赖是否有明确的响应机制，失败或延误是否能转化成下一轮改进”。这三个问题若没有答案，再完整的流程图也只是装饰。

下一步可以从一条真实需求开始：画出它从提出到上线的路径，标出等待和决策节点；选定一个小团队，建立可执行的完成定义；再用数个迭代观察目标完成、交付周期、阻塞和质量变化。先把一个端到端切片做实，再决定是否扩大范围。对于工具、组织结构和指标，始终以它们是否帮助团队更快获得可靠反馈作为取舍标准。