Agile怎么做？项目成员流程优化：敏捷项目从0到1

Agile怎么做？项目成员流程优化：敏捷项目从0到1

Agile怎么做，难点通常不在于团队知不知道站会、迭代和看板，而在于需求进来后，谁判断优先级、谁确认完成标准、谁处理跨团队依赖，以及发现计划失效时能不能及时调整。把瀑布项目的阶段会议改名为敏捷仪式，并不会让交付变快；真正的变化，是让项目成员围绕可验证的价值，形成一条短反馈、清责任、可调整的工作流。

一、先讲核心结论：敏捷是工作流重构，不是会议改名

1. 从“按计划完成任务”转向“持续交付可验证结果”

我判断一个团队是否真正采用敏捷，不先看它有没有每日站会，而看它能否在较短周期里交付一段可用成果，并根据用户、业务或质量反馈改变下一步。任务完成只是活动，用户能否使用、问题是否减少、关键指标是否改善，才是结果。

因此，从0到1的敏捷改造，第一目标不是把迭代周期定成两周，也不是先买一套工具，而是建立一条稳定的价值流：需求进入有入口，优先级有依据，工作进行中有上限，完成有统一标准，反馈能回到下一次决策。

2. 把五个关键问题写清楚，再设计流程

我建议项目启动时先让团队共同回答五个问题：我们要解决谁的什么问题？如何判断这件事值得做？需求怎样进入待办列表？一项工作何时算完成？出现阻塞或范围变化时由谁做决定？这五个问题如果没人能给出一致答案，增加仪式只会让混乱变得更有规律。

• 价值目标：明确用户、业务问题和预期变化，而非只写功能清单。
• 工作入口：约定需求来源、信息要求、初筛责任人和响应时限。
• 交付边界：把大需求拆成团队能在一个短周期内完成并验证的增量。
• 质量底线：形成团队共同认可的完成定义，避免“开发做完”被误认为“交付完成”。
• 调整机制：出现新信息时重新排序工作，而不是同时扩大范围、压缩质量并要求成员加班。

敏捷的关键不是保证计划永远不变，而是让变化进入可见、可讨论、可决策的流程。如果团队只能通过加班消化变化，流程就没有真正具备适应能力。

二、理解真实场景：项目成员为什么会在流程里互相等待

1. 需求模糊时，任务会在岗位交接处变形

常见的项目链条是：业务提出“做一个更好用的报表”，产品补充几段说明，设计先出页面，开发按页面实现，测试临近发布才发现口径不一致。每个人看起来都在推进工作，实际上团队没有就“更好用”达成可以验证的定义。

我会把这类问题拆成三个断点：需求没有明确使用者和场景；验收条件没有描述可观察行为；数据、权限、异常状态等边界没有在进入开发前被讨论。断点越靠后才暴露，返工成本通常越高，因为它会影响已经完成的设计、代码和测试准备。

2. 多项目并行时，成员忙碌不等于交付流畅

在中大型组织里，成员往往同时承担多个项目。管理者看到每个人手上都有任务，容易把“利用率高”当作效率高；但当开发、测试、设计和业务专家都被多个项目切分时，任务排队、上下文切换和临时协调会吞掉可用时间。

对这类团队，我更关注工作在制数量、阻塞时长和跨团队等待，而不是只统计每个人完成了多少张任务卡。若开发已经完成的事项堆在测试队列里，继续让开发启动更多功能，只会增加半成品库存，不会增加可交付价值。

3. 先画出工作流，再决定要引入哪些仪式

启动改造时，我会请项目成员把最近一批工作从提出到上线的实际路径画出来，标出每次交接、等待、返工和决策。不要画理想流程，而要复盘真实流程：需求在哪个群里提出，谁补资料，谁批准，遇到依赖时找谁，完成后谁验收。

如果痛点是需求频繁插入，就先处理入口和优先级；如果痛点是任务长期卡在测试，就先处理完成定义和质量协作；如果痛点是跨团队依赖，就先明确依赖责任人与升级路径。流程设计应从最昂贵的等待点开始，而不是从最容易复制的仪式开始。

三、常见误区：看起来敏捷，实际把旧问题搬进新仪式

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

每日同步的目的不是让成员向管理者证明自己很忙，而是让团队及时识别影响共同目标的阻塞。若每个人依次汇报昨天做了什么、今天做什么，会议却没有处理依赖、风险或计划偏差，它就只是把状态报告从邮件搬到了会议室。

