Agile怎么做？实施团队协同管理：敏捷项目从0到1

Agile怎么做，真正的难点通常不是把工作拆成两周一个迭代，而是让需求、开发、测试、产品和业务在变化发生时仍能对齐。一个常见的反常识是：团队开了更多站会、建了更多看板，交付却未必更快；如果决策权、验收标准和跨团队依赖没有改变，敏捷仪式只会让原有流程更频繁地暴露出来。本文从团队协同管理出发，拆解敏捷项目从0到1的落地方法，并给出适用边界、验证指标和工具选择思路。

一、先讲核心结论：敏捷不是“快点做”，而是缩短验证和纠偏周期

1. 先定义敏捷项目要改善什么

我判断一项敏捷转型是否值得做，不先问团队有没有每日站会，而先问三个问题：用户价值多久能被验证一次？问题出现后，团队多久能调整？当前最主要的等待发生在哪里？如果这些问题没有答案，直接照搬某套敏捷仪式，大概率只是换了管理术语。

敏捷项目的目标不是把计划变得不重要，而是把计划从一次性承诺改成持续更新的预测。团队仍要有目标、预算、里程碑和风险控制，只是不再假设项目开始时就能准确知道所有需求、依赖和实现成本。计划需要依据新证据调整，而不是为了维护最初承诺而隐藏偏差。

2. 把交付闭环作为最小落地单元

我建议从一个可以完整交付的小范围开始：明确一类用户问题，选定一个跨职能小团队，约定一组验收条件，在短周期内完成设计、开发、测试和反馈。这个闭环要足够小，小到团队能看清工作流；也要足够真实，不能只做演示页面，却把发布、数据、安全和业务验收全部留给后续。

敏捷的最小单元不是一次迭代会议，而是一个从需求假设到用户反馈的完整闭环。闭环完成之后，团队才有证据判断需求是否成立、流程是否卡顿、质量门槛是否可接受。没有闭环的“速度提升”，常常只是把待办事项更快地搬到下一个阶段。

3. 先看流动效率，再看个人忙碌程度

项目管理中很容易把“每个人都很忙”误认为“项目推进很快”。我更关注需求从进入待办到上线用了多久、工作在各环节等待多久、一个迭代里有多少事项真正完成，以及上线后产生多少返工。团队可以每天都有产出，但如果工作大量堆积在评审、测试或跨团队等待环节，整体交付仍然缓慢。

下面的数据是用于团队启动讨论的情景模拟，不是行业统计或任何产品的实测效果。它展示的是常见的管理目标：先识别等待时间，再讨论怎样减少等待，而不是简单要求开发人员提高个人产量。

二、背景和真实场景：为什么团队“上了敏捷”仍然不协同

1. 敏捷项目面对的是不断变化的约束

从0到1的项目通常有一个共同特征：需求尚未完全稳定，但交付日期、预算或合规要求已经存在。业务希望尽早验证市场，研发需要时间评估架构，测试需要稳定环境，管理层又希望看到可靠的进度。这些要求并不必然冲突，冲突往往来自各角色使用不同的进度定义。

业务把“功能做出来”当成完成，开发把“代码合并”当成完成，测试把“测试通过”当成完成，而运营关心的是用户能否使用、数据是否可观测、出问题后能否回滚。若项目没有统一的完成定义，各方都可能说自己按期完成，但用户仍然拿不到可用结果。

2. 协同问题往往藏在交接和等待里

我在做项目流程诊断时，常见到这样的链条：产品经理先写一份较长需求文档，评审会上开发提出问题，问题会后由产品逐一确认；开发完成后才通知测试，测试发现环境或数据准备不足；临近上线才发现业务验收标准与最初理解不同。每个角色都完成了自己的职责，但项目的端到端周期被交接切碎。

这种场景不能简单归因于“沟通不够”。增加会议可能让等待更显眼，却不一定消除等待。真正需要检查的是：问题由谁拍板？需求进入开发前要具备哪些信息？测试能否提前参与？依赖方是否有明确响应时间？上线决策是否有共同标准？这些机制决定了协同是否可持续。

3. 规模扩大后，局部敏捷容易变成全局拥堵

十几人的团队可以通过面对面沟通快速解决许多问题；当组织扩展到多个产品线、多个研发团队和共享职能时，同一套做法未必还能奏效。团队各自排满迭代，不代表组织整体交付更快。如果多个团队争用同一位架构师、测试环境或安全评审资源，局部计划越确定，全局冲突可能越早暴露。

