实现这种绩效水平的目的是为了让组织能够以高度信心进行更多实验,从而获得更多学习。
译自 Elite Performance Is Wasted on Feature Factories,作者 Steve Fenton。
精英级表现在 DevOps 领域意味着您可以经常且早期部署,拥有较低的失败率,一旦出现问题也能快速恢复。达到这种水平需要对技术实践和文化能力有严格的坚持,所以如果您只是想加快功能发布的进度,可能会浪费时间。
实现这种绩效水平的目的是能以高度信心运行更多实验,从而让组织获得更多学习。
"精英级表现者"这个概念来自于 Accelerate State of DevOps Report,该报告根据软件交付绩效将表现分为多个层级。位于最顶层的表现者能够每天部署多次,改动的领先时间在一小时之内。他们还拥有最低的改动失败率和最快的恢复时间。
要在吞吐量和稳定性两方面实现这一绩效水平,就必须将持续交付的技术实践嵌入组织。需要自动化测试、管理测试数据、松散耦合的架构和部署自动化。
掌握这些技能需要时间,所以精英级表现代表了一项严肃的作。这就是您需要确保组织具备利用这种软件交付绩效水平的能力的原因。这意味着要从功能驱动思维转向基于实验的方法。
让我们通过想象力来看看功能驱动与实验驱动的团队。假设软件交付绩效如此之高,以至于不再受到约束,从而让我们拥有了实际上无限的交付容量呢?
功能工厂的工作方式是根据客户需求和内部灵感时刻排队建立功能路线图。总是有比可供交付的时间更多的功能请求。
如果一个功能驱动团队能够比构思进程更快地交付功能,他们只需为每个需求生产一个功能。该软件几乎可以做任何事情,并且会有某种机制让每个用户配置软件以自己想要的方式运行。
当您陷入交付每个功能请求的陷阱时,您生产的软件就会失败。由于用户无法理解自身的配置,它将在自身的重量下崩溃。拥有无限的功能交付能力只会让它更快失败。
在功能工厂的情况下,无法交付每个请求实际上是拯救它们免于失败的唯一原因。由于 backlog 迫使它们从无穷选项中进行选择,它们才能在缺乏产品管理的情况下生存。如果没有这种选择的压力,优秀的功能就会被糟糕的功能所淹没。
简而言之,更多功能和更多代码并不能增加软件的价值。这种软件缺乏真正有价值的东西: 一个坚定的立场。
那实验驱动的方法呢?
实验团队使用影响映射等技术来确定目标并生成实验,以发现将使它们更接近每个目标的方式。
如果没有约束,实验团队将最大化学习。他们会尝试许多替代方案来发现最佳方法,并可以重新审视之前实验中学到的东西,看看结果是否仍然有效。
实验团队 DNA 的一部分是移除无效的做法。他们可能会在结账流程中添加一个 upsell 界面来增加销售额,但如果放弃购物车的价值比 upsell 收益高,他们就会撤回这一做法。
实验过程需要在连续测量和同时测量之间保持平衡。您不想一次改变太多内容,但通常需要同时测量当前软件和提议的想法,以避免时间事件和季节性因素带来的干扰。
实验团队将从无限容量中获得更多学习价值,这将是非常宝贵的。
精英级绩效在为您提供快速高质量反馈时是有用的,而不仅仅意味着更多功能。
在白皮书"持续交付的重要性"中,我描述了持续交付的技术实践如何有助于缩短反馈周期。持续交付的目标不是创建更多功能,而是产生更大影响。
短反馈回路有许多帮助。它们降低风险、减少返工并提高幸福感。频繁反馈还能最大化学习效果、增加新工作时间,并更有可能实现并超越目标。
每个人都会使用代理反馈循环作为对更改的临时验证,例如内部测试。但唯一有意义的反馈来自于将软件推向真实用户。
当您以大批量工作时,您会延迟这种真实反馈。延迟反馈的影响可能会被隐藏,因为内部反馈循环确认功能正在"完成",在没有实际信号的情况下,这看起来很像进展。您在代理反馈上行进的越远,就积累了越多的市场风险。
我曾参与一个 CMS(内容管理系统),该系统被20多个国家1500多个公司网络所使用。CMS 的一个经典问题是,您无法始终预测用户将添加的内容。
用户通常在数码相机上拍摄照片并以全尺寸上传,但仍希望网页为访客快速加载。一个好的 CMS 需要对图像进行管理,以处理用户可能不知道的良好做法,无论是文件大小、格式还是其他方面。
这个案例研究很有趣,因为图像优化问题被解决了两次。一次采用实验方法,一次采用功能驱动方式。这为在大多数其他因素相等的情况下比较这两种方法提供了一种方式。
实验方法:
功能驱动方法:
实验方法在技术上的结果是,原始图像从不会提供给网站访问者。相反,会存储图像的多个调整大小版本,浏览器会从包含各种选项的源集中选择适当的大小。折叠下方的图像被设置为懒加载,进一步增加了感知速度。
这种方法的结果是网站运行速度大大加快,尽管需要进行多次实验才能在图像质量和网站速度之间找到可接受的平衡。
功能驱动方法导致进行了多项重大技术变更。许多变更被广泛认为可以提高性能,但该团队并未通过任何测量来验证。
功能驱动方法的结果是网站速度变慢。存储技术的速度、从无 Cookie 域提供图像的优势以及缓存的好处无法解决在典型网络速度下提供许多大图像的根本问题。
这个教训不是将图像调整大小比其他性能变更能带来更多改进。而是通过测量变更的影响来验证您的假设,使您能够实现预期的结果,并从所做的尝试中学习。
在采取实验方法时,尝试每个理论至关重要。移除被拒绝实验的代码也是标准做法。如果变更不能让您朝目标前进,您就不希望保留它。
然而,许多组织由于未能测量变更的影响,正在做这样的事情。
当软件产品高度功能驱动时,限制吞吐量是有益的,因为压力迫使对每个功能的潜在价值做出决策。功能驱动的组织需要有理由说"不",如果没有限制因素,他们很快就会损害自己的软件质量。
当产品以实验为重点时,更高的性能水平会导致知识更快地积累。这使得该方法远远优于功能工厂。