EET方法和AGR方法放在一起对比时最容易让人误会的点是它们看起来都是用来“做判断”的但一个是从经验证据往前推一个是从目标差距往回拉。我先把结论放在前面如果你的团队已经有足够多的历史数据优先把 EET 作为估算底座如果你面对的是一个新目标或重构任务历史数据稀薄AGR 反而更容易把范围拆清楚。这篇文章会围绕这两类方法从适用场景、操作流程、选型标准、常见坑和边界条件几个角度展开适合做需求评估、技术方案选型、项目复盘和团队评审的人直接参考。需要先说明一点这里讨论的 EET 和 AGR严格说不是某个官方标准或认证框架而是两类方法论的简称。EET 更偏“经验外推”AGR 更偏“目标反推”。即使你在其他资料里看到相同缩写定义可能不同但“一个看历史、一个看差距”的对比逻辑是通用的。1. 先弄清楚这两个方法分别擅长解决什么问题1.1 EET方法到底是什么EET 可以理解为“经验外推法”。核心逻辑是要判断一件新事情大概要多少成本、多少时间、多少资源不要凭感觉拍脑袋而是先去翻历史记录找到与当前任务最接近的过往样本把样本里的关键指标抽出来再通过对比差异、修正影响因子最终给出一个可验证的估计区间。EET 之所以在很多团队里受欢迎是因为它把“凭经验”变成了“有依据地用经验”。传统专家判断经常表现为“我做过类似项目我觉得需要三周”。EET 会强迫你把“类似”拆成可对比的维度业务复杂度、接口数量、改动范围、参与人数、历史缺陷率、需求变更次数、联调耗时、测试周期。只有这些维度能对上一个旧项目你给出的三周才有可推导路径。EET 的典型输入是历史项目数据典型输出不是“一个确定日期”而是“区间估计加置信理由”。比如“如果复用现有权限模块预计 8 到 12 人日如果重新设计权限模块预计 18 到 25 人日。”这个思路在生活中也很常见你装修房子不看当地报价单直接猜全包价很容易被坑。等你把户型、面积、施工项目、材料等级、淡旺季逐项拿出来对比同小区案例价格区间才会变得可信。EET 本质上就是这件朴素的事。1.2 AGR方法到底是什么AGR 可以理解为“目标差距评审法”。它不依赖“过去发生了什么”而是先定义“未来应该长什么样”再回头测算现在和理想状态之间的差距把差距变成一张可执行的任务清单。AGR 常用的流程可以拆成四步定义目标。目标要能量化不能只说“提升体验”要说“客服系统平均响应时间从 5 分钟降到 1 分钟以内”。盘点现状。当前系统和理想目标之间的每条差异都要记录不能只写一句“现状很落后”。按差距归类。把差异项归成流程、数据、代码、基础设施、组织协作等类型方便后续安排负责人。从差距生成行动。每条行动必须对应到至少一个差距不能出现“不知道该干嘛”的待办。AGR 最容易被误解的地方是它“不重视经验”。其实它重视的是“经验不能替代目标清晰度”。如果你连目标状态都描述不清楚再多的老专家坐在会议室里也给不出可靠方案。相反一旦目标状态清晰即使团队没有同类项目经验也可以通过拆解“当前状态到目标状态的每个断点”找出任务。1.3 两者解决的根本问题不同EET 解决的核心问题是一件事情大致的量级是多少。 AGR 解决的核心问题是朝向某个目标我们还缺哪些工作。很多人把这两个问题混在一起于是评审会会变成这样有人提出“我觉得要做 20 人日”另一个人反驳“我觉得 30 人日都不够”但他们讨论的其实是“量级估算”。真正该讨论的应该是“为了达到什么目标任务列表是什么”。这就是为什么很多团队用 EET 或 AGR 单跑都能跑通一放一起就说不清楚因为它们根本不在同一个决策层。建议开会之前先确认本场评审要产出什么。如果只是排期EET 更快如果是确定范围和分工AGR 更稳。2. 核心差异为什么不能混着用2.1 推导方向不同EET 是从历史推导未来。它的前提是“过去发生过的规律可以延续”。AGR 是从目标反推现状。它的前提是“目标状态可以被描述并且当前状态存在可识别的差距”。这两个方向听起来简单实际执行时影响很大。EET 适合回答“如果照以前的方式做大概需要多久”。AGR 适合回答“如果我们要达到一个没去过的状态到底缺了什么”。当项目从增量优化变成结构性重构时历史经验往往不够用这时只有 AGR 能把新的要求拆成任务。我把两者的差异放在一起看会更容易理解对比维度EET 方法AGR 方法推理方向从历史到未来从目标到现状核心输入历史样本、专家判断、影响因素可量化的目标、现状盘点清单核心输出估算区间、资源规模、时间范围差距清单、任务列表、验收口径适用阶段方案评估、工期预判、排期目标拆解、方案规划、需求对齐主要风险历史数据失真、类比样本不相似目标描述模糊、差距拆成伪任务对团队经验的要求高中到高对新场景的适应性差好2.2 对输入数据的依赖不同EET 非常依赖历史样本的质量。如果历史项目数据口径不统一比如上一个项目的工时记录里混入了大量脱产培训时间你的类比外推就会失真。更麻烦的是很多团队的历史项目记录只保存了“计划工时”和“实际上线时间”没有记录“中途砍掉的需求”“临时加入的联调成本”“返工次数”。这些缺失数据会让 EET 的估算看起来精确实际却非常脆弱。AGR 对历史数据要求低但对目标定义要求高。目标如果只写“提高人效”这个目标无法拆出收敛的任务清单因为“人效”没有边界、没有度量口径、没有起点和终点。同样的指标从“客服人均处理量”和“客户满意度”两个角度拆得到的两套任务可能完全不同。目标写得越模糊AGR 拆出来的任务就越像在给决策者交差而不是真正指导执行。2.3 输出形态不同EET 大概率输出“多少资源、多少钱、多少时间、在什么条件下成立”。AGR 输出“待办列表、里程碑、依赖关系、验收口径”。如果你只需要回答“这个迭代排多少天”EET 更直接。如果你需要回答“为什么排这么多天、哪些任务可以砍掉”AGR 更有说服力。两者不是非此即彼而是各自回答不同层面的问题。一个常见错误是用 EET 输出一次估算就当作 AGR 的差距清单来用。比如“20 人日”只是一个数字它没有告诉你这 20 人日到底花在哪个后端模块、哪些前端页面、哪些联调环节。反过来如果把 AGR 拆出的任务直接加起来估时间却没有做过任何历史校准也容易高估或低估。3. 同一个需求用 EET 和 AGR 各走一遍这一节用一个相对常见的案例来说明方便对照落地。假设背景如下项目名称客服系统重构。现状客服系统响应慢报表模块和第三方机器人耦合严重遇到高峰时段消息经常堆积。目标通过前后端分离和消息队列优化把平均响应时间从 5 分钟降到 1 分钟以内。团队情况有三个月的历史项目记录包含数个项目工时、缺陷数据、联调耗时但历史项目中没有和客服系统完全一样的项目。3.1 用 EET 走一遍第一步收集历史项目数据。先把历史项目按技术栈、模块数、接口数、页面数、参与人数、测试周期、联调天数、缺陷数整理成一张表。不要只收集“看起来漂亮”的项目还要把延期项目、失败项目、中途砍需求的项目也放进去否则样本偏差会很大。第二步筛选相似项目。客服系统重构涉及权限模块、实时消息、异步任务、报表模块。拿这些维度去匹配历史项目。如果完全匹配不上就找相近的有一个历史项目做过工单系统消息链路类似另一个项目做过数据大屏报表模块类似。把这些项目作为类比样本。第三步校准影响因素。历史项目可能没有做过真正的异步任务队列当前客服系统涉及第三方机器人连接复杂度更高。这时需要把接口数量、异常分支、并发量等因素纳入修正系数。比如基础人日按相似项目取中位数再根据实时消息和第三方依赖复杂度乘以 1.2 到 1.5。第四步输出估算区间。不要只写一个“ 25 人日”。要写成“如果沿用现有团队、不引入消息中间件预计 25 到 32 人日如果引入消息中间件并做压测预计 32 到 42 人日。”每一个数字都要配一句“在什么条件下成立”。第五步找两三个资深同事独立看一遍。如果独立估算的结果偏差超过 30%回去检查样本和修正系数如果偏差在 20% 以内说明这个区间基本可用。注意EET 这一步只能回答“大概率需要多少人日”不能回答“这些天到底花在了哪些差距上”。所以下一轮要用 AGR 补上差距清单。3.2 用 AGR 走一遍第一步定义可量化目标。可以把客服系统重构拆成三个子目标平均响应时间从 5 分钟降到 1 分钟以内。第三方机器人故障时系统能持续提供服务不影响核心工单处理。运营报表数据能在 10 分钟内完成同步不再依赖人工导出。每个子目标都配一个验收口径用什么样的压测环境跑多少并发观察多长时间数据从哪里取。没有验收口径的 AGR很容易变成纸上谈兵。第二步盘点现状。逐项列出当前系统离目标还差在哪里。比如请求链路经过多个同步调用导致平均耗时长。第三方机器人接口超时后没有熔断机制。报表模块直接读业务库大数据量查询会拖慢主流程。缺少消息队列积压监控和告警。没有独立的压测环境无法准确评估响应时间。第三步按差距归类。把上面的现状差异归成链路优化、稳定性治理、数据同步、监控告警、测试环境建设。每一类都要有一个责任人视角但不一定现在就指定人。第四步从差距生成行动清单。例如在消息处理链路上引入异步队列把非核心通知类请求改成异步处理。给第三方机器人调用增加超时和熔断策略失败时切换到备用通道。把报表模块改造成读取只读副本避免影响主流程。配置队列积压监控和告警规则。搭建独立压测环境编写压测脚本。第五步做闭环验证。检查每一条行动是否能至少消除一条现状差异。如果有一条行动找不到对应差距先不要保留因为它大概率是“想当然的优化项”而不是“目标反推的必做项”。3.3 结果怎么判断EET 的有效性看估算区间是否覆盖真实消耗。项目结束后把实际人日和估算区间对比。如果实际数字经常落在区间之外说明样本或修正系数有问题需要回来修正方法论本身。AGR 的有效性看行动清单是否闭环且可验收。每个差距都有对应行动每个行动都有明确的完成标志。如果拆出 50 个任务但没有人说得清“做完之后目标是否达成”说明差距拆解仍然停留在表面。两种方法合起来跑才能既知道要做哪些事也知道这些事大概需要多少资源。4. 怎么选型判断标准、组合用法和常见误区4.1 选型判断表实际使用时可以按照下面这张表快速判断当前条件推荐方法理由历史数据充足目标模糊EET 先估量级再进入目标细化先把资源边界定下来避免后面失控历史数据不足目标清晰AGR 先拆任务再用单点经验补量级目标拆解不依赖历史样本排期可以后续估算历史数据充足目标清晰AGR 拆范围EET 估量级两个方法互补可追溯性最好历史数据和目标都模糊先补最小样本或先做目标对齐不要直接排期输入质量不够时任何方法都会失真这里有个容易被忽略的点EET 并不等于“有历史就行”。历史项目是否真的完整记录数据维度是否统一直接决定 EET 能不能用。我见过不少团队说“我们有很多历史项目”但真去拉数据时发现工时表只记录到“提交测试”没有“联调改动”和“上线后修复”的部分这种数据只能用来做趋势判断不能做精准外推。4.2 组合用法先AGR拆范围再EET估量级最稳妥的组合方式是“AGR 拆范围EET 估量级”而不是反过来。先讲一个反例团队先用 EET 根据历史项目估算出一个总人日比如 40 人日然后用 AGR 去拆任务。结果拆出来的任务列表和当初估算总人日时的假设完全对不上因为估算时参考的历史项目里没有现在这种第三方机器人依赖。这时候总人日就悬空了讨论时只能重新回到“是不是该加 5 天”这种没有依据的博弈。正确的顺序应该是用 AGR 把目标拆成三到五个可衡量的子目标。每个子目标下列出差距清单。对每个差距项或行动项用 EET 从历史项目里找类似工作项做估算。把所有估算区间汇总再根据团队人员水平、技术熟悉度、外部依赖做整体校准。最后请至少两名同事独立复核估算区间确认偏差范围。这套组合的好处是每一个估算数字都能追溯到“它是在解决哪个差距”。评审会上有人质疑“为什么这里要 5 人日”你可以直接说“这个差距是当前状态到目标状态之间缺少异步队列历史项目里类似的消息改造工作耗时 4 到 6 人日。”这个逻辑比单纯拍一个数字清晰很多。4.3 常见误区误区一EET 等于拍脑袋AGR 等于更高级。实际上 EET 需要高质量历史数据AGR 更依赖目标质量。两者都需要严格过程不存在谁自动更优。误区二先用 EET 估总人日再让 AGR 去拆任务。这个顺序容易造成估算和任务脱节。越早把目标和差距拆清楚后面的估算越可靠。误区三把 EET 的估算区间当成上线日期承诺。EET 给出的是决策输入不是合同日期。尤其是业务方追问“到底能不能 30 天上线”时应该回答“在什么条件下能在什么条件下不能”而不是给一个看起来确定的数字。误区四只跑 AGR 不校验工作量。任务拆得很细每个任务要不要人日完全不知道最后排期仍然失控。AGR 只解决“做什么”不解决“多贵”“多贵”必须交给 EET 或者更细粒度的估算方法。5. 落地时会踩的坑现象、原因和排查顺序5.1 常见现象对应表实际推进过程中团队很容易遇到下面这些情况现象可能原因优先排查点EET 估算结果总被业务质疑样本口径不统一或没有给出假设条件查看是否给出了区间是否写明了适用条件AGR 拆出一堆任务排期仍然失准待办与差距没有一一对应或缺少工作量估算验证每条待办是否对应一个具体差距EET 估算总是偏乐观历史数据本身被赶工加班污染或只选了表现好的样本检查样本是否包含延期、失败、中途变更的项目AGR 目标反复争执目标没有量化或目标之间互相冲突先把目标写成可验收的指标再开会团队争论方法谁对谁错混淆了“量级估算”和“任务拆解”先明确当前会议要的是哪一种输出5.2 排查顺序先看问题再看输入很多人一遇到结果不准第一反应是换方法。其实多数问题不在方法本身而在输入质量和使用顺序。我建议按这个顺序排查先确认这次评审要回答的问题是什么。是“大概多少工作量”还是“要做哪些事情”。如果两个问题混在一起先花 10 分钟把它拆清楚。再确认输入质量。EET 看历史项目记录是否完整AGR 看目标描述是否可度量。输入不干净过程再好也没用。再确认输出质量。EET 输出的是不是“区间加假设”AGR 输出的是不是“任务加验收口径”。如果只有单一数字或一批没有验收标准的待办说明执行过程走了样。最后检查操作顺序。有没有先拆目标再估量级估算时有没有做独立校准差距清单有没有做到闭环很多看起来像“方法不对”的问题最后都出在同一个地方输入材料没有处理干净或者团队根本没有确定要什么输出。5.3 复盘检查清单项目结束后我建议用下面这份清单做一次简短复盘实际人日和 EET 估算区间相比是偏高还是偏低哪些偏差来自历史数据缺失哪些偏差来自需求变更AGR 拆出的行动清单里有多少任务真正落地了有没有任务当时拆得出来但后来发现和目标没有直接关系下一次评审时至少要补充哪一类数据或哪个维度的目标描述这份清单不需要很长但每一条都要落到具体项目上才有复盘价值。6. 一些关于边界的实话EET 的边界在于历史数据只是一个参考外部环境变化、团队人员变化、技术栈更替都会让经验失效。如果历史项目与当前任务差异过大EET 的区间会从“窄而清晰”变成“宽到没有意义”。这时候不要硬套历史数据不如先用 AGR 把未知项找出来再回到历史里找局部相似点。AGR 的边界在于目标清晰是前提。但很多探索型项目目标本身就是模糊的比如“我们要引入一套新的消息中间件但还不确定它是否适合客服场景”。如果强行 AGR容易把“不知道”伪装成“差距”拆出一堆看似合理但没有实质内容的任务。探索阶段更适合先做原型实验把目标和真实反馈校准之后再回到 AGR 做任务拆解。我在实际使用时会把两者当成两个互补工具而不是非此即彼的选择。先跑一个最小样本比如用上一个项目的一条迭代记录分别用 EET 和 AGR 对同一个小需求做一次试验。EET 帮你校准历史数据的口径和估算区间AGR 帮你验证目标是否能被拆成闭环任务。这个过程做一遍团队就能直观感受到两种方法的差异不会在正式评审时吵成一团。真正落地时最该盯住的不是“谁更先进”而是输入是否干净、输出是否可验证、评审会是否用对了输出。EET 和 AGR 都只是工具能稳定解决“量级”和“差距”这两个问题就已经很有价值。