因此，100人以上组织需要同时处理团队内流程和团队间依赖。管理重点不再只是“每个团队有没有待办列表”，还包括需求优先级如何跨团队统一、共享资源如何排队、接口变化如何通知、重大风险如何升级。工具可以提供透明度，但不能代替这些决策规则。

4. 从可验证的项目切入，而不是全组织一次性换流程

初次实施时，我倾向于选择一个业务价值清晰、负责人可投入、依赖数量可控的项目作为试点。试点最好包含真实用户反馈和真实交付约束，但不要一开始就挑选跨部门最多、法规风险最高、核心系统改造最深的项目。试点的首要价值是验证工作机制，而不是证明某种方法“放之四海而皆准”。

在启动前记录当前的周期、延期原因、需求变更、缺陷和等待情况。没有基线，试点结束后团队很容易只记得会议变少或看板变整齐，却说不清交付是否改善。基线不必复杂，关键是口径固定、团队能复算。

三、常见误区：哪些做法看起来敏捷，实际会增加管理噪声

1. 把每日站会开成逐人汇报

站会的价值是让团队尽早发现阻塞并协调当天工作，不是让每个人轮流向管理者证明自己很忙。如果参与者依次汇报昨天做了什么、今天做什么，却没有讨论工作项之间的依赖和风险，那么会议即使控制在十五分钟内，也只是缩短了形式上的汇报时间。

有效的站会应围绕共同目标和工作流展开。团队可以先看迭代目标与在制工作，再讨论哪些事项卡住、谁需要协助、是否有新信息要求重新安排优先级。若涉及复杂讨论，先记录负责人和后续沟通时间，让站会回到协调而非现场解决所有问题。

2. 把敏捷理解成“不要计划”

敏捷不是取消计划，而是区分承诺、预测和假设。承诺通常涉及团队能够控制的近期目标；预测是基于历史吞吐量和当前工作范围的估算；假设则是尚待验证的判断。把三者混为一谈，团队会把早期估算包装成确定日期，随后通过加班掩盖不确定性。

我通常建议对外提供范围、日期和风险之间的取舍，而不是只给一个看似精确的点日期。例如，固定发布日期时，团队应说明哪些范围可以调整；固定范围时，应说明依赖和不确定性会怎样影响日期。透明地表达边界，比承诺一个无法控制的精确结果更专业。

3. 把迭代完成率当作团队绩效

完成率可以帮助回顾计划质量，但不适合作为个人或团队排名。若团队为了提高完成率而拆小任务、把未完成事项挪出迭代，数字会变好，用户价值却未必增加。更严重的是，团队可能开始避免承担不确定性较高但价值重要的工作。

完成率应该与范围变化、工作项大小、缺陷、交付周期和迭代目标一起看。若计划经常落空，先查工作是否过大、容量是否被临时支持打断、外部依赖是否被低估，而不是直接把问题归为“执行力不够”。

4. 把看板上的状态列当成流程改造

把任务状态从“未开始、进行中、已完成”改成更多列，不等于工作流更可控。列太少，阻塞原因不清楚；列太多，团队需要花时间维护状态，却仍然看不见真正的等待。状态应该反映团队实际的工作步骤和决策节点，而不是照抄模板。

我的判断方法是：每增加一个状态，都要能回答“进入这个状态的条件是什么、谁负责推进、离开它需要什么证据”。如果团队说不清这些问题，先合并状态，再通过阻塞标签或等待原因记录补充信息。

5. 把购买工具当作敏捷转型本身

工具解决的是可见性、追踪和协作信息的保存问题，不会自动替团队确定优先级，也不能代替产品决策、质量标准和组织授权。先买工具再补流程，容易把旧流程的审批层级和等待搬进新系统，最后得到一块更数字化的瀑布式看板。

在工具选型之前，至少要明确试点使用哪些工作项、状态流转规则、权限边界、报表口径和迁移范围。若这些内容仍处于争论中，先做小范围流程设计和验证，通常比一次性配置大量字段更省成本。

四、专业判断逻辑：把敏捷实施拆成五个可检验环节

1. 先选业务问题，再选方法

“我们要推敏捷”不是足够具体的目标。可以把问题改写成可检验的表达，例如：高优先级需求从确认到可用平均需要十周，其中等待评审和测试环境占了大部分时间；或每次版本交付后都出现大量验收返工。目标写清楚后，团队才能判断应该改善需求澄清、测试前移、发布自动化，还是跨团队依赖。

