“铁三角”的概念是一个古老的一个。在项目管理中,成本之间的权衡,时间表,和范围。“选择任意两个”是一种常见的经验法则,也就是说,你可以优化两个而不是三个。

三角形的一个变体是成本、进度和质量(范围被质量)。下面的标志(通过Flickr)是一个著名的版本:

DevOps到达时,然而,它似乎是铁三角已经完成了其使命。DevOps-aligned组织交付软件更好,更便宜、更快——一次!有时,突破发生。

但随着DevOps已经成熟和演变成产品为中心组织转型,新的铁三角似乎新兴。它开始,天真地,敏捷和DevOps值:

  • 团队应该自治。
  • 团队应该“两个披萨”(6 - 10)。
  • 团队应该是持续的;他们不应该经常分解和改革(与一些项目管理模型相比)。

这三个值会有许多你点头头。我们都听过他们。

但是他们是矛盾的。选择任意两个:

如果你的团队很小,长寿,它将有显著的外部依赖。你会处理协调和排队问题访问外部服务必须交付一个结果。这是完全不同的问题我的客户现在在在他们的操作模型。自动化是首选的回应,但许多深入的客户都让我相信,总有一组残余人性化的依赖性,会导致一些问题。

如果你想优先”小和自主,“你将旋转人的团队。当然,你可以在必要的专业知识,但是如果你想让你的团队在一个最优规模,你必须旋转别人。这也有缺点的团队文化,信任水平(例如,心理安全),为整个团队有效性,深入理解同事的知识、技能和态度。(我想起将拉尔森一个优雅的难题——“高性能团队是神圣的,我很犹豫是否要拆开他们。”)

最后,如果你的团队是长寿的完全自治,它将比两个披萨可以提要。你可能会与团队成员和协调问题,也许一个整体产品经理工作负荷太大。我听到这大组织的多个情况下实验结果取向。

有许多反应:自动化(如前所述)丁字形的专业人士为例。但在复杂的和高度扩展环境,这些都是有限的。自动化可以帮助,但它不是一个银弹。有时,在专业知识的依赖关系(如安全磋商)不容易自动化。有时问题比t型专业的搜索堆栈溢出可以回答。

所以我的观点是,没有“解决方案”。它的设计权衡产品为中心的组织。我很感兴趣你浏览这些!请伸出或安排调查如果这是你积极工作。