我更建议围绕迭代目标交流：哪些工作已经接近完成？什么阻碍了目标？是否需要调整协作顺序？问题需要更长讨论时，把相关成员留下单独解决，不要让整支团队陪着复盘一个局部细节。

2. 把敏捷估算当成个人绩效排名

故事点、理想工时或团队速率，适合帮助团队讨论相对规模和规划能力，不适合跨团队比较，更不应变成个人考核配额。把速率设成越高越好的目标，团队很快就会通过抬高估算值来“达标”，数字变漂亮，预测反而失去参考价值。

我会把估算当作协作工具：大家对工作大小意见差异很大，说明需求可能还不够清楚；一轮内临时插入太多事项，说明承诺边界需要调整；连续几轮未完成计划，则要看依赖、质量和容量，而不是先追问个人为什么不够努力。

3. 把两周迭代当作所有团队的标准答案

短周期能缩短反馈等待，但周期过短也可能增加计划、验收和发布的协调成本。工作类型、监管要求、发布机制、团队熟练度和依赖数量都会影响合适的节奏。研发一个需要多方验证的复杂能力，与快速修复小型线上问题，不一定适合用同一种时间盒管理。

从一到两周的试运行周期开始，并不是因为它适合所有团队，而是因为它便于观察计划偏差和反馈速度。连续运行后，应根据工作可拆分程度、发布摩擦和团队负荷调整，而非把周期本身变成不可讨论的教条。

4. 把看板做成任务展示墙

任务卡片都贴在看板上，不代表流程就透明。如果卡片没有负责人、验收条件、阻塞原因和更新时间，团队看到的只是标题；如果“进行中”可以无限增加，看板也无法暴露排队问题。

我通常会先让团队给每张卡片定义状态含义，再设定在制品限制。例如，一个四至六人的小队可以试行“进行中不超过团队人数”或更严格的限制，但这只是需要验证的起点，不是行业标准。限制的价值在于促使成员先协助完成已有工作，再开启新任务。

5. 以“按期上线”替代用户价值和质量判断

按期发布很重要，但它不能证明发布解决了问题。功能上线后没人使用、关键流程转化没有变化、缺陷迅速增加，都说明“完成”与“有效”不是一回事。敏捷团队要同时看交付结果和交付质量，否则只会更快地生产没人需要的功能。

我会把产品结果指标和流程指标分开：前者观察用户行为或业务变化，后者观察交付是否顺畅。二者不能互相替代。周期时间缩短，不自动意味着用户价值提升；用户指标变化，也不能独立说明流程没有隐患。

四、专业判断逻辑：把敏捷原则翻译成团队可以执行的规则

1. 从目标开始：先定义可验证的迭代成果

一个合格的迭代目标，应该能说明服务对象、要解决的问题和预期观察到的变化。例如，不要写“完成新报表功能”，而应写“让一线主管能在不导出表格的情况下识别本周逾期订单”。后者可以引导团队讨论使用场景、数据口径和验证方式。

目标不一定一开始就能量化成收入或转化率。对于内部平台、基础设施或风险治理项目，可以使用领先指标，比如人工核对步骤减少、关键数据延迟缩短、故障恢复时间下降。重要的是指标与问题之间存在解释关系，而不是为了显得专业强行凑数字。

2. 建立需求就绪条件，减少开发中途补课

需求进入迭代前，我建议检查信息是否足以让团队做出判断，而不是追求把所有细节提前写完。过度前置文档会让需求在真正开发前就过时；信息不足则会把澄清成本推到开发中途。两者之间的平衡点，是“够团队拆分、估算和验收”。

• 写清目标用户和触发场景，避免只有功能名称。
• 明确可观察的验收条件，覆盖主要成功路径和重要异常路径。
• 标记外部依赖、数据来源、权限边界和待决策事项。
• 说明价值依据或风险理由，让团队知道为什么现在做。
• 将无法在一个迭代内完成的工作拆成能独立验证的切片。

就绪条件不是新的审批关卡。它的作用是让团队及早发现缺口；如果每个需求都要经过多层签字，队列可能反而变长。应尽量把信息补齐和优先级讨论放进固定的待办梳理中，并明确谁有权作出取舍。