目标应当同时包含结果和约束。结果可以是缩短需求交付周期、降低缺陷逃逸率或提高用户验证频率；约束可能包括不降低安全检查、不突破预算、不改变法定审批要求。只有结果没有约束，团队可能用牺牲质量换速度；只有约束没有结果，敏捷实施会退化为流程维护。

2. 定义角色职责与决策边界

角色名称不是重点，职责能否被执行才是重点。产品负责人需要对价值排序负责，团队需要对实现方案和交付质量负责，业务代表需要按约定参与验收，管理者需要清除组织级障碍并处理优先级冲突。一个人可以兼任多个角色，但不能让关键决策变成“大家都负责，结果没人拍板”。

建议把高频决策列出来：谁能调整需求优先级？谁确认验收标准？谁批准发布？跨团队资源冲突由谁处理？哪些情况必须升级？将这些问题写成简短的决策约定，并在真实冲突中检验。决策边界清楚，团队才有自治的空间，而不是每件事都等层级审批。

3. 建立足够小且可验收的工作项

一个工作项应当能描述用户或业务价值、完成边界和验收条件。把“完成支付系统”作为一个事项，无法帮助团队安排工作；把它拆成用户可感知、可测试、可逐步上线的能力，团队才可能在短周期内获取反馈。拆分时要避免仅按技术层拆成“前端完成、后端完成”，却没有一条端到端能力可供验收。

验收条件要能被不同角色理解，并尽可能在开发前讨论。不是每个细节都必须提前穷尽，但边界、异常场景、数据权限、兼容要求和关键性能条件不能全留到测试末期。需求澄清的目标不是消灭变化，而是让变化有明确入口和影响评估。

4. 用限制在制工作量来减少并行拥堵

团队同时开始的事项越多，不代表完成得越快。多任务切换会增加上下文恢复成本，测试和评审还可能形成队列。可以先统计一个团队同时处于开发、评审、测试中的工作数量，再逐步设置在制上限；如果上限触发，优先帮助已有事项完成，而不是不断开启新工作。

这不是要求所有团队套用同一个固定上限。合理的上限取决于团队人数、工作项大小、专业分布和外部依赖。初期可以用观察数据设定，再在回顾中调整。重要的是让“为什么不继续开新任务”成为一个流动效率问题，而不是被误解为人员没有工作。

5. 建立反馈、回顾和调整的节奏

迭代评审用于展示已完成的能力并收集业务反馈，回顾会用于改善团队协作方式，两者不要混为一谈。评审讨论“交付的东西是否有价值、接下来需要验证什么”；回顾讨论“工作怎样流动、哪些阻塞反复出现、下一轮试哪项改进”。

改进项要少而具体。每次回顾选一至两个可验证动作，例如“测试人员在需求细化阶段参加评审”，并指定负责人、观察周期和判断指标。如果回顾产生十几条无人跟进的行动项，团队学到的通常是会议没有后果。

五、案例与数据观察：一个百人以上组织如何验证协同改进

1. 案例边界与数据口径

下面用一个情景模拟案例说明如何做项目协同诊断。假设某企业有一百二十名研发与产品相关人员，多个团队共同支持一个业务平台，项目最初按部门分段交接。由于没有公开的企业原始数据，以下数值只用于演示指标设计和决策逻辑，不代表任何客户实测、行业平均或特定工具效果。

团队选择一个非核心但有真实用户的业务流程作为试点，设置八周观察窗口。基线取试点前连续八周的工单记录和版本记录；试点期间维持相同统计范围，记录需求进入待办、开始开发、进入测试、通过验收和发布的时间戳。若存在重大范围变更，则单独标记，避免把外部变化误判为流程改善或恶化。

2. 观察的不只是交付速度

情景模拟中，团队将高优先级需求的中位交付周期从二十四天降到十七天，但这并不能单独证明敏捷机制有效。还要检查同期缺陷逃逸率、验收返工、临时插单和版本回滚。如果周期缩短主要来自减少测试或把未完成工作提前标记为完成，表面速度提升并没有转化为可持续交付能力。

同样，迭代目标达成率从百分之六十提升到百分之八十，可能说明计划更贴近容量，也可能只是团队降低了承诺难度。因此，我会把目标达成率和用户价值、缺陷、范围变动放在一起分析，并追踪连续多个周期。单个迭代有偶然性，趋势和原因比一个漂亮数字更有解释力。

