Scrum 是一种广泛用于开发和交付数字产品的流行方法。最常见的 Scrum 形式是一系列不断耗尽精力的冲刺，没有为如持续研究这样的长期投资留出空间。不一定非得这样。Scrum 可以带来能量，而不是消耗它。
我们从一个例子开始吧：
乌塞恩·博尔特是一位不可思议的短跑选手。看他参加100米短跑，就像看到超人飞行一样。他跑起来轻松自如。如果我们让他跑马拉松，他可能会把记录缩短一半。继续冲刺吧，乌塞恩！
想象一下如果我们向博尔特先生提出这样的想法；这位世界冠军最有可能的回答会是：“这样做不仅愚蠢而且危险，你如果继续这样跑，可能会有生命危险”。
事后看来，这样的结论是合乎逻辑的。
为什么大多数公司都在没完没了地冲刺？
在这篇文章中，我会列出为什么连续的冲刺周期是个坏主意的原因，以及你可以尝试的三种应对策略来解决这些问题。
1. 无尽的冲刺会把你累死你再这么拼命跑下去，就会死
—— 假想中的尤塞恩·博尔特，2024年9月
一种流行的产品开发方式是敏捷开发，而最流行的方法是scrum。我合作的所有公司都在某种程度上使用 scrum；要么严格遵守规则，要么宽松使用，或者使用像 SAFe 这样的复杂框架（感到反感）。
对于我经历的所有Scrum变体而言，一个基本的原则是，一个sprint结束，另一个就开始了。永无止境的冲刺。
无休止的冲刺导致了几个相互关联的问题：团队士气下降，质量下滑，脱离实际业务，以及不切实际的预估。
你是否在公司中发现下面这些问题中的任何一个？
（让我们在Medium上做一个小投票：在你遇到的问题上做标记或评论）
- 故事很难评估：需求和验收标准不够清晰
- 令人惊讶的是，团队抱怨需求和验收标准定义得太死板了，由于缺乏灵活性而无法发挥创造力来创造最佳解决方案
- 由于不确定性，团队往往会高估。这导致利益相关者寻找捷径，例如移除争议较大的需求项
- 业务相关方发现很难把需求放进开发环节，开发功能需要很长时间，最终结果与他们的预期不符。不知道具体该说明些什么。
- 相关方过度要求，因为他们要等待很长的时间才能再次轮到他们，这反而加重了其他人的负担。
- 研究和开发之间存在差距。研究人员难以将他们的发现传达给开发团队，而开发团队则感觉像是在没有了解用户需求的情况下盲目进行开发。开发人员没有时间参与像可用性测试这样的研究会议。
- 任务从一个冲刺溢出到另一个冲刺：产生僵尸任务，跟随团队经历多个冲刺
- 团队停止庆祝重要里程碑，因为他们总是在为下一个事情忙碌
- 开发者发现很难将用户故事纳入冲刺中以解决重要问题，如架构更新、单元测试、重构、改进现有功能或仅仅是“思考时间”——因为总是被“业务”要求开发“新事物”所吸引
- Scrum 团队成员在描述工作时会谈到“苦工” 😿
- 因为超出了预期和 sprint 结束时的压力，带着未修复的 bug 发布功能，这样会导致返工，也就是过去 sprint 留下的问题
- 一旦完成，很难迭代功能来纳入学习成果，为最终用户提供最佳影响，因为待办事项列表已经被即将处理的事项填满
- 在 sprint 过程中获得的学习难以应用，因为开发人员正在处理几个月前创建的故事（和设计）
上述问题导致了程序上的争论和推卸责任。有些问题不够重要，有些问题又太小，需要更细致的打磨和完善；设计不应该在一次冲刺中频繁变动，我们需要更灵活地适应变化；沟通不足，会议过多；“业务方”不太理解等。
这可以解决，但先有个问题。
2. 有些事情急不了，比如说持续的研究工作这种事。除了连续冲刺带来的破坏性问题之外，还需要指出一个重要的事实：《并不是所有的活动都适合Scrum这种方法》。
Scrum 需要精准估量的故事。但是这种要求无法满足研究、设计和 IT 架构中的开放式问题。那些需要对齐、反复思考、长期思考和灵活实验的问题。Scrum 并不是为此而设计的。当然，我们可以将这些活动“硬塞”进 Scrum 流程中，通过设置时间限制的冲刺，或让故事跨越几个 Sprints，但很少真正奏效。
在一些公司中，将这种类型的工作放在开发冲刺之外进行，采用非 scrum 的过程，或者相同节奏的并行冲刺。这会在组织中制造孤岛和隔阂，尽管 scrum 的力量在于多学科团队的协作。
我们可以解决所有这些问题，但在介绍我的方案之前，我们还需要一块额外的拼图。
3. 全天 scrum （敏捷开发）是误导一个 “为期三周的冲刺，有8个全职员工” 听起来非常棒，这相当于320个小时的纯开发时间！
难道是吗？
当然不是，绝对没有。没有人每个冲刺周期每周都花40小时编写用户故事。
人们需要休假。他们进行培训。去参加行业大会。参加公司会议。参加Scrum仪式（站会、梳理、回顾）。带生病的猫去看兽医。去看牙医。开会。读研究报告（开玩笑）。在Slack上回答“快速问题”却花了几小时。参加更多的会议。还有（天啊！）喝咖啡聊天气。
这些事情本身并没有什么不好或邪恶。大多数提到的事情都有助于一个好的工作环境。我们可不像机器人。还不是。
Scrum承诺我们的冲刺周看起来是这样的:
但实际上，我们的周看起来更像这样：
那太乐观了，我猜你一天得开好几个会吧！
情况更糟糕了。如果我们一直被打断，就无法专心。每次被打断，都需要重新集中注意力。一个人通常需要大约15分钟才能重新集中注意力。四次30分钟的会议会额外损失整整一个小时的专注时间！
除此之外，打断还影响了合作的可能性。要是我们一整天都在开会，你一半时间，我另一半时间，我们怎么能够一起工作呢。
如果我们把这些团队成员的日程排在一起看，就会发现他们一起处理工单的时间是有限的。
那看起来真是糟透了。但是别担心，解决办法很快就会来了！
我们一直在挖的这个大坑，来个快速回顾Scrum承诺聚焦、责任感、持续改进和协作精神。但实际上我们得到的是：
- 没有冲刺团队内外的人之间的合作
- 非冲刺干扰导致无法集中精力
- 团队内部合作缺失，因成员遭遇不同干扰
- 不适合冲刺的活动（比如持续研究）要么搁置，要么单干，要么被迫套用“用户故事”格式
- 没有持续改进，因为繁重的工作让人难以跳出框架思考
- 无尽的冲刺让团队成员感到失望和恐惧
够了吧，咱们快点爬出来吧！
摆脱无尽Scrum的方法是的，我正在将这篇文章的标题作为副标题重复使用。让我们来看看三种替代无尽Scrum的方法。
首先，让我简单介绍一下自己。我不是反对 Scrum 的人。在我之前是出色的战略产品设计师（现在是自由职业者）——您可以在领英上联系我（https://www.linkedin.com/in/matthijs-zwinderman/）。我在几个项目中当过Scrum 主管。我见过这种方法有效。
当 Scrum 真的管用时，它会变得神奇。一个多功能的团队，成员平等。完全一致的目标。全速前进。看着产品在你眼前成形。激动的泪水不禁涌出，你对人性的信任得以重燃。好吧，也许我不是指那一点，但请相信 Scrum 确实能管用，甚至可以（惊不惊喜）变得有趣。
我们怎么去那儿？
方案1：scrum-daysScrum手册里没有说Scrum是全天候的工作。过程中的仪式确实带来了很多繁琐的步骤，因此理论上讲，每天都全力以赴投入Scrum确实说得通。但实际上，这通常会带来前面提到的问题。
我们可以把一周分成“Scrum日”和“非Scrum日”。每个团队成员只需在一周中的“Scrum日”工作两到三天。
听起来一周三次的 Scrum 比你习惯的五天少了些，但先听我说一下。
Scrum日是什么样的？在这段时间里，在“冲刺阶段”期间，处于“冲刺”状态的人需要遵守严格的“仅冲刺”规则。团队之外的人不得在此期间召开会议或打扰他们提出快速问题，团队成员也不会安排任何非冲刺活动。
这确实很苛刻。但是好处是压倒性的。由于缺乏“外部干扰”，Scrum团队成员们可以连续三天专心致志地工作。没有分心的事，没有任务的切换，团队成员们全天候在一起。这几天里，你就能拥有一支专注、合作且多功能的团队。
公司里的其他同事将需要适应“冲刺日”期间的信息和会议管控。然而，奇怪的是，他们在“非冲刺日”会有更多机会与冲刺团队一起工作。
非敏捷开发的日子（非Scrum日）‘非Scrum的日子’就是一般人所说的‘普通日子’。这些日子是在开会、简短通话、一对一、培训、知识分享、做用户研究、参加研讨会、进行团队建设等等。
而现在，Scrum团队成员也能享受到这些好处了。他们可以有足够的时间来进行长时间的会议和深入思考，进行激烈却富有成效的工作坊，而不用担心冲刺结束的压力。
研究人员可以与开发者合作。测试人员可以花时间改进他们的自动化工具。设计师可以专注于长期深入的研究。架构师可以绘制白板并与利益相关者讨论。
实践中的敏捷日Scrum 日子里，团队有了更多时间来完成任务，以及更多时间来处理其他任务。
关于“冲刺日”的描述，可能听起来有点太乐观了。
我们来看一个例子。看看当我们引入“冲刺日”后，我们的日历会怎样：
我只是重新安排了一下。我没有删除任何会议，也没有缩短它们，我所做的只是对Scrum日进行了组织。细心的读者会注意到，单独处理工单任务这一项已经消失了。这一部分已经被团队合作所取代。
如果我们考虑到上下文切换，新的“冲刺日”实际上只占了之前处理任务时间的超过95%。在理论上，这是一天最多两次会议的例子。五天的工作被压缩到了三天。实际上的好处更大，有时候甚至可以更大。（你有没有哪天会议少于两次的时候？）
当我作为Scrum主管时，我们是这样运作的。开发人员和测试人员每周有三天进行Scrum，而设计师、研究员和产品负责人则每周两天。我是一个严格的Scrum主管，不允许做任何与故事无关的工作。我甚至物理上将团队隔离，让他们在不同的地点工作。
我们度过了美好的时光。在冲刺日，设计师和开发人员一起处理细节。在非冲刺日，开发人员与设计师一起关注大局，并进行研究工作。产品负责人在冲刺日总是可以迅速做出决策，而非冲刺日，则有充裕的时间与其他成员保持一致。
团队合作非常好，速度也快得惊人。
我们做到了移山这样的大事，因此Scrum 日的工作进展得非常顺利。
另一种选择：Scrum框架下的假期即使在没有冲刺日的日子里，团队也会因为高强度的工作压力持续不断而感到精疲力竭。
简而言之，无冲刺的日子有助于保持团队健康，但要发挥最佳表现，还需要更充足的能量补充。
我给你介绍一个叫做“Scrum假期”的概念：每个两到三个冲刺后放一周假。这听起来简直疯狂。甚至比完全不使用Scrum的日子还要疯狂。但这种方法确实管用。
为什么？嗯，当团队专注于任务并付出最大努力时，Scrum 效果最好。在这种情况下，一个两周（或三周）的冲刺可以交付大量产品。这正是Scrum爱好者们常说的例子！但这需要一个充满活力和热情的团队来完成，而不是一个被连续冲刺压垮的团队。
在冲刺假期期间，您的团队可以专注于偿还技术债务，探究问题的根源，或进行用户研究。
当我还是Scrum主管的时候，我们以两轮冲刺为一个周期工作。每个冲刺都有一个特定的目标：一个大型功能或“史诗级特性”，或者故事之间的某种共同主题（例如，“寻找并修复错误”，“无障碍性改进”）。完成那个目标成为了我们健康的目标——并且当我们达成目标时，那种喜悦的胜利感令人振奋。鼓励大家在工作时间内尽力而为（作为这个Scrum主管，当然不允许不健康的加班）——以及当我们实现了这些雄心勃勃的目标时，我会在冲刺评审会上用美食和饮料庆祝胜利。
那个团队给力。我们在五个冲刺周期内，六个人就搞定了这个复杂的项目。这种项目通常至少需要一年时间。
你不能连续不断地冲刺。
休息一下能提升工作效率。
(提到泰勒，他在20世纪初就证明了这一点))
另一种选择：更灵活地想问题 🙈在本书的开头部分，我提到Scrum是一种敏捷工作方法。它并不是唯一的敏捷工作方法。
存在看板(Kanban)、形变法(Shape-up，由Basecamp的方法)、精益(Lean)、水晶法(Crystal)、特性驱动开发法(feature-driven)、动态系统开发法(Dynamic Systems Development Method)等，等等。
或者你可以选择自己动手创建一种流程，而不是遵循预定的方法。根据团队和具体环境的需求进行调整。尝试新事物，保留有用的，放弃没用的（了解更多戴明的文章可能会有所帮助）。
敏捷宣言是由四位顾问在滑雪度假期间撰写的，作为对他们所经历的不同流程之间相似性的总结。该宣言庆祝多样化的做法和灵活性，不相信僵化的框架：
我们重视的是：
- 个体和交互重于流程和工具
- 可运行的软件胜过详尽的文档
- 与客户的合作胜过合同谈判
- 应对变化比遵循计划更重要
每个公司在不同的环境中运作，公司内部的各个团队也有各自的需求和优势。没有一种现成的方法能完全适用所有公司，也没有一种方法能适合所有团队。
真正的敏捷性意味着学习、理解、实验，然后调整你的流程和方法（等等），使过程更加灵活。
结论Scrum 可以很有趣，也能让人充满活力。可惜的是，但大多数公司在实践中并未如此。
我介绍了三个简单的步骤，帮助你从无休止的冲刺中解脱出来。
- 引入Scrum日：让团队重新聚焦 同时 扩展与团队外部的协作
- 引入Scrum假期，让团队充电，使Scrum再次变得有冲击力
- 对工作采取更灵活的态度，而不是固守既定流程。借鉴其他方法，从 其他方法 中学习，尝试各种方法
最后提醒一下：你所引入的任何更改都需要时间才能生效，并且会有一些影响或波动。需要经历一个学习过程。不要仅仅试了两周就停止实验，也不要一次性引入太多改动。
祝你好运，希望你玩得开心，实验顺利！
期待听到您的想法：留下评论，或在领英上联系我