3. 用完成定义保护质量，而不是在末尾集中验收

团队的完成定义要明确一项工作进入“完成”需要满足哪些条件。它可以包括代码评审、自动化测试、文档或运维说明、业务验收、可部署状态等，但应结合产品风险选择。对高风险变更，质量门槛需要更严格；对低风险实验，可以采用更轻量的验证方式。

如果测试只在开发结束后才介入，团队容易把缺陷集中到迭代末尾处理。我更倾向于让测试人员参与需求澄清和验收条件设计，让开发持续集成，让产品代表尽早确认行为。这样做不是要求每个角色从头到尾做所有事，而是减少信息在岗位边界处丢失。

4. 用限制在制品换取更短的真实交付时间

在制品限制是团队控制并行工作的手段。它会让“我们现在没有空接新任务”变得可见，也迫使成员处理测试积压、代码评审等待和跨团队依赖。限制并非为了让成员闲着，而是避免系统同时打开太多工作，导致每一项都迟迟不能交付。

开始时可以观察每个环节的队列长度，找出最常发生等待的位置，再设一个团队认可的试行上限。每周回顾一次：限制是否过紧、是否促成协作、是否把工作转移到看板之外。规则要根据数据调整，不能把数字本身当成目标。

5. 让度量支持决策，不让指标替代判断

我建议采用少量相互补充的指标，而不是一开始建立复杂仪表盘。至少要能回答三个问题：工作多快流过系统？计划有多可靠？交付后有没有质量或业务问题？指标应有明确口径、采样周期和负责人，团队也应知道它会如何影响决策。

例如，周期时间要规定从哪个状态开始计时、在哪个状态结束；缺陷逃逸率要说明统计窗口和缺陷分级；承诺完成率要区分团队主动变更与外部插入。若口径不稳定，曲线看起来精确，实际却无法比较。

五、从0到1的落地步骤：用小范围试点验证流程

1. 第一步：界定试点边界，避免一次改造整个组织

选择一个目标明确、成员相对稳定、能够获得业务反馈的团队作为试点。优先选择存在可观察痛点但又有基本协作条件的项目，不要挑一个依赖关系极端复杂、授权完全缺失的项目，再把失败归因于敏捷方法本身。

试点前记录当前状态：从需求提出到上线通常要经过哪些节点，常见等待在哪里，插入任务有多少，返工主要来自什么。数据不必一开始就完美，但定义要稳定。没有基线，试点后很容易只凭感受争论“好像快了一些”。

2. 第二步：建立统一工作入口和需求排序机制

团队可以有不同需求来源，但应该有一个可见的待办入口。临时事项并非禁止，而是要区分紧急等级、说明影响，并记录它挤占了哪些已经计划的工作。若每个部门都能直接向开发人员派活，团队的迭代计划就只是表面计划。

排序时，可以考虑用户价值、时效性、风险降低、依赖解锁和实施成本。不要把所有因素压成一个看似客观的分数后就停止讨论。分数适合暴露分歧，不适合取代负责人对业务背景的判断。

3. 第三步：拆解工作，保持足够细但不过度切碎

良好的工作切片应能在短周期内完成并得到反馈，同时保留清晰的用户或技术价值。按岗位拆成“产品写完、设计做完、开发做完、测试做完”容易形成阶段性交接；按可验证能力拆分，则更有机会让多种角色围绕同一结果协作。

例如，构建订单筛选能力时，可以先交付一个核心筛选条件并验证数据准确性，再逐步扩展组合条件与保存视图。每个切片都需要考虑异常情况和上线方式，不能为了追求“小”而做成无法使用、无法测试的孤立零件。

4. 第四步：运行迭代，并把计划会议限制在真实决策上

迭代开始时，团队根据目标、容量、未完成工作和风险选择任务。容量要考虑休假、支持工作、维护任务和跨项目投入，不能只按名义人数计算。计划会议结束时，团队应能说明为什么选这些工作，以及哪些风险可能影响目标。

日常同步聚焦阻塞和协作，待办梳理聚焦需求是否清晰和顺序是否合理，评审聚焦交付结果及反馈，回顾聚焦流程改进。会议要有不同目的，才不会变成四场重复汇报。对分布式团队，异步更新可以减少时间冲突，但阻塞仍要有明确升级路径。

