在真正的敏捷项目中，业务分析师的角色是否变得多余了？

Question

在一个真正敏捷的项目中，业务正在扮演产品所有者的角色，业务分析师是否仍然有一个角色？一旦开发了用户故事，产品所有者就会进行功能测试，并对用户故事进行文档记录和优先排序。

在这种情况下，我必须补充说，我还没有经历过这种情况，在高绩效、自我激励的开发人员中，我很难看到传统业务分析师的角色？

Answer 1

当然，100%。仍然需要业务分析师：

引用来源：

与项目经理不同，业务分析师参与敏捷项目并不限于项目处于活动状态的时间段。业务分析师通过与投资组合管理团队合作，确保最有价值的项目被投资，在项目期间提供监督，并最终在项目完成后衡量实际收益，从而为公司提供从摇篮到坟墓的连续性。

看看这些链接：

• Agile Modeling
• PM Forum
• Search Software Equality

我在一个项目中工作，在这个项目中，没有BA与开发人员一起工作，产品负责人完全是无用的。它给我们的生活带来的痛苦远远大于拥有BA ;)带来的痛苦

Answer 2

我会说我们的项目相当敏捷(尽管由于各种原因不是SCRUM，但相当接近，并在不断改进-当然，敏捷是否“真正”足够，可以由方法论纯粹主义者争论;-)不管怎样，我们确实有一个BA，我对此感到高兴。

这是一款内部遗留的web应用程序，由数十个国家的数千名代理商使用。要求从许多国家的代表涌入，由于我们公司中的每个国家都有自己的预算和议程，确定任务的优先顺序并不是一个简单的问题，我相信背后有很多管理谈判(幸运的是我没有感觉到任何事情)。因此，我们没有专门的产品负责人--实际上，我们的技术领导扮演的角色与我们需要的一样多。这并不是很多，因为我们的团队已经将应用程序从绝症状态恢复过来，并且仍然不稳定，所以我们的大部分工作是修复错误、重构和其他稳定和清理问题的任务。

我们的BA已经在柜台工作了几年，还有我们的应用程序所依赖的后端系统，所以他比我们任何一个开发人员都更了解这些野兽的内部工作原理，以及在现场使用的过程。这一点尤其重要，因为很少有书面文档，更不用说我们的应用程序应该做什么的规范了。通常，我们很难弄清楚代码的特定行为是bug还是特性。

因此，他帮助我们识别错误，而且做了大量的需求收集，从不同国家的代表那里榨取了一些信息。他还为我们做测试和验证。如果没有他，我们肯定会过得很艰难。

Answer 3

我们的SCRUM团队中至少有一两个BAs。他们填补了产品负责人的角色，每天都不能回答功能性问题。因为：

• 在开发产品积压的过程中，他们一直与产品负责人举行会议。
• 与开发人员和QA
• 相比，他们对Sprint中用户故事的相对优先级有更好的认识。他们帮助当前sprint中的功能进行高级设计，以平滑合并最有可能在未来3~4个sprint中出现的用户故事。