Scrum做好，效果非常好；Scrum做不好，会损害产品和团队士气。
译自 Scrum Sucks Because You’re Doing It Wrong，作者 Ben Grimwade。
我能听到你在对着屏幕大喊。
“我用过Scrum，它糟透了。它增加了太多结构，太多会议，并且重视指标而不是实际工作。”
大多数人不喜欢Scrum，因为他们把它当作一个待办事项清单，而不是按照其本意——一种实现增量交付 的思维方式来使用。
在这篇文章中，我将重点介绍我听说和看到的Scrum中最常见的问题，并希望能给你一些切实可行的解决方法。
Scrum的核心是一种敏捷方法，它专注于增量交付。
理想的Scrum团队
- 产品负责人: 这是决定你所从事产品方向和功能集的核心人物。他们是行业专家，对产品需要达到的目标有清晰的认识。他们与高级管理层、销售和客户密切合作。
- Scrum主管: 团队的组织者。Scrum主管确保需求被准确收集，遵循Scrum流程，并迅速处理任何障碍。他们还确保所有Scrum仪式都得以举行并有所帮助。
- 开发团队: 一个由跨职能、自组织工程师组成的团队。编写代码的人。
- QA: 分配给Scrum团队的专业测试人员。
Scrum仪式一览
- Sprint: 通常为两到三周的一段时间。这是故事的开发开始和结束的时期。
- 计划会议: Sprint开始之前的会议，团队在此决定将要处理（并且重要的是，完成）哪些故事。
- 每日站会: 一个大约15分钟的每日会议，每个团队成员都会讨论“我昨天做了什么”、“我今天将做什么”以及“任何障碍”。这是一个简短的状态会议，以确保一切顺利进行。
- Sprint评审: 在每次评审结束时，团队将向产品负责人和其他利益相关者演示他们已完成的工作。
- Sprint回顾: 团队回顾之前的Sprint，讨论哪些方面做得很好，哪些方面可以改进。
记住，Scrum的核心是承诺在一定时期内交付一部分工作。Scrum提倡专注于少量、具体的作业（故事），每个人都在一小段时间内（Sprint）一起工作（Swarm）。
Scrum通过回顾促进持续改进，并通过速度提高计划的准确性。
就是这样。这就是Scrum的全部内容。
在我看来，工程师讨厌Scrum。他们认为它是一种浪费时间的活动，它将他们束缚在武断的时间表上，并增加了毫无意义的会议。
如果我把它概括成以下一句话，你认为有人会不同意这是一个好主意吗？Scrum是一种更准确地估算工作量，同时获得关于产品的定期反馈并改进团队的方法。
我个人认为这是一件好事。
部分采用
我曾经在一些团队中，他们以前使用过一些瀑布式规划方法，并保留了大部分瀑布式实践，但现在，我们每两周举行一次Scrum仪式。
问题在于瀑布式和敏捷在规划和方法上有所不同。
瀑布式预先进行规划，并假设交付是固定的。敏捷更像是一种“边走边计划”的方式，交付可以根据利益相关者的投入而在一轮轮Sprint中发生变化（核心交付保持不变，但细节可能会改变）。
不可能将瀑布式项目计划补充到敏捷项目计划中。
如果你已经有一个项目的瀑布式计划，你需要做以下两件事之一：
- 通过使用现有的瀑布式计划交付项目，看看是否可行。
- 完全采用敏捷，重新启动项目，专注于增量交付。对变化持开放态度，并在每个Sprint中交付有价值的东西。
团队设置不正确
Scrum 的一个关键方面是拥有一个完全跨职能的团队。Scrum 需要产品人员、QA、Scrum Master 和一些工程师。我经常听到人们告诉我他们使用 Scrum，他们的团队只有四到八名工程师，而缺少其他角色。
拼图需要所有碎片。
理想情况下，一个团队应该为每个角色配备专门的专家。但是，如果没有足够的预算，可以通过指定工程团队成员担任每个角色并在该项目中负责来妥协。
例如，产品知识最丰富的工程师在仪式期间担任产品角色，最关注测试的人员成为 QA。
“无意义的”每日站会
每日站会是一个大约 15 分钟的会议。仅此而已。每个成员都会谈论他们的“昨天、今天、阻碍”。当每日站会使用不当时，它们可能会变成冗长而拖沓的事情。
解决方案是什么？你需要一个强大的 Scrum Master 来让会议保持正轨。
根据我的经验，当谈话过于深入时，简单地说一句“我会记下我们需要在另一个会议上对此进行跟进”就足够了。
只要人们知道他们的担忧稍后会得到解决，他们就会没事。不过，请务必预订这些后续会议！
指标超载
Scrum 的速度源于统计数据。
在规划你的故事时，作为团队，你们会赋予它们名为“故事点”的神奇属性，这些属性在你的团队之外毫无意义。故事点是一种团队分配工作相对大小的方法。
一旦你这样做一段时间后，你就会开始了解团队的速度。
你可以准确地预测你的团队在一个冲刺中可以完成 30 个故事点的工作。只要你的团队评估了工作，这应该是准确的。
只有尊重速度，它才会准确。Scrum Master 必须在冲刺开始之前审查计划和故事点。这会准确地告诉你你在特定时期交付了多少点。通常，你希望将你每个冲刺交付的故事点平均值计算大约五个冲刺。这将给你一个相当准确的数字。
确保始终由同一个人分配点数。如果你的团队构成每个冲刺都在变化，那么这些数字就失去了意义。
回顾会议
回顾会议应该突出团队流程的积极方面和消负面。你应该从回顾会议中学习。
但是，如果你在每个冲刺结束时都进行回顾会议，却从未采取任何行动呢？如果你从未对你在回顾会议中获得的信息做任何事情呢？这是毫无意义的，也是我在团队中看到的常见陷阱！虽然每两周进一个房间抱怨一次可能会令人感到轻松，但如果一段时间后，这些抱怨变成了噪音，因为从未对它们采取任何行动，人们就会（理所当然地）感到沮丧。
确保你对回顾会议的要点采取行动。如果不这样做，你的团队将错过举行会议的好处。
基于产品的评审
工程师应该进行评审，向利益相关者展示其冲刺工作的价值。
他们应该向利益相关者展示已完成的工作，并获得关于他们在冲刺中做的是“正确”还是“错误”事情的反馈。
通常情况下，评审会变成产品负责人进行的展示，以及产品和工程之间单向的沟通。虽然这可能会有所帮助，但这并不是评审的目的。
让评审重点关注你在过去冲刺中作为工程团队交付的内容。获得对该工作的反馈以及下一个冲刺中即将发生的事情的反馈，然后保持原样。
我在敏捷、瀑布和“没有真正计划”的工作场所工作了 20 年。
如果做得好的话，Scrum 效果非常好。做得不好的 Scrum 会损害产品和团队士气。
有很多资源可以学习 Scrum 和敏捷，所以在完全放弃公司中的 Scrum 和敏捷之前，请首先尝试解决我在这里提到的陷阱。