大型科技公司如何以产品而非Scrum方式运行科技项目? - Gergely


在与 Facebook、Whatsapp、Google、Netflix 和类似组织的工程师交谈时,他们中的大多数人从未使用过 Scrum。为什么?这是因为以下几点:

  • 有能力、自主的人需要较少的结构来产生可靠、高质量的输出。大型科技公司能够吸引、负担和雇用这些人。
  • 通过给予他们选择如何运作的自由来利用有能力的团队。对于大多数类型的工程来说都是如此,并且有充分的理由说明为什么臭鼬工厂的自治模式和减少官僚主义,是许多拥有高素质人才的高绩效团队最终遵循的。

扩展工程组织远远超出团队级别的流程,这是大多数大型科技公司不推动重量级团队流程的另一个原因。这并不是说这些组织在生产力方面没有挑战,但这些挑战中的大多数都不是重量级流程可以解决的。这些公司正在应对的挑战包括:
  • 开发人员生产力。工程师如何才能花更多时间编写代码来推动团队目标的实现,而不是陷入基础架构问题或解决依赖关系的问题?平台团队是一种有用的方法,但这里还有很多东西需要解压缩。我们将在以后的时事通讯中详细介绍这方面的内容。
  • 偿还技术和架构债务。所有大型科技公司都在快速行动并快速响应新机遇。在这样做时,公司经常走捷径,导致技术和架构债务。如何以合理的方式偿还这笔债务成为日常流程的一部分,而不是进行“大爆炸”的技术债务偿还项目?
  • 与组织目标相匹配的团队结构。公司和子组织的目标会定期更改。团队结构如何反映这些变化,同时最大限度地减少对团队凝聚力的破坏?
  • 为创新和意想不到的工作腾出时间。对于期望创新的团队,您如何创造空闲时间来实现这一目标?
  • 随着工程团队的成长跟上步伐。公司拥有的工程师越多,沟通或做出影响大多数工程师的决策所需的开销就越大。组织规模扩大一倍后,如何保持快速发展?无论组织规模如何,都有哪些流程和结构选择可以让团队保持敏捷和快速行动?
  • 经久不衰的卓越。整个组织如何提高其吞吐量,同时工程师也保持快乐,并且改进持续时间足够长以复合?“持久卓越”一词来自Will Larson的文章“保持在通往高绩效团队的道路上”

 
以产品为中心的环境和放弃 Scrum
Scrum 妨碍了每天的交付。Scrum 的整个想法围绕着 Sprint,在 sprint 开始时提交任务,在 sprint 期间处理这些任务,并演示我们在最后所做的事情。 
这个过程感觉不自然,就像是强加给一个快速移动的网络团队一样。我们很快就转向了一种更流畅的工作方式,采用了看板方法。我们不再关心 sprint,并且放弃了 Scrum 带来的大多数仪式。我们只关心知道我们现在在做什么,以及我们接下来要做什么。
基础设施和开发人员工具消除了对许多 Scrum 仪式的需要。Scrum 仪式,比如向产品负责人演示、签署工作然后交付它,假设了一些事情:
  • 产品负责人是可以肯定地按照规范验证工作的人。
  • 产品负责人编写了规范——因为他们正在验证它。
  • 在签收完成之前,工作不会被运送到生产中。

然而,在我们的环境中,这些假设往往是有缺陷的。我们编写的所有代码都经过了单元测试,并在需要时进行了集成和端到端测试。我们在功能标志后面发布了我们的代码,并通过分阶段推出来验证它们,从向团队推出开始。CI/CD、功能标志和实验工具让我们拥有比依赖产品负责人更快的反馈周期。
许多大型科技公司已经认识到一流的基础设施和开发人员工具如何对工程团队的生产力产生重大影响。这就是为什么 30-40% 的工程师经常在平台团队工作,也是Uber 在平台团队上投入巨资的原因。有了一流的基础设施和平台可供使用,团队可以专注于他们的核心工作目标,而不是弄清楚如何设置基础设施或如何使服务合规。
 
是否应该仅仅因为大多数大型科技公司已经这样做就放弃 Scrum 和其他方法论?这将是一个错误。在许多情况下,切换到 Scrum 是非常有意义的,并且会带来更好的生产力。Skype 就是一个例子。