因为保险公司通常拥有历史悠久的异构系统环境。这种情况意味着新产品往往要连接很多接口。这会产生强烈的依赖性，甚至可以决定产品的成功或失败。这可能会导致摩擦，特别是如果新产品以敏捷方式开发，而现有产品以与发布周期相关的经典方式开发。业务分析师还可以使用通常不受欢迎但必要的文档来支持开发团队，并且仅在开发团队有具体问题时才与他们联系。
根据我的经验，我可以说业务分析师至关重要，尤其是对于以下任务：
接口技术开发支持
获取接口文档
与其他领域的协调支持
开发团队关于接口解析的不确定性
协助安全和发布文档
技术特性文档
支持产品负责人
由于并行的项目经理活动和较短的开发周期，产品所有者通常缺乏时间来深入处理技术主题。在这里，业务分析师可以在以下活动中支持和减轻产品所有者的负担：
在迭代收集需求和创建用户故事期间
提交适当的优先级建议时
与开发团队沟通内容时
为提高产品质量做出贡献
由于业务分析师非常了解主题，因此他们也有助于提高产品质量。特别是在测试领域，容易出错的星座往往很难让开发人员和部门识别。业务分析师可能会面临以下任务：
创建测试用例和测试场景
检测负面测试用例
执行测试用例和探索性测试
业务分析师在敏捷环境中应该避免什么？
敏捷业务分析师应该将自己视为服务提供商，并为开发团队提供更 脊医电子邮件地址 好地了解主题和用户的机会。因此，业务分析师不应该代表技术垄断，而应该为开发团队提供技术指导，最重要的是，让他们有机会参与必要的决策。
我认为团队只有共同做出最好的决定。因此，业务分析师应该收回他的自我，作为团队成员领导公开讨论，并对替代解决方案持开放态度。这也适用于传统上属于业务分析师“主权”的领域，例如流程建模或服务削减。
业务分析师也不应该进行微观管理。实现冲刺目标所需的任务、冲刺计划和冲刺待办事项应与开发团队一起确定。业务分析师应该始终对理解问题、技术问题和开发团队的反馈持开放态度。
结论
正如您所看到的，业务分析师可以成为敏捷团队中的真正支持者。他们可以引入在经典项目中获得的方法经验以及软技能。这意味着产品所有者和开发团队可以获得支持，特别是在组织尚未以敏捷方式工作的领域以及需要技术开发的领域。
由于敏捷项目中的沟通是在团队内部直接进行的，而不是通过详细的技术概念或规范进行的，因此此类项目特别适合业务分析师。在这里，您可以扩展您的技术和方法知识，包括技术理解。