这是一个典型的谈话，我最终每次提及我的角色时都有。

让我开始回答几个问题，即我在我的术语上作为“Devops的商业分析师”。

Devops在交付中的作用是什么？

devops是一个只有流行语的东西。该术语在技术和正确的原因中挑选了很多关注。

Devops桥梁弥补了在SDLC中使用的团队之间的差距。连续集成和连续交付增强了敏捷交付模型。这允许递送以持续的较小块中的船舶代码。它加速了向生产的货物运输。

我在devops工作的一些例子：

• 架构更改/升级作为交付的一部分（例如：升级支持SMTP服务器）
• 实施新工具以帮助交付（例如：监控工具，如Splunk，Appdynamics，使用Jenkins）
• 支持非产品环境
• 设计部署管道
• 在管道中整合早期测试
• 提供强大的功能

并且最重要的是培养Devops心态跨交付和运营！

是的，工具对于实现最终目标很重要，但我们无法在没有固有的文化转变的情况下进步。

谁是DEVOPS中的BA的利益相关者，并且企业分析师需要考虑什么？

更高的管理，交付团队，测试团队，操作和自己的自我：他们都是你的利益相关者。提高应用程序的开发，交付，测试或操作的想法或要求可以来自任何人。

业务分析师的基本核心作用不会随项目或需求类型而改变。这同样适用于Devops的业务分析师。以下示例将阐明BA必须与Devops工具和心态所需的位置一起使用。

a）单击“部署： 这一要求出现了我们必须作为团队执行的广泛手动部署。这意味着不断监测，并让某人手动从一步到另一个步骤。就像任何其他过程一样，人工介入越少的人类错误的机会就越少。

利益攸关方：

• 运营团队（实际部署团队）
• Devops团队（创建一键式流水线0
• 交付团队（提供输入）
• 高级管理人员

作为商业分析师的事情：

• 了解运营团队面临的当前状态下的问题。
• 纹波效果和发布的问题为本释放。
• 优势交付团队将展望。
• 如何构建以添加自动化测试和蓝色/绿色部署作为迭代方法？
• 提供哪些工具来交付

b）迁移到 云: 随着基础设施迁移到云的扫描，这是许多组织中的普遍存在项目。如此！迁移可以是小尺寸升力并仅用云中的API或队列端点转移，或者它可以是大规模的迁移。

利益攸关方：

• 管理（指令和时间表来自于它们）
• 解决方案架构师（解决方案和设计将来自此组）
• 项目经理
• 表演团队
• 功能测试
• 安全团队
• 数据库管理员
• 德沃斯
• 交货
• 运营
• 第三方供应商如果有的话

作为商业分析师的事情：

• 与解决方案设计师和业务合作以了解用例
• 开始创建史诗来管理范围和优先级
• 将高级设计或史诗分解为带有交付团队的较小块
• 将安全性和非功能性要求合并，作为交付使用案件的一部分
• 关于数据迁移策略的工作
• 与测试团队合作以创建功能和回归测试计划
• 聘请相关利益攸关方进行操作准备，博士战略和最终削减策略

c）业务需求（功能/功能驱动工作）：交付业务功能要求。这项工作涉及Devops Mindset作为上述工作。在功能的交付中，我们需要考虑非产品环境所需的BAU支持，涉及部署代码的工作，提供非功能要求的交付。所有这一切都与“我不在孤岛上工作”的心态完成，使其成为任何其他工作的人。

这是商业分析师需要考虑的事情的快照。这不是一个详尽的清单。

BA需要哪些技能成为Devops的一部分？

商业分析师需要来自他/她的工具包和经验的所有工具，并在过去获得的经验导航Devops World。然而，最重要的是持续交付，集成，持续部署和敏锐理解和对非功能要求的重要性的心态。

天气在一个标题为“Devops”团队或一个功能递送团队中，这种心态将确保我们认为“可靠性”“性能”“安全性”和“稳定性”作为一个特征而不是良好的氛围。 

然后，BA的作用是帮助提供世界级平台。

作为业务分析师的核心不会改变我们使用传统的瀑布方法，敏捷框架或敏捷Devops框架工作的天气。事实上，我们使用的任何框架都需要Devops Mindset。从本质上将NFR视为一个功能，并在合作中连续地交付它们以及功能性的业务需求。

我希望这有助于回答Devops Conundrum的商业分析师。