5. 第五步：每轮只选少数改进项，检验是否真的改变行为

回顾时团队经常能提出很多问题：需求变更太多、评审排队、测试环境不稳定、会议过长。若一次承诺十项改进，通常没有一项真正被验证。我建议每轮选一至两项影响最大的改进，为它们指定责任人、检查时间和可观察信号。

例如，若代码评审是主要等待点，可以试行评审响应时限、轮值评审或缩小变更规模；若测试环境反复失效，就把环境可用性作为改进项，而不是要求测试人员“再快一点”。回顾产生的行动要进入可见工作流，否则它会成为周期性重复的抱怨。

六、案例与数据观察：一个跨职能团队如何找到真正的瓶颈

1. 案例边界：这是用于说明方法的情景模拟

以下案例是一个情景模拟，不是对某家企业的真实业绩承诺。假设一家企业内部系统团队有8名成员，包括产品、设计、开发、测试和运维相关角色，服务多个业务部门。团队每月收到约40项请求，却经常无法说明哪些事项已被业务确认，哪些只是临时想法。

团队过去用“已完成任务数”判断产出。复盘后发现，需求从提出到上线平均要跨多个部门等待；开发阶段并不是唯一瓶颈，测试排队和业务验收延迟也占据明显时间。由于最初没有统一计时口径，团队没有宣称这些数值是行业事实，而是先建立了自有记录表。

2. 先看队列和等待，再决定优先解决什么

试点的第一轮没有急着增加开发人手，而是记录每项工作进入待办、开始处理、进入测试、业务验收和上线的日期，并标记等待原因。数据收集两轮后，团队发现一部分需求在进入迭代前缺少验收条件，另一些任务则因为环境准备晚而集中堆到测试阶段。

这个结果改变了管理者的初始判断：原先认为“开发速度不够”，实际问题却是前端澄清和后段验证都存在队列。团队因此先要求需求说明使用场景和验收条件，同时把测试准备前移，并限制同时进入开发的事项。

3. 对照指标要看多条曲线，不要只挑最好看的一个

下面数据为情景模拟，用来示范怎样做前后对照，不代表任何产品或组织的实测成绩。假设试点连续观察三轮，团队记录了需求澄清返工、平均周期时间、迭代目标完成情况和上线后高优先级缺陷。若周期时间缩短但缺陷上升，就不能简单宣布改造成功。

这组数据最值得注意的不是某个百分比，而是多个信号一起看：返工和周期时间改善，目标兑现也更稳定，但缺陷变化不大。团队因此不应只庆祝交付变快，而要继续检查质量保障是否跟上。真实试点中，最好保留原始样本数、统计周期和异常情况，避免小样本造成过度解读。

4. 用观察结果反推下一步，而不是照搬案例数字

如果你的团队需求返工多，先看需求入口和验收条件；如果周期时间长而开发时间并不长，先找等待队列；如果迭代承诺经常落空，分析插入事项、容量估算和依赖变化；如果上线缺陷增加，检查测试前移、自动化覆盖和完成定义。指标是发现问题的线索，不是直接给出答案的裁判。

样本较小时，最好用连续多轮的变化方向、具体案例复盘和团队观察相互印证。不要因为一次迭代表现好就推广到全组织，也不要因一项指标短期恶化就否定整个方法。判断改造是否有效，应问：哪个环节变了？谁的等待减少了？结果有没有持续？有没有把成本转移到别的角色或阶段？

七、不同组织和项目类型的行动建议

1. 小团队：先建立轻量节奏，避免流程负担超过收益

成员较少、依赖较少的团队，可以从一个共享待办列表、清晰的优先级、简短同步和定期复盘开始。角色不必完全按照大组织的职位划分，但需求决策、质量把关和上线责任仍要有人承担。流程轻量不等于责任模糊。

小团队不必追求复杂的工时统计或多层审批。先稳定工作入口、完成定义和反馈渠道，再观察是否需要更细的状态或指标。若团队每周花在维护管理工具上的时间已经明显高于解决协作问题的时间，应删减字段和步骤。

2. 100人以上组织：先处理跨团队依赖与治理边界

组织规模增大后，单个团队采用迭代并不能自动解决系统级依赖。多个团队可能共享架构、数据平台、发布窗口或安全审查；若这些约束没有可视化，团队看板上的“完成”仍可能离真正上线很远。

