问我的敏捷项目真的需要一个专门的业务分析师(BA)吗？

EN

一个完整的团队，包括能够理解业务需求并将其转化为软件设计和实现的人员是非常有效的。

但通常，没有人涵盖复杂系统的每个方面，并且了解所有业务需求的一切。例如，对财务、会计、财务数学有着深刻理解的人，与专门从事生产、MRP调度或产品安全的人相比，对某些物质流动或物流需求的接受程度要低得多。

而且，有一个专门的学士可以帮助。也许他没有执行的作用，但他/她应该：

• 对业务需求之间的关系有一个广泛的理解。他将看到业务需求中的链接，而这些链接对于更专业的同事来说并不明显。例如，对于仓库中的一种材料，客户可能需要遵循几种价格，而仓储也有一些间接成本，以及如何最好地获取它们。
• 作为一种功能集成器，帮助构建一个架构和设计，将所有这些需求结合在一起，最终帮助解决冲突的需求。
• 防止风险，例如，在早期阶段识别缺少的需求，这些需求在业务流程的范围内是常见的。
• 了解不同功能的相对重要性，并帮助对它们进行排序。
• 最重要的是，找出客户当前实践之外的业务改进机会。或者，如果您有一个已经启用了这种更改的产品，量化它们并促进客户业务的更改(“出售”业务案例并得到用户的支持)
• 与高级涉众(客户的CFO对ORM层的优势不感兴趣，但他会很高兴地看到它可以帮助实现降低的维护成本)。

但是，从一个BA中受益的关键是，不要把他/她作为一种规划大师，或者是一些没有人会读到的优秀研究的制作人，而仅仅是预先(是的:是的:这将是非常倾向于瀑布的)：你必须让他/她在整个项目过程中与整个团队的其他成员密切合作。

我也不确定英格兰队需要在多大程度上参与这样一支球队的日常工作。但是，附加值并没有在上面提到的任何内容中列出。

有时，产品所有者加倍作为BA，但取决于领域和该人的经验，这可能是不够的。一个专注的业务分析师是最有知识的人在业务领域。任何BA都肯定被认为是涉众，这只是一个关于如何将她添加到您的开发过程中的问题--无论是作为产品所有者的顾问，还是作为sprint计划会议的定期与会者。

BA可以添加的一些值可以是：

• 根据预期收入确定特征的优先次序
• 澄清任何领域和财务问题
• 可能引入新需求的涉众(比如更好地分析软件对业务的影响的特性)
• 支持更好地将域工作流/流程与软件工作流匹配

这在很大程度上取决于团队成员的能力以及谁的利益受到威胁。对于我们来说，一个典型的项目-- POs通常代表业务兴趣，当他们理解他们的产品和他们的优先级时，他们通常试图向开发团队提出一些粗略的想法，并要求尽快完成所有的事情。BA或Product会减慢他们的速度，并将他们的需求以故事的形式出现，征求评估，确保在承诺之前满足Ready的定义，并迫使他们保持可持续的速度。

如果您的POs更好地与团队保持一致，或者您有足够强大的scrum高手来强制执行流程，那么BA/PDM可能是一种奢侈。以我的经验(主要是咨询)，我们会在没有咨询的情况下被解雇。