Scrum 的问题所在 [译]
内容提要
Scrum是一种敏捷项目管理系统，但在实际应用中存在问题。团队可能过于关注任务完成而忽视交付功能，也可能出现领导分裂和任务驱动开发的问题。要让Scrum发挥作用，需要团队成员定义工作方式，信任团队，总结经验并改进，主动征求建议，意识到指标的局限性，鼓励犯错并修正错误。
延伸解读
当仪式取代了交付
文章指出，Scrum 的仪式和角色在实践中容易异化为任务驱动：团队忙于填写 Jira 工单、估算故事点，却忽视了真正交付功能。故事点本应衡量复杂度，却被用来计量时间，导致成员为填满日程而工作，甚至出现为 10 分钟小任务开单的荒诞现象。这种本末倒置让效率不升反降。
指标陷阱与微观管理
作者警告，一旦设定静态指标（如个人效率），成员就会寻找绕过方法，破坏结对编程和团队协作。同时，分裂的领导结构——产品负责人、Scrum 主管、技术领袖等多头管理——让问题解决变得迟缓。Scrum 并非万能药，低效团队采用后可能更慢，进度耗尽图便是明证。
让团队定义工作方式
文章认为，Scrum 要发挥作用，工作方式应由团队层面定义，而非上层强加。估算应基于团队经验，计划需执行者参与，障碍由团队内部解决。通过信任、委托和诚实回顾，团队能更自主、透明地分享成果，并主动征求建议而非被动反馈，从而避免指标误导和指责文化。
Q&A
Scrum 在实际应用中常见的问题有哪些？
团队可能过于关注任务完成而忽视交付功能，出现领导分裂和任务驱动开发的问题；Scrum 常被管理层视为提升生产力的万能药，但实际可能使本就低效的团队更慢。
Scrum 中的冲刺包含哪些仪式？
冲刺计划会议、每日站会、冲刺执行阶段、冲刺回顾会议、冲刺回顾总结，以及待办事项梳理（非正式仪式）。
Scrum 框架中的关键角色有哪些？
利益相关者、产品负责人、开发者和 Scrum 主管。
如何让 Scrum 真正发挥作用？
团队成员应定义工作方式，信任团队，总结经验并改进，主动征求建议，意识到指标的局限性，鼓励犯错并修正错误，共同承担待办事项管理责任，促进透明成果分享和诚实回顾。
为什么说 Scrum 不是解决团队低效的灵丹妙药？
因为 Scrum 经常被管理层误认为是提升生产力的万能药，但一个本就效率低下的团队在采用 Scrum 后可能会变得更慢，且实施效果受环境和不理想因素影响。
敏捷与瀑布模型的核心区别是什么？
敏捷强调迭代和灵活性，追求精简高效、代码优先；瀑布模型按顺序逐步进行，显得笨重缓慢、重视文档编写。核心区别在于对软件开发流程的不同处理方式。