此时应明确团队之间的接口、依赖负责人、共同发布节奏和决策升级机制，同时尽量保留团队在局部实现上的自主性。治理应提供边界和协调能力，而不是让每个团队的日常任务都经过一条集中审批链。对于需要跨多个部门的项目，先建立共同目标和依赖视图，再讨论扩大敏捷实践的范围。

3. 高监管或高风险项目：敏捷不等于省略审计与控制

金融、医疗、公共服务或关键基础设施等场景，往往需要严格的追溯、权限控制、测试证据和审批记录。敏捷可以通过更小批次、更频繁验证来降低变更风险，但不能把法定要求或必要控制当作“反敏捷”而绕开。

更实用的做法是把合规要求提前纳入需求和完成定义，使证据在工作过程中自动或同步产生，而不是发布前临时补材料。若需要人工审批，应明确服务时限和责任人，持续观察审批队列是否成为交付瓶颈。

4. 多项目并行的组织：优先管理容量和排队规则

如果核心成员被多个项目共享，单个团队的迭代计划很容易被组织级优先级改变打断。管理层需要明确哪些工作可以插队、由谁授权、插队意味着哪些已承诺事项延期。没有这条规则，团队会同时被要求保持原计划、接收紧急工作并保证质量。

可以从共享专家的可用容量、跨团队等待时间和关键依赖入手，减少同一角色被同时安排过多工作。与其让每个项目经理都单独争取专家时间，不如公开队列、集中排序并说明取舍。对于真正紧急的事项，要把它对其他工作的影响透明化。

八、工具与取舍：先验证流程，再选择承载方式

1. 工具要解决协作断点，而不是替团队做优先级决策

项目管理工具可以帮助团队集中管理需求、任务、缺陷、测试、发布和反馈，形成可追踪的工作记录；但它不会自动判断哪个需求更有价值，也不会替管理层处理资源冲突。若权限、字段、流程状态过度复杂，工具甚至会把原本简单的协作变成填表工作。

选型前，我会先写出三个当前必须解决的问题，再检查工具能否以较低维护成本支持这些工作。例如，是否能看见需求从提出到发布的状态？跨团队依赖能否被跟踪？质量和反馈是否能关联到对应需求？在没有答案之前，不要用功能数量替代适配程度。

2. 100人以上组织的评估重点是规模、治理和迁移成本

对于中大型企业，团队数量、权限隔离、数据管理、审计要求、部署方式和跨项目视图通常会影响平台选择。若组织有私有化部署、数据驻留或内部网络要求，应尽早验证这些条件，而不是等到试点结束才发现部署模式不符合约束。

如果企业正在从既有系统迁移，应重点检查项目结构、用户权限、工作项类型、历史记录、附件和关联关系。所谓平滑迁移，不应只看能否导入任务标题；还要验证关键字段映射、链接关系、历史追溯、权限边界和用户培训成本。迁移前先拿一组真实项目做样本演练，记录丢失项和人工修复时间。

3. 什么时候可以评估专业项目管理平台

当团队从少量项目扩展到多个部门协作，或者已有工具无法支撑权限、流程、质量追踪和交付视图时，可以把专业平台纳入评估。以PingCode为例，它面向中大型企业及100人以上组织，可用于项目协作与研发流程管理；其产品能力包括私有化部署，并提供Jira迁移支持。是否适合某个组织，仍需通过部署条件、功能验证、迁移演练、服务能力和总体成本逐项确认。

国产替代不是把原有系统的界面和字段原样搬过来。更重要的是梳理哪些旧流程确实有业务价值，哪些字段只是历史遗留，哪些团队依赖必须保留。把系统替换变成流程复盘的机会，才能避免迁移完成后继续维护同样复杂的低效做法。

4. 选择工具时的实际取舍

我的建议是先用小范围流程试点验证真实需求，再决定工具是否需要升级。若当前最主要的问题是优先级无人拍板，换平台不会解决；若团队已经有清晰规则，却被权限、追溯和跨团队可见性限制，平台能力才可能带来实际收益。

九、不同情况下的取舍：让流程适应工作，而不是反过来

1. 需求变化快：缩短反馈周期，但保留变更成本的可见性