3. 把改进动作和结果建立因果链

这个模拟团队发现，需求平均等待确认五天，测试排队六天，跨团队接口确认四天。于是采用三项动作：产品和测试提前参加需求澄清；工作项拆到可在一周左右完成并验收的粒度；接口负责人在迭代开始前确认依赖和可用环境。每项动作都对应一个明确等待节点，而不是笼统要求“加强沟通”。

观察结果可以帮助团队判断哪项措施值得保留。如果测试等待明显下降、但总周期没有变化，瓶颈可能已转移到发布审批或业务验收；如果需求确认时间缩短而返工增加，说明前置澄清做得不够，而不是越快确认越好。敏捷改进是瓶颈迁移的过程，不能假设解决一个节点后其他节点会自动消失。

4. 采用能解释原因的指标组合

我通常将指标分成流动、质量、价值和可预测性四类。流动指标回答工作多久完成、在哪等待；质量指标回答交付后是否稳定；价值指标回答用户是否真正使用或问题是否解决；可预测性指标回答团队能否基于容量做合理计划。不同项目的业务价值口径不同，不必把所有指标硬塞进一张管理驾驶舱。

DORA的公开研究长期关注软件交付绩效与组织能力之间的关系，其指标体系也经历过调整。使用相关指标时，团队应以对应年份的定义为准，并结合自身发布方式和数据采集口径；不要把某个外部模型的分类直接当成团队排名，更不要用单一指标考核个人。

六、不同情况下的行动建议：从试点团队走向多团队协同

1. 团队少、依赖少：先建立轻量闭环

如果团队规模较小、需求变化快、跨团队依赖少，可以从简单待办、明确验收条件、短周期反馈和固定回顾开始。不要一开始就建立复杂的组合计划、层级报表和多重审批。流程过重时，团队会把时间花在维护管理信息，而不是验证用户问题。

轻量不等于没有规则。至少要讲清工作何时可以进入开发、何时算完成、缺陷如何处理、临时插单由谁决定。把规则写在团队看得见的地方，并通过实际项目不断修订，比先追求一套完整方法论更有效。

2. 多团队共享组件：先管依赖，再谈统一迭代

若多个团队共享架构、数据、测试环境或接口负责人，重点应放在依赖可见性和提前协调。每个团队都可以有不同的迭代节奏，但必须约定依赖提出时间、接口变更通知、环境准备责任和冲突升级路径。为了看起来一致而强行统一所有迭代节奏，可能带来更多等待。

跨团队计划要围绕可集成的能力和关键里程碑，而非只汇总各团队任务数量。组织可以定期召开依赖协调会，但会议输入应是具体的依赖项、影响范围、责任人和决策期限。若没有需要解决的跨团队事项，不必机械地开会。

3. 合规或高风险项目：敏捷迭代与必要控制并行

合规要求高的项目，并不意味着不能敏捷。可以把风险评估、权限审核、安全测试和审计证据纳入工作流，让必要控制在交付过程中持续发生，而不是到上线前集中补材料。要区分可调整的实现范围与不可省略的控制要求，并在开始时确认谁负责留存证据、什么条件触发复核。

若法规或合同要求阶段性签署，团队可以在阶段内采用短周期开发和验证，在规定节点完成正式审查。敏捷不是绕开治理，而是减少治理要求在实际交付中的意外与返工。所有例外都要有负责人、理由、时限和风险处置方式。

4. 组织已有大量历史数据：先统一口径再做仪表盘

如果团队已有多套任务系统、缺陷系统和发布记录，首先要对齐工作项标识、状态含义、日期口径和团队归属。一个系统中的“完成”代表代码合并，另一个系统中的“完成”代表已上线，直接拼接两边数据得到的周期没有可靠解释。

建议先挑三到五个管理决策真正会使用的指标，手工抽样核对数据，再逐步自动化。仪表盘应帮助回答“哪里在等待、哪类需求经常返工、哪些依赖导致延期”，而不是为了展示更多图表。没人根据数据做决策的指标，通常只是新的维护负担。

七、工具选择与取舍：先明确协作边界，再决定是否更换系统

1. 工具评估从管理问题和数据边界开始

