我参与过一个项目，没有 BA 与开发人员合作，产品负责人完全没用。它给我们生活带来的痛苦远远大于获得学士学位的痛苦;)
Absolutely, 100%. There is still a need business analysts:
Quoting from a source:
The business analyst involvement in
agile projects, unlike that of the
project manager, is not limited to the
period of time when the projects are
active. Business analysts provide
continuity for companies from cradle
to grave by working with portfolio
management teams to make sure the most
valuable projects are being invested
in, providing oversight during
projects, and finally measuring actual
benefits after projects are completed.
I worked on a project whereby there was no BA working with the developers and the product owner was completely useless. The pain it brought into our lives was far greater than the pain of having a BA ;)
I would call our project fairly agile (although not SCRUM by the book for various reasons, but reasonably close, and improving - of course, whether it is agile "truly" enough, can be debated by methodology purists ;-) Anyway, we do have a BA, and I am happy about it.
It is an in-house legacy web app, used by thousands of agents in dozens of countries. The requirements are pouring in from many country representatives, and since each country inside our corporation has their own budget and agenda, prioritizating tasks is not a simple issue, I believe there is a lot of managerial negotiations behind (of which luckily I don't sense anything). So we don't have a dedicated product owner - practically our tech lead plays the role as much as it is needed. Which is not very much, since the app has been brought back from terminally ill status by our team and is still shaky, so the larger part of our work is bug fixing, refactoring and other tasks to stabilize and clean up things.
Our BA has been working at the counter for a couple of years, also with the back-end system our app depends on, so he knows more about the inner workings of these beasts, and also the processes used on the field, than any of us developers. This is especially important since there is very little written documentation, let alone specification of what our app is supposed to do. Often we have trouble figuring out whether the particular behaviour of the code is a bug or a feature.
So he helps us identifying bugs, moreover does a lot of requirements gathering, squeezing bits of info out of various country representatives. He also does testing and verification for us. We would definitely have a hard time without him.
We do have at least one or two BAs in our SCRUM team. They fill the role of Product Owner not being available on a daily basis to answer functional questions. Because:
They have been in meetings with the Product owner in developing the Product Backlog.
They have a better sense of relative priority of user stories in a Sprint compared to developers and QA
They help out with high level design of features in current sprint to the extent of smoothing out incorporation of user stories that most likely will be coming 3~4 sprints down the road.
产品负责人拥有产品待办事项列表并负责管理它，但这并不意味着她是唯一执行业务分析类型任务的人。 PO 的工作是做出有关价值和优先级的决策。其他团队成员可以（而且通常确实）帮助提供数据来推动这些决策。
业务分析师经常帮助整理待办事项列表（对于复杂的项目，他们可能必须这样做）；如果不维护产品，产品负责人就会遇到麻烦。分析师的角色在 Scrum 团队中肯定会发生变化（Mike Cohn 的第 8 章 Succeeding with Agile 有几页介绍了这一点），但是在团队中拥有非 PO 分析师仍然非常有用。 （我希望我现在的团队有一个。）
It's really a question of how complex your Product Backlog Items are and how much analysis work they take to put them in a state where the Team can commit to them in a Sprint.
The Product Owner owns the Product Backlog and is responsible for managing it, but that doesn't mean she is the only person doing business analysis-type tasks. The PO's job is to make decisions about value and priority. Other team members can (and usually do) help provide the data to fuel those decisions.
Business Analysts often help groom the Backlog (and on complex projects, they probably have to); the Product Owner is one who is in trouble if it isn't maintained. The role of Analysts certainly changes in Scrum teams (Chapter 8 of Mike Cohn's Succeeding with Agile has a few pages on this), but having a non-PO Analyst on a team can still be quite useful. (I wish my current team had one.)
发布评论
评论（4）
绝对是，100%。还是需要业务分析师：
引用一位消息人士：
查看这些链接：
我参与过一个项目，没有 BA 与开发人员合作，产品负责人完全没用。它给我们生活带来的痛苦远远大于获得学士学位的痛苦
;)Absolutely, 100%. There is still a need business analysts:
Quoting from a source:
Have a look at these links:
I worked on a project whereby there was no BA working with the developers and the product owner was completely useless. The pain it brought into our lives was far greater than the pain of having a BA
;)我认为我们的项目相当敏捷（虽然由于各种原因不是书本上的 SCRUM，但相当接近，并且正在改进 - 当然，它是否“真正”足够敏捷，可以由方法论纯粹主义者争论;-）无论如何，我们确实拥有学士学位，我对此感到很高兴。
它是一个内部遗留网络应用程序，被数十个国家的数千名代理商使用。许多国家代表纷纷提出要求，而且由于我们公司内部每个国家都有自己的预算和议程，任务的优先顺序不是一个简单的问题，我相信背后有很多管理谈判（幸运的是我不知道）感知任何东西）。因此，我们没有专门的产品负责人 - 实际上我们的技术主管只扮演需要的角色。这并不是很多，因为应用程序已经被我们的团队从绝症状态中恢复过来，而且仍然不稳定，所以我们的大部分工作是错误修复、重构和其他任务来稳定和清理东西。
我们的 BA 已经在柜台工作了几年，也与我们的应用程序所依赖的后端系统一起工作，因此他比任何人都更了解这些野兽的内部运作方式以及现场使用的流程。美国开发商。这一点尤其重要，因为书面文档很少，更不用说我们的应用程序应该做什么的规范了。我们常常很难确定代码的特定行为是错误还是功能。
因此，他帮助我们识别错误，此外还收集了大量需求，从各个国家代表那里榨取了一些信息。他还为我们做测试和验证。没有他，我们肯定会过得很艰难。
I would call our project fairly agile (although not SCRUM by the book for various reasons, but reasonably close, and improving - of course, whether it is agile "truly" enough, can be debated by methodology purists ;-) Anyway, we do have a BA, and I am happy about it.
It is an in-house legacy web app, used by thousands of agents in dozens of countries. The requirements are pouring in from many country representatives, and since each country inside our corporation has their own budget and agenda, prioritizating tasks is not a simple issue, I believe there is a lot of managerial negotiations behind (of which luckily I don't sense anything). So we don't have a dedicated product owner - practically our tech lead plays the role as much as it is needed. Which is not very much, since the app has been brought back from terminally ill status by our team and is still shaky, so the larger part of our work is bug fixing, refactoring and other tasks to stabilize and clean up things.
Our BA has been working at the counter for a couple of years, also with the back-end system our app depends on, so he knows more about the inner workings of these beasts, and also the processes used on the field, than any of us developers. This is especially important since there is very little written documentation, let alone specification of what our app is supposed to do. Often we have trouble figuring out whether the particular behaviour of the code is a bug or a feature.
So he helps us identifying bugs, moreover does a lot of requirements gathering, squeezing bits of info out of various country representatives. He also does testing and verification for us. We would definitely have a hard time without him.
我们的 SCRUM 团队中至少有一两个 BA。他们担任产品负责人的角色，但无法每天回答功能性问题。因为：
他们一直在与产品所有者开会以制定产品待办事项列表。
与开发人员和 QA 相比，他们对 Sprint 中用户故事的相对优先级有更好的认识
与开发人员和 QA 相比，
他们提供帮助在当前冲刺中对功能进行高级设计，以平滑合并用户故事，这些用户故事很可能会在未来 3~4 个冲刺中出现。
We do have at least one or two BAs in our SCRUM team. They fill the role of Product Owner not being available on a daily basis to answer functional questions. Because:
They have been in meetings with the Product owner in developing the Product Backlog.
They have a better sense of relative priority of user stories in a Sprint compared to developers and QA
They help out with high level design of features in current sprint to the extent of smoothing out incorporation of user stories that most likely will be coming 3~4 sprints down the road.
这实际上是一个问题，即你的产品待办事项列表项有多复杂，以及需要多少分析工作才能将它们置于团队可以在 Sprint 中承诺的状态。
产品负责人拥有产品待办事项列表并负责管理它，但这并不意味着她是唯一执行业务分析类型任务的人。 PO 的工作是做出有关价值和优先级的决策。其他团队成员可以（而且通常确实）帮助提供数据来推动这些决策。
业务分析师经常帮助整理待办事项列表（对于复杂的项目，他们可能必须这样做）；如果不维护产品，产品负责人就会遇到麻烦。分析师的角色在 Scrum 团队中肯定会发生变化（Mike Cohn 的第 8 章 Succeeding with Agile 有几页介绍了这一点），但是在团队中拥有非 PO 分析师仍然非常有用。 （我希望我现在的团队有一个。）
It's really a question of how complex your Product Backlog Items are and how much analysis work they take to put them in a state where the Team can commit to them in a Sprint.
The Product Owner owns the Product Backlog and is responsible for managing it, but that doesn't mean she is the only person doing business analysis-type tasks. The PO's job is to make decisions about value and priority. Other team members can (and usually do) help provide the data to fuel those decisions.
Business Analysts often help groom the Backlog (and on complex projects, they probably have to); the Product Owner is one who is in trouble if it isn't maintained. The role of Analysts certainly changes in Scrum teams (Chapter 8 of Mike Cohn's Succeeding with Agile has a few pages on this), but having a non-PO Analyst on a team can still be quite useful. (I wish my current team had one.)