Scrum 不再是万能解药，新的协作范式正在崛起。本文将深入剖析敏捷在大厂环境中的失效逻辑，揭示它被放弃背后的真实原因，并带你一探这些巨头正在转向的替代方案。
还记得每个人都痴迷于 Scrum（敏捷）的时候吗？什么时候每家公司都向往有经过认证的 PMP？当两周的冲刺和每日站立会议成为软件开发的日常流程？
我已经关注这种趋势有一段时间，迹象无处不在。大公司正在取消敏捷教练等角色，这不仅仅是因为经济压力。这里发生了一些更深层次的事情。
敏捷开发的历史始于2001年的敏捷宣言，此后中国自2008年起逐渐接受敏捷理念，见证敏捷社区的快速成长。经过十几年的发展，2023年起，敏捷在国内开始显得落寞，许多企业错误地将敏捷等同于加班文化，背离敏捷的原始宗旨。
我也在逐渐意识到，敏捷开发真的可以给公司带来价值吗？
在与阿里、腾讯、京东、网易等大厂朋友交谈时，他们中的大多数人从未使用过 Scrum。即便在实际的过程中会运用敏捷开发的项目流程方法论，但不会说这就是敏捷开发。
大厂项目管理的过程繁杂而冗余，各个项目的复杂程度以及人员角色均不同，不能仅依靠敏捷开发来解决。
在深入研究行业报告并与在这些公司工作过的人交谈后，我发现了以下内容：
1. “无正式方法论”方法
“没有正式的方法”对于上市公司和风险投资的科技公司来说很常见。听起来很混乱，对吧？但实际上它相当优雅。
这些公司没有严格的框架，而是专注于：
一位前京东项目经理总结道：“在担任项目经理> 1 年里，我创建了零工单/任务。我们也不做冲刺。这里的项目经理专注于愿景、战略和合作伙伴关系。减少项目管理和任务。工程师承担大部分项目管理责任并创建自己的任务。
2. OKR的快速跟进
在拥有授权团队、目标和关键结果 （OKR）、关键绩效指标 （KPI） 和目标是协调团队的工具，比推出 Scrum 等僵化方法要好得多。
他们不是问“我们在这个冲刺中能交付什么”，而是问“我们本季度试图实现什么结果？
3. 规划、迭代、上线
没有复杂的流程，只需要调研或发现根本问题，给到短期以及长期解决方案，预计上线时间，后续的维护或运营如何处理即可。
在我经历的工作中，这是真正让我印象深刻的事情：有能力、自主的人需要更少的结构来产生可靠、高质量的输出。大型科技公司能够吸引、负担得起和雇用这些人。
这些公司不需要敏捷的主要原因是，敏捷旨在解决的主要问题——弥合技术员工和非技术员工之间的鸿沟——在这些公司并不存在。
组织越来越多地选择量身定制的方法，而不是像SAAS这样的标准化框架。中型和大型公司对敏捷能为他们做的事情不太满意，他们更有可能选择使用许多不同框架的软件开发策略。
敏捷开发可以适用的团队：
但是，当您拥有了解业务环境的智能、自主团队时呢？Scrum 经常会成为开销，从而减慢速度。
我们有足够的权力来削减 Scrum 中阻碍我们的部分。过了一段时间，剩下的根本不代表 Scrum——这正是我在成熟团队中看到的情况。
让我们诚实地对待一些事情。在生活成本危机和不稳定的经济环境中，只有一些人愿意向敏捷专业人员支付薪水。
当公司查看资产负债表并看到某人的工作是“促进会议”和“消除障碍”时，这很容易成为预算削减期间的目标。尤其是当球队足够成熟，可以在没有外部帮助的情况下自我指导时。
以下是我对事情发展方向的看法：
想要更多证据吗？JIRA 的提及大多带有负面关联：所有 13 次提及 JIRA 都是在这种情况下。有人提到，无需与 JIRA 进行太多合作即可完成工作，这是一个积极的因素。
一家科技公司衡量了工程师对 JIRA 的满意度，净推荐值 （NPS） 为 -83。这个数字低得惊人，这意味着 83% 的工程师会建议不要使用 JIRA。
当你用于“敏捷”的主要工具被使用它的人普遍讨厌时，也许是时候重新考虑这种方法了。
如果您正在领导一个团队，请考虑这一点：也许您的团队已经准备好获得更多的自主权。也许那些每日站立会议可以变成每周同步。也许你可以用谈论感觉可以实现的事情来代替故事点。
敏捷并没有消亡，但它周围的工业综合体正在消亡。未来不是遵循框架，而是建立能够适应、学习和交付价值的团队，而不需要有人告诉他们如何做。
更加注重结果打成与否，问题解决与否。
本文由 @来学习一下 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。