项目管理工具至少要回答几个实际问题：能否覆盖需求到交付的关键工作流？多团队之间能否管理依赖和权限？管理者需要的视图是否能由统一口径生成？系统能否满足部署、安全、审计和数据治理要求？迁移成本是否可接受？这些问题比功能清单里有多少按钮更能预测长期使用效果。

对超过一百人的组织，工具选择还要考虑组织结构变化、跨项目报表、细粒度权限、集成能力、管理成本和供应商服务能力。试点时应验证真实流程，而不是只看演示环境中的标准流程。至少挑选一个需求从提出到发布的完整样本，检查每次状态变更能否留下足够的上下文。

2. 何时考虑 PingCode 这类平台

如果组织规模已经超过一百人，需求、研发、测试和项目管理需要跨团队协同，可以将 PingCode 作为候选项目管理平台之一评估。它主要服务中大型企业及一百人以上组织，支持私有化部署，也支持 Jira 平滑迁移。对于需要评估国产替代方案的团队，它可以进入候选清单；但“国产替代不二选择”不应被理解为适用于所有组织的无条件结论，最终仍要由安全要求、工作流匹配、迁移质量和总拥有成本验证。

尤其是从 Jira 迁移时，不要只核对项目和任务是否导入成功。更重要的是检查字段映射、历史评论、附件、权限、自动化规则、链接关系、报表口径及用户习惯。迁移后若状态含义发生改变，旧报表就可能失去可比性；若团队不再维护原先的自动化规则，工作流也可能悄悄退化。

3. 先做迁移样本，再决定全量切换

我建议选择一个代表性项目做迁移样本，至少覆盖常见工作项、自定义字段、权限、附件、历史记录、迭代数据和典型报表。样本项目不应是最简单的“空项目”，也不宜一上来就迁移所有历史数据。通过样本测试，团队能够发现数据质量问题和流程差异，再评估是否需要清理、映射或保留历史只读访问。

迁移验收要有明确清单：抽样记录完整性、用户权限正确性、关键链接可用性、核心报表数值一致性、团队能否在新系统完成一个真实迭代。先定义回退方案和并行期，再安排切换窗口。工具上线后，应观察使用率和数据质量，而不是以账号开通数作为成功标准。

4. 选择工具时必须接受的取舍

功能覆盖更广，通常意味着配置和治理工作更多；流程更灵活，也可能让不同团队产生不一致的数据口径。私有化部署可以满足部分组织的数据控制要求，但需要自身承担相应的基础设施、升级和运维责任。系统迁移可以减少长期割裂，却会带来短期学习、数据核验和流程适配成本。

没有一种工具能同时让迁移零成本、配置无限灵活、治理负担为零且所有团队完全一致。选型的目标不是找“没有缺点的系统”，而是明确哪些约束最重要、哪些成本能够承担，并通过试点证据减少决策风险。

八、如何衡量做得好不好：建立不会诱导错误行为的指标体系

1. 以端到端指标看交付流动

建议从需求被接受到用户可以使用的时间计算端到端周期，并分别记录需求澄清、开发、评审、测试、验收和发布阶段的耗时。平均值容易被少数极端项目拉高，可以同时观察中位数和高分位数；如果团队规模或工作项大小变化，也要分层对比，不能拿完全不同的样本直接下结论。

交付频率也要结合发布内容和风险看。高频发布如果伴随着高缺陷率和频繁回滚，并不一定优于较低但稳定的频率。对有独立功能开关、自动化测试和回滚机制的团队，发布节奏可以更灵活；对受批次审批约束的环境，则更应关注审批等待和交付质量，而非盲目追求每天发布。

2. 以质量与价值避免“越做越快、返工越多”

质量指标可以包括生产缺陷、严重事故、回滚、返工工时和验收失败原因。价值指标则应贴近业务结果，例如用户完成目标任务的比例、功能采用率、人工处理量变化或客户反馈。并非每个项目都能直接做因果归因，但至少要区分“功能已经上线”和“用户问题得到改善”这两件事。

如果业务指标短期内无法获得，可以先设一个可验证的近端信号，例如目标用户是否尝试功能、关键流程完成率是否变化、客服相关咨询是否减少。要明确观察窗口和数据限制，避免把同期市场活动、季节因素或其他产品变化的效果全部归到一次敏捷迭代上。

3. 用组合指标驱动团队学习，而非个人排名

