为什么开发者讨厌 Agile：真实世界的主要原因

Source: Dev.to

我在初创公司、企业以及介于两者之间的各种团队中，都听到开发者说出这句话。Agile 的初衷是为了减少官僚主义、提升协作，并帮助团队更快地交付更好的软件。然而，对许多开发者来说，Agile 已经成为 压力、挫败感和倦怠 的来源。

在与多个工程团队合作并与无数开发者交谈后，我注意到一个模式：

大多数开发者并不讨厌 Agile 本身，他们讨厌的是 Agile 在现实中的实施方式。

下面是开发者 讨厌 Agile 的最常见原因的拆解，基于真实经历、数据和实际案例——以及针对每个问题可以采取的对策。

1. “我花在会议上的时间比写代码的时间还多。”

• 每日站会、冲刺计划、待办事项梳理、回顾会、冲刺评审、临时同步……会议清单永无止境。
• 本应“轻量”的会议却变得压倒性。

数据点： 2023 年 Atlassian 报告发现，普通员工平均每月参加 62 场会议，而开发者始终将会议列为最大的生产力杀手之一。

为什么有害

• 深度工作需要长时间的、不中断的专注。
• 上下文切换会消耗精神能量。
• 许多会议重复相同的信息。

真实案例

我合作的一位前端开发者记录了两周的时间分配：

他感觉自己更像是“状态报告员”，而不是工程师。

该怎么做

• 将站会限制在 10 分钟内。
• 取消没有明确议程的会议。
• 在 Slack 或 Jira 中使用 异步更新。
• 合并重叠的仪式（例如，待办事项梳理 + 冲刺计划）。
• 记住：敏捷应当支持开发，而不是取代开发。

2. 缺乏信任与自主

Agile倡导信任和自主，但许多团队却出现相反的情况。

症状

• 开发者感到被持续监控：

  • 故事点被痴迷式追踪
  • 速度在团队之间进行比较
  • 需要每日“进度说明”

• 与其赋能，反而受到压力。

成因

• 管理者将 可视性 与 控制 混为一谈。
• Agile指标被用作 绩效评估工具 而非 改进工具。

期望的文化

• 对解决方案的所有权
• 自由实验
• 信任专业判断

更佳做法

• 使用指标来发现瓶颈，而不是惩罚人员。
• 衡量结果（客户影响），而非产出（故事点）。
• 让团队自组织。

当开发者感受到信任时，质量自然会提升。

3. 单个冲刺中的工作过多

Agile 鼓励小而增量的工作。实际上，开发人员经常同时处理：

• Bug 修复
• 新功能
• 重构
• 技术债务
• 支持工单

全部在同一个冲刺中。

任务切换的成本

Research from the American Psychological Association shows that task switching can reduce productivity by up to 40 %.
美国心理学会的研究表明，任务切换可能导致生产力下降最高 40 %。

实际引用

“我开始构建一个 API，然后被拉去处理生产问题，接着被要求估算故事点，再去审查 PR。当我回来的时候，我已经忘记自己在做什么了。” – 后端工程师

缓解措施

• 专注日（无会议）。
• 单独的 bug 修复冲刺 或轮换。
• 限制在制工作 (WIP)。
• 积极保护开发者时间。

流畅状态是打造优秀软件的所在。

4. 文档不足与验收标准

敏捷宣扬“工作软件胜过完整文档”。许多团队误解为 “根本不写文档”。

典型用户故事

“作为一名用户，我想要一个仪表盘，以便查看我的数据。”

仅此而已——没有验收标准、边缘情况或用户体验预期。开发者只能猜测，利益相关者随后改变期望，导致返工激增。

优秀文档的样子

• 明确的验收标准
• 示例输入与输出
• 设计参考
• 非功能性需求（性能、安全等）

轻量级文档并不等于零文档。

5. 累积技术债务

短冲刺 + 交付功能的压力 = 技术债务快速累积。

开发者看到的情况

• 快速的临时方案
• 跳过的测试
• 过时的库

产品优先级常常把清理工作推迟到“以后”。以后永远不会到来。

后果

• 构建变慢
• Bug 增多
• 开发者对代码库失去自豪感
• 速度最终下降

解决方案

• 分配 20‑30 % 的冲刺容量用于技术债务。
• 像跟踪功能一样跟踪技术债务。
• 庆祝重构成功。

健康的代码库能保持速度；混乱的代码库会毁掉速度。

Source: …

6. 不切实际的冲刺承诺

Agile 假设生产力是稳定且可预测的，但 人类并不具备可预测性。

现实因素

• 状态不佳的日子
• 家庭紧急情况
• 学习曲线
• 心理疲劳

冲刺承诺很少考虑这些因素，导致开发者即使努力工作也会感到“落后”。

建议

• 将估算视为预测，而非承诺。
• 在冲刺中预留缓冲。
• 关注可持续的节奏。

精疲力竭的开发者无法打造出优秀的软件。

7. 规模化敏捷

Agile 最初是为小型跨职能团队设计的。大型组织常常尝试使用复杂的框架来扩展它，这会导致：

• 更多角色
• 更多仪式（ceremonies）
• 更多工具

讽刺的是，这重新制造了 Agile 试图消除的官僚主义。

原始理念的资源

• Agile Manifesto
• Scrum Guide
• State of Agile Report

关键要点： 扩展 Agile 应该 简化 工作，而不是使其复杂化。

8. 行动清单（适用于所有人）

无论你是开发者、经理还是团队负责人，都请自问：

1. 哪项敏捷活动真的对我们有帮助？
2. 淘汰或减少低价值会议。
3. 推动更明确的需求。
4. 倡导专门的技术债务处理时间。
5. 保护专注时段。
6. 把人当作人，而不是资源。

小的改变会累积成巨大的改进。

TL;DR

• 开发者并不讨厌敏捷；他们讨厌糟糕的敏捷。
• 当正确实施时，团队会感到被赋权、富有创造力并为自己的工作感到自豪。
• 当实施错误时，会感觉像是带有额外步骤的微观管理。

敏捷本身并不是罪魁祸首。错误的解读、僵化的流程以及管理层的误用会把本来灵活的框架变成令人沮丧的系统。

如果我们回归敏捷的核心价值——信任、协作和简洁，就能重新实现它的承诺。

- y, and sustainable pace — developers won’t hate Agile anymore.