Overcoming Challenges in Agile and DevOps Integration: A Qualitative Study
这项基于对来自巴西和德国的六位行业专业人士访谈的定性研究，识别了在整合 Agile 与 DevOps 过程中存在的关键文化、结构、流程及技术挑战，并提出了四个战略解决方案领域，以帮助组织克服这些障碍并改进软件交付。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
想象一下，你正试图在一座庞大且复杂的工厂（DevOps）内部，驾驶一辆高速赛车（Agile）。
Agile（敏捷） 就像是赛车手：他们想要加速、快速转弯，并根据乘客（客户）当下的需求随时改变路线。
DevOps 则是像维修团队和工厂车间：他们希望赛车是安全的，引擎运行平稳，并且维修工作能在不停止比赛的情况下自动完成。
你分享的这篇论文是一项关于尝试将这两个世界结合起来时会发生什么的调查研究。研究人员采访了来自巴西和德国的六位资深“赛车技师”和“赛车手”，旨在找出为什么这种结合如此困难以及如何解决。
以下是他们研究结果的简单拆解：
核心问题：为什么这种结合很难？
研究人员发现，最大的障碍通常不是工具或代码，而是人和规则。他们将问题分为以下四个类别：
“观念错误”的文化（文化与组织障碍）：
- 隐喻： 想象一下，赛车手认为“敏捷”意味着“随心所欲地奔跑，无需规则”，而维修团队认为“DevOps”意味着“买一个新机械臂”。
- 现实情况： 人们经常误解这些概念。他们认为购买了软件工具（如 GitLab）就成为了 DevOps 团队，或者认为敏捷就是遵循一套严格、僵化的清单。实际上，敏捷是一种灵活的心态，而 DevOps 强调的是协作，而非仅仅是工具。此外，还存在一种“责备文化”，即人们害怕犯错，这阻碍了他们尝试新事物。
“玻璃墙”（结构性约束）：
- 隐喻： 赛车手在车里，技师在车库里，但他们之间有一面厚厚的玻璃墙。他们能看到彼此，但无法交谈或传递工具。
- 现实情况： 公司通常拥有互不沟通的部门（孤岛）。编写代码的人（开发人员）和负责维护服务器运行的人（运维人员）往往在不同的房间，有着不同的上司。此外，有时公司的决策过程过于缓慢，或者依赖于那些不允许其快速更新软件的外部公司（如苹果或谷歌的应用商店）。
“过于复杂的规则手册”（流程与方法复杂性）：
- 隐喻： 团队正在试图遵循一本为另一种车型编写的 500 页说明书，而这正拖慢他们的速度。
- 现实情况： 公司经常试图将大型、僵化的框架（如 SAFe）强加给团队。这增加了过多的文书工作和会议。在修复故障（紧急任务）与构建新功能（创新任务）之间取得平衡变得非常困难。
“盲点”（技术限制）：
- 隐喻： 赛车手正在加速，但仪表盘坏了。直到车子起火之前，他们都不知道引擎正在过热。
- 现实情况： 有时系统无法实现实时“观察”正在发生的事情。如果某个环节出了问题，由于数据散落在不同的工具中，需要很长时间才能查明原因。
解决方案：如何赢得比赛
受访专家提出了四种解决这些问题的主要方法：
打造“超级团队”（团队结构与自主权）：
- 对策： 不要再区分“赛车手”和“技师”，而是创建一个赛车手本身就是技师的团队。
- 理念： 如果编写代码的人同时也负责维护代码的运行，他们就会写出更好的代码。他们不会想搞破坏，因为一旦出问题，他们自己就是那个要在凌晨 3 点起床修理的人。要赋予这些团队自主决策的权力，而不需要每做一个微小的改动都要向老板请示。
改变“团队精神”（文化与协作）：
- 对策： 当事情出错时，停止责备个人；开始询问“我们如何修复系统？”
- 理念： 创造一个安全的环境，让人们可以坦诚承认错误而不必担心受到惩罚。使用工具让所有人的工作都可见（例如共享白板），以便每个人都知道正在发生什么。改变奖励机制，让人们因为帮助团队获胜而获得奖励，而不仅仅是作为一名最快的个人。
对规则保持灵活性（流程与变更管理）：
- 对策： 不要盲目遵循规则手册；要遵循原则。
- 理念： 如果某项规则（比如特定的会议）无法帮助团队移动得更快，那就取消它。从小处着手。不要试图一夜之间改变整个工厂。先选一个小团队，证明其可行性，然后慢慢推广。要诚实面对现状，如果你还没准备好，就不要假装自己已经实现了“敏捷”。
升级仪表盘与工具（自动化与基础设施）：
- 对策： 将枯燥的工作自动化，并安装更好的传感器。
- 理念： 使用机器人（自动化）来测试代码和部署更新，从而减少人工操作。建立一个“列车”系统，让更新按计划进行（例如每周二），这样每个人都知道什么时候会有变动。这降低了出错的风险。
总结
研究结论指出，你不能仅仅通过购买软件来解决这个问题。你必须改变文化。
这就像是试图把一艘缓慢沉重的货轮变成一艘快艇。你不能只是换一个更快的引擎（工具）；你必须改变船员们协作的方式、他们做决策的方式，以及他们看待自身职责的方式。最成功的团队是那些构建软件的人和运行软件的人处于同一个团队、拥有共同目标并彼此信任的团队。
局限性： 研究人员承认他们只采访了六个人，因此虽然他们的建议非常高明，但可能并不适用于世界上每一家公司。他们建议需要更多的研究来验证这些想法是否对所有人有效。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。