BCG Digital Ventures的首席工程师 在伦敦（Continuous Lifecycle London）上发布了一份经验报告，在该报告中称，外部支持团队能够在难以实施变化的组织和封闭的团队中引入持续交付(CD)实践。该团队不只是引入新的技术和工具，而更专注于分享良好的实践和团队教育。实践范围从持续集成到遵循测试金字塔，或者通过活动度量和识别浪费来减少周期时间。

Weston承认，因为他们会导致产品团队缺乏(交付)所有权。

然而，他的团队接受了接受承诺的挑战，这是建立新文化的第一步，而不是成为另一个独立的知识。团队希望让产品团队参与一些现代开发实践，并使他们能够从这些实践中更为主动，并采用持续改进的方法。

Weston的团队开始运行，与工程师一起进行日常工作，暴露出以前看不到的瓶颈。

例如，pull requests只能由不同时区的员工批准，导致代码提交和代码集成之间的长时间延迟。

通过简单地将审批转移到同一位置的工程师，这个巨大的瓶颈就被移除了。诸如此类，他们做了大量努力做出很多变化以简化生产过程。

根据韦斯顿的说法，在众多挑战中其中之一是要避开这个团队对产品进行实际构建、测试和交付工作的请求。坚持团队的使命——让产品团队更快、更有质量地交付特性——让待办事项公开，并收集数据以显示团队的工作对关键指标的影响，这是避免在日常繁重工作中被拖垮的关键。事实上，清晰而持续地沟通问题和进展(通过常规的展示、录制演示、mob编程或wiki更新)以及在新的实践中培训产品团队(例如)占用了团队大部分时间。

显示持续交付度量(支持团队目标)的仪表板

轻松的目标实现之后（例如远程拉请求批准），团队首先就要专注于建立持续集成实践和原则明确定义团队的行动方针了，然后从几乎只有基于ui应用程序测试到，最后，使流程活动成熟、稳定。切换为最新的技术绝对不是首要任务。

例如，团队没有主动参与修复损坏的构建，则持续集成的基础还没有到位。韦斯顿表示，这表示整个交付过程总体上缺乏所有权。经持续交付就绪调查显示，大多数团队滞后于构建和环境管理、测试、数据管理、周期时间，甚至在某些情况下，都没有应用统一的版本控制。然而，这些结果有助于产品团队理解需要改变他们开发和交付系统的方式。

在流程变更方面，采用的方式，每个团队负责维护同一资源库中自己的流程定义，就像通过流程交付的应用程序一样。

在Weston离开的时候，一些团队已经在尝试微服务和来解耦版本并增加交付频率。然而，其他团队仍然在发布分支和耦合的发布计划中工作。

查看英文原文：