最近，我收到一位读者的私信，他最近 “内耗” 得非常厉害，他可能一时兴起把我的私信当作了吐槽箱。

他们公司一直实行敏捷的管理模式，复盘发现了一个问题：发布与迭代具有强相关性，一个迭代就发布一次，导致需求交付周期过长，严重超出团队和业务部门可接受的时限。现在他在考虑到底该如何改变，是选择 SAFe 还是 DevOps。

卡尔·波普尔曾说：“新的基本原则是，为学会避免犯错误，我们必须从我们的错误中学习。” 敏捷本身并不能带来投资回报。当改进开发流程而不改进部署时，我们最终不可避免会面临这些问题。我之前陆陆续续写过一系列 DevOps 文章，我的看法是选择 DevOps。

大家可以先从了解 DevOps 入手，我已经在之前的文章 《DevOps 生命周期，你想知道的全都在这里了！》 中已经详细说明了。敏捷和 DevOps 毫无疑问可以共存，DevOps 很多时候被视为敏捷的延申，将敏捷的理念扩展到代码部署之外。

那我们该如何在敏捷团队中启用 DevOps？

01 放弃使用手动

手动流程是最常见的错误和延迟源头。在软件开发过程中，我们需要注意 “手动” 一次，包括手动测试、手动部署、手动交付……这些都是浪费时间的蛛丝马迹。

02 找到瓶颈

在整个流水线中实施检测，查看代码在哪些地方受阻，然后集中精力消除瓶颈。没有什么能比通过最慢部分的速度更快。管道中其他地方的改进只会让瓶颈变得更糟，因为它们只会在堵塞点堆积更多的任务。要想取得进展，唯一的办法就是解决最大的瓶颈。

03 自动化测试

这是实现真正有效的敏捷的关键因素。我听说它被描述为黄金标准，但并非绝对必要。错。自动化测试是绝对必要的。它能让你永远快速。人们喜欢说他们做的是测试驱动开发（TDD），但通常他们只是说先写测试再写代码。真正的 TDD 是自动化的。而有效的 TDD 是立即完成的。人们常说以后再写测试。这永远不会发生。

如果你打算这么做（你应该这么做），现在就做。不仅要自动化 UI 测试，还要自动化集成测试、单元测试和验收测试。是的，在功能代码之上编写测试需要更长的时间，但从长远来看，这不会拖慢您的工作进度。事实上，自动化回归套件能帮助你实现持续和无限的速度，正如《敏捷宣言》所设想的那样。试图用手动测试来实现敏捷是失败的秘诀。尽一切努力实现自动化，并不惜一切代价保护它。

04 使用自动化工具

在选择配置管理工具时，我们应优先考虑支持基础设施即代码（IaaC）的工具，这是实施 DevOps 理念的关键。这种方法能够方便我们在多种平台上部署应用，避免重复的工作。

提高自动化程度至关重要，包括大部分代码、扫描流程，以及预防任何潜在的 Bug。我们应在存储库中构建工件，或者实施自动发布，以极大程度上减少基础设施和开发团队之间的协调工作。

同时，我们需要注重文档的记录。虽然在敏捷方法中，团队可能不会详细记录他们的会议纪要或其他交流内容，但在 DevOps 环境中，完整的设计文档和规范对于理解软件版本至关重要。

当然，企业转型 DevOps 难免会遇到一些 “不可抗阻力” 和 “结果不尽如人意”，禅道提供 DevOps 咨询课程， 帮助企业从持续集成、持续部署到自动化测试和监控的落地全方位 DevOps 流程。

既然我们已经知道了改进的方向，那么我们就该勇敢地尝试，最终形成能够持续交付和以客户为中心的团队，交付让客户满意的产品。正如培根所说：“世界上有许多做事有成的人，并不一定是因为他比你会做，而仅仅是因为他比你敢做。”

也不知道那位读者能不能看到我的回复！