曾经备受关注的 Scrum敏捷管理为何不受大厂欢迎了？

有能力、自主的人不用太多引导就能产出可靠、高质量的成果。科技大厂更倾向于招揽、雇用和用好这样的人才。
 
让有能力的团队以适合自己的方式自由选择运作方式。大部分工程项目都可以灵活放权，我们也能明确看到为什么Skunk Works这种自治模式能够减少官僚主义，吸引到更多高素质人才的支持。
 
脱离团队层级的管理，工程部门仍然可以顺畅发展。也正因为如此，多数科技大厂才不愿采取重量级管理流程。当然，大厂也面临着自己的生产效率挑战，但其中大部分问题即使是用重量级管理流程也解决不了。具体包括：
 
开发者生产力。工程师们要如何把更多时间花在代码编写和团队目标实现上，而非分神于基础设施问题或者依赖问题？平台团队当然能帮上一把，但这还远远不够。
 
偿还技术和架构债务。科技大厂永远在快速行动，迅速对新机遇做出响应。在此期间，某些比较偷懒的选择会积累下技术和架构债务。如何以合理的方式偿还这笔债务，就成了日常工作的重要组成部分。毕竟“随借随还”，要比一口气还清友好得多、也可行得多。
 
让团队结构与组织目标相匹配。企业和子部门的目标总会定期变化，那么这种变化要如何反映在团队结构当中，又不致破坏团队自身的凝聚力？
 
腾出时间搞创新和应对意外工作。如果团队有创新的意愿，那就必须留出相应的时间。
 
随着工程团队的扩大，始终保持高效。企业拥有的工程师越多，那么工程师之间沟通和决策的日常开销就越沉重。在规模翻倍之后，组织要如何才能保持同样的工作速度？有没有哪些流程和结构选项，能够无视组织规模、始终保证团队敏捷和快速行动能力？
 
持久卓越。正如 Will Larson 在文章《先进在通往高效能团队的道路上》中所说，一时的卓越不是卓越，持久的卓越才是目标。必须想办法在提升业务吞吐量、保证工程师心态健康和长久持续这三个方向间找到平衡点。
 
七、难道 Scrum 毫无用处？当然不是
 
说了这么多，那企业是不是该像科技大厂那些完全放弃 Scrum？当然不是喽。在多数情况下，转为 Scrum 本身仍是个巨大的进步，而且会带来更高的生产力。Skype 就是一例，虽然我们及时摆脱了 Scrum 的束缚，但 Skype 仍然拼不过 WhatsApp。
 
下面来看看适合采用 Scrum 的几种理想场景：
 
1、“厨房水槽团队”：对于像厨房水槽一样什么活都得接的团队，Scrum 这类重量级流程甚至有助于做好工作。毕竟 Scrum 告诉其他相关方，当前进行的冲刺不能被随意打断，而且要给整理新的功能请求留下时间。于是乎，以冲刺为基础的工作结构就让团队有了不受干扰的自主空间，保证大家能按预设的优先级顺利推进开发。
 
“厨房水槽团队”在非技术企业中相当常见，这类企业往往不了解工程技术的底层原理。所以 Scrum 有助于引导其他相关方、让他们慢慢理解软件的开发流程，同时为工程团队提供执行空间。当然，如果产品团队需要承担的责任过多，“厨房水槽团队”在科技大厂中偶尔也会出现。但无论如何，Scrum 都能给这些团队保留一点喘息之机。但大厂团队更自主而且灵活性更高，所以他们可以更新团队章程，甚至直接向自己不认可的工作说不。
 
2、新团队的“组建”与“碰撞”阶段。心理学家 Bruce Tuckman 提出了“组建、碰撞、规范和执行”几个工作阶段。这个模型也非常适合大多数工程团队的发展曲线。
 
在组建新团队时，大家首先需要确定工作方式。而 Scrum 这类现成的方法当然是个好选择，至少要比相互还不熟悉的成员们各自提出意见要靠谱得多。如果成员们对于工作方式有所“碰撞”，那么 Scrum 也能带来有据可查的方法指导。
 
Scrum 的优势就是帮助团队成员反思自己的工作方式。而且随着时间推移，团队会逐渐摸清适合自己的自主工作路线、剔除不适用的重量级 Scrum 规则，最终找到个性化开发路线。
 
3、将交付速度提升至几周一次。Scrum 提出的冲刺周期概念，确实能够帮团队加快交付速度。而且只要冲刺周期比团队原本的交付周期更短，那 Scrum 就有实际价值。不跟科技大厂比较，单纯自己跟自己比，这样的提升对很多非数字优先的传统组织来说已经是天翻地覆式的提升。
 
加快交付速度，也是 Skype 在 2012 年决定推广 Scrum 的主要原因。在过渡之前，团队每隔几个月才能交付一次。过渡之后，各团队每月能交付一到两次。请注意，最终放弃 Scrum 的主要原因，是我们想要进一步把交付周期压缩到比冲刺周期更短的水平，其实大多数团队都没必要做得这么极限。
 
4、严格要求制定统一项目进度报告的公司。Scrum 的普及往往也伴随着 JIRA 的引入，而且我觉得再没有比 JIRA 更好的组织报告工具了。我发现很多组织在选择 Scrum 时，就是希望借 JIRA 之力让领导团队对一线开发者有更多了解，真正把握谁更累、谁更需要帮助。
 
统一报告和团队层级的优先事项划分，正是 Skype 在转向 Scrum 后迎来的主要收益之一。当时在 Skype 担任敏捷教练的 Chris Matts 就做出过这样的总结：“在 Scrum 和 JIRA 的帮助下，我们既能发现组织内积压工作最多的团队，也能发现项目实施顺序有误的团队。”
 
所以我的个人观点是，对于科技大厂中那些已经贯彻了自主授权、目标灵活且只需要依关键结果（OKR）工作的团队，直接指定 KPI 和业务目标往往效果更好。但对于自主性较差、权限空间有限的团队，Scrum 仍然要比传统流程方法有效得多。