Scrum 的问题所在 [译]
最新观点：Scrum 存在问题
如果你正在阅读这篇文章，你可能有过遵循 Scrum 方法工作的经验。如果没有，那请跟我一起来了解一下。
首先，让我们从基础知识说起。
什么是 Scrum？
Scrum 是一种敏捷（Agile）项目管理系统，它旨在“帮助团队协作地逐步创造价值”。
引用自 Scrum.org
敏捷是一种软件开发的方法论，它强调灵活和迭代。如果你还未了解敏捷的宣言(2001)，可以将其看作是软件开发中应遵循的一套简洁有效的实践准则。
敏捷并不是软件开发的绝对“圣经”，它不是一套固定不变的规则，也不仅仅是 Jira 上的一系列任务或是在公司中忙碌的敏捷教练。
顺便提一下，所有的定义都有其局限性。（请再想一想这句话）
我欢迎对我对 Scrum、敏捷等术语的定义提出批评。但我希望你能在评论前仔细阅读整篇文章。
理论与实践的差距
敏捷与瀑布模型（Waterfall）是截然不同的两种软件开发方法。瀑布模型是直到 90 年代为止普遍采用的传统方法。
- 敏捷强调迭代和灵活性，而瀑布模型则是按顺序逐步进行。
- 敏捷追求精简高效，瀑布则显得笨重缓慢。
- 敏捷注重代码优先，瀑布则重视文档编写。
虽然我可以继续详细比较这两种方法，但简而言之，敏捷和瀑布的核心区别在于它们对软件开发流程的不同处理方式。
敏捷的出现源于对改善软件开发过程的渴望，它是一场革命，将软件开发从一个按部就班的噩梦转变为许多工程师，包括我自己，今天热衷实践的一门学科。
尽管我尊重那些理论化敏捷的专家们，但我认为真正的问题在于 Scrum 在现实世界中的应用，尤其是在不够理想的环境中的实施效果。
仪式
在 Scrum 这个敏捷框架中，最核心的概念是冲刺。冲刺指的是固定的、短暂的工作周期（通常是两周）。在这段时间里，除了日常的开发活动，Scrum 团队还需要参与一些特定的仪式。
《Midsommar》，一部不容错过的电影，推荐加入观影清单！
旁注：我个人不太喜欢用“宗教仪式”这样的词汇来形容这些会议，但这就是它的名字。
- 冲刺计划会议 — 正如字面意思，这是一个较长的会议（最多四小时），在会议中，团队会计划接下来一个冲刺周期内需要完成的任务或用户故事，整个 Scrum 团队都会参与。
- 每日站会 — 这是一个每天举行的、简短的会议（约 15 分钟），在会议中，小型开发团队（大约 3 到 7 人）会汇报他们的进展，突出任何阻碍问题，但不深入细节。比如，你可以在这个会议上提出和 Alice 单独讨论服务器端缓存的问题，或者和 Bob 讨论为何日期参数是字符串而不是 Unix 时间格式。
- 冲刺执行阶段 — 团队成员将自主领取并完成任务，并通过非正式会议、结对编程、代码审查以及大量从 ChatGPT 获取的代码示例来解决潜在的问题。测试、质量保证、文档编写，以及运维/DevOps/基础设施任务，都是执行阶段的一部分。
- 冲刺回顾会议 — 这是一个较长的会议（持续 1 到 2 小时），目的是向项目的利益相关者展示冲刺的成果，并从他们那里获取反馈。
- 冲刺回顾总结 — 这是对已完成工作的内部分析，重点是识别并解决障碍，以便在未来的冲刺中改进，并在流程、实践和工具方面实现持续进步。
- 待办事项梳理 — 这不算是正式的仪式，但它是团队在冲刺期间需要花费大约 10% 时间来进行的活动，主要包括：细化任务、解释、发现漏洞、定义完成标准并共同确定任务的优先级。
人员
Scrum 框架中的关键角色包括：
利益相关者 — 他们对项目有直接利益，希望得到通知、参与其中，并从最终产品中获益，不论这个“产品”在你的公司中指什么。其实，如果你把定义扩展得足够广，任何东西都可以被视为产品。 他们可能是终端用户、其他团队或甚至是另一家公司。
产品负责人 — 应该扮演沟通利益相关者和产品开发者之间的桥梁，将需求转化为具体的工作项，理解业务领域和商业价值，管理待办事项清单，以及最大化交付价值。
开发者 — 应该是负责具体操作工作的人，包括但不限于软件开发，他们以自主管理的方式工作，并能够做出技术决策来引导产品朝正确方向发展。
Scrum 主管 — 应负责促进沟通、监控进度、识别和评估风险，以及教育和指导团队有效运用 Scrum 方法。
啊，这正是 Scrum 主管那著名的能同时处理多个任务的生产力。
#敏捷开发（Scrum 已经失效了？
等等，这么说，这些繁复的仪式和角色需要一个 认证的 或 专业的 Scrum 大师来指导？
哦，多么纯真的想法。简而言之，答案是否定的。
为什么呢？
因为我们生活的世界并不完美，理论上的东西往往无法像书本上写的那样实现。
从前几段的关键词汇中，你可能已经有所感觉，但实际发生的情况是：
又一个 Jira 工单？让我们开始行动！
无论使用哪种工具，计划过程都漫长，最终只会得到一堆预设的、用故事点（story points）衡量的任务。这些本应帮助理解任务复杂度的故事点，却被用来计量时间。
真是精明，夏洛克！你的团队现在更专注于填满日程，而不是交付功能，你甚至无法测量他们的效率。理论上，效率应该能帮助了解，基于过去的冲刺，团队能交付多少相对产品进度。
那么，为什么我们不再使用Fibonacci 序列呢？或者尝试一下规划扑克怎么样？
我，听说你的公司用 Fibonacci 序列来估算任务量
别急着辞职。我有一个绝妙的解决方案，真的！我们只需要给每项任务分配一个类似衣服尺码的标准来简化估算。多么聪明的想法。我们只需要讨论一下，那个 gRPC API 究竟是大号（L）还是中号（M）任务，与此同时，我们实际上在浪费的是选择这种细微测量方法上的宝贵时间。
想象一下这样的场景：产品负责人和敏捷大师都不在办公室。一个人生病请假，另一个享受着应得的带薪休假。你的团队还会按时参加站立会议吗？我表示怀疑。
什么？你把个人效率作为每次冲刺的目标？那就做好迎接糟糕代码和不完整但自动化的测试的准备吧。一旦你设定了静态指标，人们就会找到方法绕过它。而且，再也没有结对编程和团队协作了，每个人都忙着为了那些诱人的故事点而奋斗。
一项任务太复杂无法拆分，并且需要跨团队深入分析好几天？没人愿意主动承担这个任务，因为他们害怕承担责任，看起来效率低下。
为一些 10 分钟的小任务，比如格式化文件、更新链接、移除无用导入编写任务单？欢迎来到任务驱动开发，连整理清理都变得如此漫长。
再来看一个常见的情况：冲刺期间有人发现了一个 bug。休斯顿，我们有问题，找谁商量呢？
团队领导？敏捷大师？技术领袖？产品负责人？服务所有者/经理？项目经理？是的，我亲眼见过一个运行敏捷开发的团队里居然有项目经理，不要问我为什么，这是真实发生的事。
你要找谁来解决问题？
这种分裂的领导真是够了！所谓的“自我管理团队”呢？
想象一下，你已经与所有这些人沟通了你的问题，然后猜猜他们需要多久才能弄清楚自己的责任部分并给出解决方案。
你，从会议室出来，对解决方案仍一头雾水
祝你好运，在下次冲刺中再见！
Scrum 经常被管理层看作是提升生产力的万能药，认为它能解决任何团队的低效问题。但事实上，情况并非如此。
Scrum 并不是团队绩效问题的灵丹妙药。
一个本就效率低下的团队，在采用 Scrum 后可能会变得更慢。相信我，看着那张痛苦的进度耗尽图会让人感到沮丧。
这是一张 — ??? 现在我已筋疲力尽 — 的图表。
哈哈，我是说进度耗尽图，这是个小幽默。
如何让 Scrum 发挥作用？
我相信有方法可以做到，但我还没见过哪个工程师对他们公司的 Scrum 实施感到满意。
没错，就是这样。
工作方式应该由团队成员在团队层面上来定义，而不是公司上层决定。
这样一来，敏捷开发的理念就真正实现了！
- 交付间隔时间明显缩短，变得更加灵活。不再是那种被称为“冲刺”的对时间的无休止追赶，这样软件的质量自然会大幅提升，因为对项目范围的任何调整都不再受到严格时间安排的限制。
- 估算工作基于团队过往的经验，更加直观，并在团队层面得到确认。在软件开发领域，时间应被视为一个相对而不是绝对的概念。
- 计划制定不仅仅涉及管理层，还包括实际执行工作的人员。他们可以一起讨论计划中的问题，并在还有时间优雅处理时发现潜在的缺陷。工作不是由领导分配，而是由团队成员根据自己的判断来承担。
- 执行过程是一种赋权行为。每位开发者都根据自己的经验拥有一定的技术自主权，并对产品、同事及利益相关者承担商业责任。通过减少依赖性，开发团队变得更加自主，速度也显著提升。日常更新真实反映了问题追踪器的状态，信息流通畅通，文档得到及时更新。
- 每日的团队同步会议简短高效，真实反映了当前工作进度。没有人觉得有必要在待办事项中添加一些不重要的任务，或者对自己的进度进行虚假报告。
- 遇到的障碍由团队内部共同解决，无需与复杂的管理层结构打交道。团队对每一个决策承担责任，不论结果如何。
- 成果的分享是透明的，甚至对那些难以沟通的利益相关者（通常是关键客户）也能清晰展示项目状态。目的是为了获取真实的反馈，而不仅仅是赞赏。
- 对已完成工作的回顾是诚实且不指责的，这样团队成员就不再需要篡改数据以使成果看起来还不错，而可以开始专注于解决遇到的问题的根源。
- 待办事项的管理终于成为了一个团队共同的责任和持续的努力。这种简单（但并非微不足道）的变化将对团队产生深远的影响。
解决之道
- 认真总结经验，以清醒的头脑回顾那些行之有效的策略，探讨如何进一步优化，并对团队的出色表现表示赞赏。当然，你还需要反思哪些地方出现失误，原因何在，以及改善的方法。
- 主动征求建议，而不仅是反馈。人们乐于提供建议（有时甚至不需求助），这有助于避免毫无意义的“一切良好”或“全然糟糕”的反馈。当你得到一个实用的建议时，可以立即付诸行动。向别人征求建议，会让他们感到自己更值得信赖，而不仅仅是被动提供反馈。
- 信任你的团队，保持诚实，不要过度干预。尝试更多的委托和灵活应对，你会发现，给予团队自由会营造一个更健康的环境，让大家更容易学会负责任，即便是在上级（比如管理层）不在场的情况下。
- 意识到指标有时会误导，如果你不批判性地分析它们，就容易陷入确认偏误。这里有一句我非常喜欢的名言：“只要对数据施加足够的压力，它最终会招认一切” —— Ronald H. Coase。
- 鼓励犯错，勇于承担并修正错误，不必担心绩效评估。不要一味追究上一阶段犯错的开发者，这只会影响他们的表现，并创造一个压抑的工作氛围。我们应该分析错误本身，而不是批评犯错的人。如果你看到开发者正面临困难，不妨关心一下他们的状况，给他们一些调整时间，然后观察下一阶段的成果。
我知道你们中的一些人可能会认为我所说的全是废话。如果你此时写下愤怒的评论，我也不会责怪你。
现在，让我们重新审视这份宣言：
个体和互动 优先于流程和工具
有效的软件 优先于全面的文档
客户合作 优先于合同谈判
适应变化 优先于遵循计划
这次你不能说标题是为了吸引点击：
Scrum 真的有其不足之处。
除非你让它变得灵活和敏捷。
这意味着：要具有弹性、适应力强、注重协作、围绕人员建立，并专注于成果而非仅仅是指标。
广而告之！（可跳过）
我目前为需要云原生咨询（DevOps/Cloud/Kubernetes）的公司和寻求顾问的初创企业提供工程服务。如有兴趣，请通过LinkedIn联系我，即使只是推荐我给您认识的某人。
对于每一次成功的推荐，我将提供首份发票支付金额（不含增值税）的 10% 作为现金奖励*或捐赠给您选择的慈善机构 💰
我还为个人提供职业辅导和指导，如果您想深入了解软件工程、DevOps、云计算、Kubernetes，或者需要我审阅您的简历/LinkedIn 或职业路径，请查看我的 MentorCruise 个人资料！
*参与推荐的人不能是推荐公司的决策者或大股东。例如： - 投资者推荐他们投资的一家初创公司 ❌（你不需要这笔钱！） - 某公司 CEO 推荐我给特斯拉 ❌ —— 抱歉，伊隆。 - 非 C 级或高管级别的员工推荐我给他们的公司 ✅ - 谷歌的 CEO 推荐我给微软 ✅
欢迎评论、分享并@我来讨论！找到我的所有链接 👉 这里。
到此为止，再见 :)