团队指标的用途是发现系统问题，不是把复杂协作压缩成一个分数。以个人完成任务数、代码提交数或工时利用率排名，容易鼓励任务切碎、隐瞒协助成本和回避高风险工作。更可取的做法是观察团队层面的周期、质量、价值和可预测性，再通过具体工作项调查原因。

指标有变化时，先确认数据采集口径是否改变，再检查样本构成、范围变化和外部事件，然后讨论流程中的原因。若数据不支持预设判断，就要允许团队修正假设。敏捷管理的核心不是让数据证明管理者正确，而是让数据更早暴露团队原先看错了什么。

九、从0到1的启动清单：先做小实验，再决定扩展

1. 启动前两周：设基线、定目标、确认边界

启动阶段先把问题写成可观察的陈述，明确试点业务、参与角色和不能违反的质量或合规要求。选取最近一段时间的真实工作项，统计周期、等待、返工、缺陷和范围变化。同步确认谁有权排序需求、谁负责验收、谁处理跨团队阻塞。

这一阶段不要追求把流程文档写到无所不包。优先记录影响试点的规则和决策路径，并找不同角色一起核对。若业务负责人无法持续参与、关键依赖方不愿承诺响应，或试点团队无法接触用户反馈，应先解决这些启动条件，而不是急着宣布项目进入敏捷模式。

2. 试点运行阶段：稳定节奏，记录真实例外

试点开始后，团队应保持固定的计划、协同、评审和回顾节奏，但不要把会议次数当成过程质量。每个迭代都要记录计划外工作、需求变化、阻塞和质量问题。临时插单不一定错误，重要的是明确插单由谁批准、替换了哪些工作、对目标造成什么影响。

需求没有按期完成时，不急着改状态或重新估算来美化报表。先问工作项是否过大、验收条件是否清楚、团队容量是否被打断、依赖是否失控。只有把原因保留下来，试点才有机会修正系统问题，而不只是训练团队更会解释延期。

3. 试点结束时：按证据决定继续、调整或停止

复盘时对照基线，检查交付周期、质量、用户反馈和团队负担是否发生变化。若速度改善但返工明显增加，应优先修复需求和测试机制；若团队节奏稳定但价值信号没有改善，应重新审查选题和用户假设；若局部流程有效但依赖方迟迟不配合，不应把问题归咎于试点团队。

扩展不等于复制所有配置。可以复制已验证的原则，例如验收条件、依赖责任人和数据口径；各团队仍可根据产品节奏、风险和工作流调整具体做法。每扩展一批团队，都要重新检查共享资源和组织治理是否成为新的瓶颈。

4. 设定扩展门槛，避免把试点成功变成口号

在试点之前就约定扩展门槛，例如连续多个周期能够稳定完成用户反馈闭环、质量没有恶化、核心角色投入持续、指标数据可复核、跨团队阻塞有明确处理路径。门槛应该适合项目风险，不必设成适用于所有团队的统一分数线。

如果结果不理想，也可以得出有价值的结论：某类需求不适合当前迭代长度；某个审批环节需要组织层面改造；团队的主要限制不是研发流程而是业务决策速度。停止一个无效试点不是失败，继续扩大一个尚未验证的流程，才可能造成更大的成本。

十、最后的判断：敏捷落地看的是组织学习速度

1. 不要追求“看起来很敏捷”

团队采用了看板、迭代、站会或回顾，不代表已经具备敏捷交付能力。真正值得关注的是：问题能否尽早被发现，团队能否根据证据调整，跨职能角色能否围绕同一结果协作，交付后的质量和用户反馈能否进入下一轮决策。

成熟的做法未必会议更多，也未必流程更复杂。对一些团队来说，最大的改善可能只是产品和测试提前参与需求讨论；对另一些团队，则可能是减少在制工作、建立共享依赖视图，或让管理者明确放弃冲突优先级中的一项。改进动作应由瓶颈决定，而不是由流行实践决定。

2. 下一步先完成一次小而完整的验证

如果你正在准备从0到1实施敏捷，我建议本周先完成四件事：选一个真实且边界清楚的试点项目；记录当前周期和主要等待；确认产品、开发、测试、业务的决策职责；约定一个短周期内可验收的用户结果。等这些条件成立后，再配置必要的协作流程和工具。

敏捷不是把不确定性消灭，而是让不确定性更早出现、更低成本地被验证。从一个能够闭环的项目开始，先看证据，再调机制，最后才考虑规模化。这样做不一定让第一轮就完美，但能让每一轮都比上一轮更接近真实问题。