bob电子体育竞技,记录操作系统,专业服务自动化

持续交付如何实现高性能技术组织

持续交付业务策略

Cto 和其他技术领导者面临着一个艰难的挑战: 我们如何让董事会成员和其他高管了解研发团队的表现?简短的回答是通过证明价值,这在于工作软件。我们交付软件的速度越快,我们展示的价值就越大。快速交付软件的最好方法是通过建立持续交付来创建一个高性能的技术组织 (又名工程团队)。

使用持续交付来满足期望

持续交付不是一个新概念,但它是一个实践,没有多少更大的,成熟的公司遵循。历史往往太多,这导致了风险规避政策。不使用连续交付,公司将多个版本打包成一个大版本。因此,他们等待发布产品更新的时间更长。这种方法风险较小,但事实是,发布较大更新的频率较低,比常规较小的更新风险大得多。

例如,电子商务公司可能会在寒假期间停止对其网站的更改,以避免在网站流量达到高峰时出现潜在的中断或其他问题。这似乎足够合理,直到 1月更新网站的时候。如果在大更新后,网站的一部分停止正常工作,或者最近下的订单被损坏,会发生什么?因为如此多的代码同时被更改,所以几乎不可能确定在更新中问题发生的位置。

由于无法确定发布有什么问题,团队可能不得不回滚整个更新以稳定网站。这意味着即使失去了好的代码,也可能会推迟其他项目,个别团队正在努力应对回滚。

如果电子商务公司实行持续交付,它不会陷入这样的困境。随着持续交付,公司定期在短周期内发布软件更新。这更新网站和产品不是大规模的变化,而是增量的调整。持续交付允许工程团队不断改进产品,同时也检查和改进他们自己的流程。

理解为什么持续交付有意义以及如何使实践与客户期望相一致是很重要的。

根据客户要求持续交付

在我们深入研究如何保持工程团队顺利运行之前,我们应该首先确保我们朝着满足客户需求的目标努力。为了发布符合客户需求的软件,收集并听取用户反馈。

只有当您的团队定期收到反馈并能够快速适应新信息时,您的团队才能完成持续交付。根据客户需求不断迭代可以确保两件事: 1) 你的团队灵活,能够根据客户需求快速行动; 2) 你不仅仅是为了更新而更新。

沉迷于客户是没有用的,除非你能提供他们想要的结果。交付足够的结果需要创造期望和对照期望衡量进展。许多典型指标,如变更的提前期、平均恢复时间 (MTTR) 和变更失败率都适用于此。达到这些指标的最佳方式是什么?练习连续交付。

定期交付提高了绩效指标

如果我们重新审视以客户为中心的指标,我们可以看到持续交付如何使我们能够满足这些要求。

  • 变更的提前期指的是工程团队对软件进行更改需要多长时间。更大的变化通常需要更大的投资: 需要更多的人在场来实施变化,而命令链的高层必须批准这些变化。这导致更长的交货期和更大数量的风险变化。通过持续交付,工程团队可以利用更多预先批准的标准变更或由必要的审批者以电子方式批准的变更,从而减少修改软件所需的人力资本和时间。
  • 平均恢复时间指在出现故障时修复软件所需的时间。有了更大、更不频繁的更新,团队将很难破译出什么问题。持续交付使识别问题和修复问题变得更加容易,甚至可能完全避免更新的回滚。
  • 改变故障率看看变化多久会导致需要立即关注的失败。目标是实现 0-15% 之间的故障率。如果团队推动的改变非常小,那么改变失败的可能性就小得多。在回顾过程中,微小的变化更容易理解,并且通常影响较小。

制衡使过程顺畅

虽然持续交付可以帮助我们痴迷于客户的技术组织在高水平上发挥作用,但团队仍然需要一路上的制衡。这些制约和平衡可能包括实践,如确保代码经过深思熟虑的结对编程,作为结对编程和测试驱动开发的双重检查的代码审查, 这导致快速开发周期和基于特定测试用例的最小回归重构。

领导层必须倡导流程变革以满足客户需求

与任何大的变化一样,实现持续交付以支持高性能的工程团队需要整个组织的支持。然而,需要从更多个人那里购买的大型组织将从改变到持续交付实践中受益最大。能够连续部署的大公司比小公司每天人均部署的次数多,这是一个高效团队的标志。

不幸的是,由于不必要的过程和感知的风险缓解,大型组织通常没有实施这种做法。技术领导者必须敦促他们的领导团队采用持续交付。这是满足客户要求的严格性能要求并在竞争中保持领先的唯一途径。

希望这份持续交付入门书能帮助你理解为什么这个过程对一个高效的组织至关重要。这本书加速: 精益软件和 DevOps 的科学Nicole Forsgren 、 Jez Humble 和 Gene Kim 更详细地解释了这个概念,我向任何有兴趣在他们公司追求持续交付的人推荐它。

这篇文章最初于 2019年9月20日在福布斯上发表。

注释