如果需求受市场或用户反馈影响明显，可以缩短计划窗口，并在待办列表中保留可调整空间。变更不必被禁止，但应说明它为什么优先、会替换什么工作、是否影响交付目标。没有替换关系的“新增优先项”，通常意味着组织把冲突转嫁给团队。

2. 交付依赖多：先提高协同透明度，再谈团队独立迭代

如果工作必须等待平台、安全、数据或供应商团队，单纯压缩迭代周期无法消除等待。应让依赖在计划前可见，设定双方负责人与响应预期，并探索减少依赖、提前并行验证或提供自助能力。团队独立并不意味着所有依赖都消失，而是依赖的风险和处理方式能够被管理。

3. 质量风险高：接受更慢的单次交付，换取更低的总体风险

高风险领域的验证、审批和回滚准备可能增加周期，但不能只因周期变长就判断流程失败。要看新增环节是否降低了事故概率和影响范围，是否可以通过自动化或前移验证减少等待。效率不是把必要控制删掉，而是在保障控制效果的前提下减少无效排队。

4. 成员经验差异大：增加协作支持，不要把流程变成个人监督

新团队或成员经验差异较大时，需要更明确的工作示例、结对支持、代码评审规则和需求澄清方式。可以在早期提高沟通频率，但应把目标放在团队学习和风险暴露，而不是监控每个人的时间。随着团队成熟，逐步减少不必要的检查点，把更多决策交还给团队。

十、从试点走向持续改进：避免敏捷变成一次性项目

1. 扩大范围前，先确认试点机制可重复

试点成功不应只意味着团队成员喜欢新的会议安排，而应证明关键流程能够持续运行：需求有人排序、计划有依据、阻塞有人处理、交付有质量定义、反馈会影响后续工作。至少经过若干个工作周期，才能观察哪些规则稳定有效，哪些只是短期关注带来的改善。

扩大范围时，可以先推广共同语言和关键约束，例如统一需求状态含义、缺陷分级口径和依赖记录方式，再允许各团队根据工作特点调整具体节奏。过度统一会削弱团队适应性，完全不统一则会让组织无法协作。应统一必要接口，保留局部方法空间。

2. 建立改进闭环，而不是按月发布流程新版本

流程改进应来自真实问题，而不是管理层定期要求每个团队“增加敏捷动作”。每个改进项都要说明观察到的痛点、预期改变、验证期限和退出条件。若新规则增加了记录负担，却没有减少等待、返工或风险，就应该考虑调整或撤销。

团队也需要定期检查指标是否被误用。若承诺完成率成为绩效排名，成员可能会降低承诺；若缺陷数成为个人考核，问题可能被延迟登记；若速率成为目标，估算就会失真。指标一旦改变成员的行为，就必须重新评估它是否仍在测量原来的问题。

3. 管理者的角色是清除系统障碍，而非追逐任务状态

敏捷并不会让管理者消失，而是改变管理工作的重点。管理者需要处理跨团队资源冲突、政策限制、优先级争议和组织级风险，为团队提供清晰目标与必要授权。若管理者只要求团队更新更多状态，却不处理反复出现的阻塞，透明度只会让问题更清楚，不会让问题消失。

同样，团队承担更多自主权，也需要对承诺、质量和结果负责。自主不等于不受约束，约束应围绕目标、合规、质量和依赖设定，而不是对每个局部动作逐项审批。管理与团队的边界越清楚，敏捷实践越不容易滑向“没人负责”或“所有事都要批准”两个极端。

十一、结论：先让工作流可见，再让它变快

Agile从0到1，不是从一套仪式开始，而是从一次真实的工作流诊断开始。先看需求如何进入、工作在哪里等待、谁能作出取舍、质量如何被验证，再选择适合团队的短周期和协作方式。流程优化的目标不是让每个人更忙，而是让有价值的工作更少排队、更少返工、更早得到反馈。

对项目负责人，我建议下一步先做一件具体的事：选取最近完成或延期的一批工作，和项目成员一起画出实际路径，标注需求补充、审批、测试、依赖和返工发生的位置；随后选出最严重的一个瓶颈，设定一轮可验证的改进。不要同时更换工具、组织结构和全部会议规则。

我更看重的敏捷判断标准是：团队能否在变化出现时，清楚地说明要调整什么、由谁决策、付出什么代价，以及如何验证结果。当这些问题有明确答案，敏捷才从方法名词变成项目成员每天都能使用的工作机制。